User:Gmaxwell/mtx
A proposal for special messaging transactions.
Many people want to use the Bitcoin network for messaging: no other practical flooding networks exists and flooding has interesting security properties. Plus, the Bitcoin network reaches Bitcoin nodes by definition so its convenient when people are already connected to the network.
When people use transactions to accomplish messaging there is a tremendous externalized cost: transaction data which is part of the blockchain must be preserved (by someone, potentially 'everyone') forever and accessible to the network so that the chain can be validated.
But messaging doesn't have unlimited life, it doesn't need to go into the chain.
Instead, we could permit relaying transactions which are non-final and have a lock time set maximally far in the future. These wouldn't get mined, and so don't have the perpetual storage issue.
To prevent them from being spammed to death we would require that the transactions be valid spends of existing bitcoin unspent transactions. But instead of placing them into the memory pool and preventing further spends, we would place the input TXID:Vout into a priority queue keyed by expiration-priority.
The expiration priority should be 'now' + factor*tx_in_value/tx_size, with factor set to get reasonable behavior (needs discussion). The queues size can be managed by prematurely expiring the nearest to expiration limits.
Effectively, the scarcity of bitcoin is what controls access to the flooding network.
If a transaction is received when its rate-limiter hasn't expired yet the limit is adjusted to the new (further future expiration) and the txn is dropped.
To further prevent spamming, the txid of these transactions should be required to be below a certain target, so creating the transaction requires comparable cpu time to the work the whole network will do in validating and checking the transaction. Though this wouldn't be a very high barrier, it is more equitable than letting someone holding a bunch of coins spam endlessly for free and it doesn't require memory to store the ratelimiters.
To prevent wallets from being confused that they're getting paid by these txn which will never confirm the txout values should be required to be zero (all input 'goes to' fee, though the txn will never be mined).
open issues
- prevent message, spend, message using change from being a way to get unlimited rate. Perhaps require any txin used for this to be at least N (2?) confirms deep. You could still message per tx you send, at 'no cost' (except the POW) but I think thats a desirable property and the POW keeps the badness of that bounded.