User:Gmaxwell/mtx - Revision history

Gmaxwell: open issues

2013-02-27T18:44:52Z

open issues

← Older revision		Revision as of 18:44, 27 February 2013
Line 49:		Line 49:
	should be required to be zero (all input 'goes to' fee,		should be required to be zero (all input 'goes to' fee,
	though the txn will never be mined).		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.

Gmaxwell at 18:34, 27 February 2013

2013-02-27T18:34:56Z

← Older revision		Revision as of 18:34, 27 February 2013
Line 1:		Line 1:
	A proposal for special messaging transactions.		A proposal for special messaging transactions.

	Many people want to use the ~~bitcoin~~ network for messaging no other		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 ~~they~~ use transactions to accomplish ~~this~~ there is a tremendous		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

Gmaxwell: a very rough outline

2013-02-27T18:30:13Z

a very rough outline

New page

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.

When they use transactions to accomplish this there is a tremendous
externalized cost: transaction data which is part of the blockchain
must be preserved by someone 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.

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).