User:Gmaxwell/mtx: Difference between revisions
a very rough outline |
mNo edit summary |
||
| Line 1: | Line 1: | ||
A proposal for special messaging transactions. | A proposal for special messaging transactions. | ||
Many people want to use the | Many people want to use the Bitcoin network for messaging: no other | ||
practical flooding networks exists and flooding has interesting | practical flooding networks exists and flooding has interesting | ||
security properties. | security properties. Plus, the Bitcoin network reaches Bitcoin nodes | ||
by definition so its convenient when people are already connected to | |||
the network. | |||
When | When people use transactions to accomplish messaging there is a tremendous | ||
externalized cost: transaction data which is part of the blockchain | externalized cost: transaction data which is part of the blockchain | ||
must be preserved by someone forever and accessible to the network | must be preserved (by someone, potentially 'everyone') forever and accessible to the network | ||
so that the chain can be validated. | so that the chain can be validated. | ||
| Line 27: | Line 29: | ||
queues size can be managed by prematurely expiring the nearest to | queues size can be managed by prematurely expiring the nearest to | ||
expiration limits. | 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 | If a transaction is received when its rate-limiter hasn't expired yet | ||
Revision as of 18:34, 27 February 2013
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).