public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers
@ 2015-05-27  1:50 Mark Friedenbach
  2015-05-27  7:47 ` Peter Todd
                   ` (2 more replies)
  0 siblings, 3 replies; 22+ messages in thread
From: Mark Friedenbach @ 2015-05-27  1:50 UTC (permalink / raw)
  To: Bitcoin Development

[-- Attachment #1: Type: text/plain, Size: 2458 bytes --]

Sequence numbers appear to have been originally intended as a mechanism for
transaction replacement within the context of multi-party transaction
construction, e.g. a micropayment channel. The idea is that a participant
can sign successive versions of a transaction, each time incrementing the
sequence field by some amount. Relay nodes perform transaction replacement
according to some policy rule making use of the sequence numbers, e.g.
requiring sequence numbers in a replacement to be monotonically increasing.

As it happens, this cannot be made safe in the bitcoin protocol as deployed
today, as there is no enforcement of the rule that miners include the most
recent transaction in their blocks. As such, any protocol relying on a
transaction replacement policy can be defeated by miners choosing not to
follow that policy, which they may even be incentivised to do so (if older
transactions provide higher fee per byte, for example). Transaction
replacement is presently disabled in Bitcoin Core.

These shortcomings can be fixed in an elegant way by giving sequence
numbers new consensus-enforced semantics as a relative lock-time: if a
sequence number is non-final (MAX_INT), its bitwise inverse is interpreted
as either a relative height or time delta which is added to the height or
median time of the block containing the output being spent to form a
per-input lock-time. The lock-time of each input constructed in this manor,
plus the nLockTime of the transaction itself if any input is non-final must
be satisfied for a transaction to be valid.

For example, a transaction with an txin.nSequence set to 0xffffff9b [==
~(uint32_t)100] is prevented by consensus rule from being selected for
inclusion in a block until the 100th block following the one including the
parent transaction referenced by that input.

In this way one may construct, for example, a bidirectional micropayment
channel where each change of direction increments sequence numbers to make
the transaction become valid prior to any of the previously exchanged
transactions.

This also enables the discussed relative-form of CHECKLOCKTIMEVERIFY to be
implemented in the same way: by checking transaction data only and not
requiring contextual information like the block height or timestamp.

An example implementation of this concept, as a policy change to the
mempool processing of Bitcoin Core is available on github:

https://github.com/maaku/bitcoin/tree/sequencenumbers

[-- Attachment #2: Type: text/html, Size: 2594 bytes --]

^ permalink raw reply	[flat|nested] 22+ messages in thread

end of thread, other threads:[~2015-06-10  2:43 UTC | newest]

Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-05-27  1:50 [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers Mark Friedenbach
2015-05-27  7:47 ` Peter Todd
2015-05-27  8:18   ` Gregory Maxwell
2015-05-27 10:00     ` Tier Nolan
2015-05-27 10:58     ` Peter Todd
2015-05-27 17:07       ` Jorge Timón
2015-05-27  8:04 ` Telephone Lemien
2015-05-27 10:11 ` Mike Hearn
2015-05-27 15:26   ` Mark Friedenbach
2015-05-27 17:39     ` Mike Hearn
2015-05-28  9:56       ` Mark Friedenbach
2015-05-28 10:23         ` Mike Hearn
2015-05-28 10:30         ` Tier Nolan
2015-05-28 12:04           ` Peter Todd
2015-05-28 13:35             ` Tier Nolan
2015-05-28 16:22               ` s7r
2015-05-28 17:21                 ` Tier Nolan
2015-05-28 14:59           ` Mark Friedenbach
2015-05-28 15:18             ` Tier Nolan
2015-05-28 15:38               ` Mark Friedenbach
2015-05-28 15:57                 ` Tier Nolan
2015-06-10  2:40                   ` Rusty Russell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox