public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Telephone Lemien <lemientelephone@gmail.com>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers
Date: Wed, 27 May 2015 10:04:09 +0200	[thread overview]
Message-ID: <CAL6tygZbYOXh3bS50ejwS6aynhuxu2xCoAOV9Fb7hfLu-4RFpA@mail.gmail.com> (raw)
In-Reply-To: <CAOG=w-sfiUQQGUh=RR55NU-TkAi1+2g3_Z+YP3dGDjp8zXYBGQ@mail.gmail.com>

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

Please remove me from the mailing list

2015-05-27 3:50 GMT+02:00 Mark Friedenbach <mark@friedenbach.org>:

> 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
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

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

  parent reply	other threads:[~2015-05-27  8:04 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAL6tygZbYOXh3bS50ejwS6aynhuxu2xCoAOV9Fb7hfLu-4RFpA@mail.gmail.com \
    --to=lemientelephone@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox