Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.213.173 as permitted sender)
	client-ip=209.85.213.173;
	envelope-from=lemientelephone@gmail.com;
	helo=mail-ig0-f173.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAOG=w-sfiUQQGUh=RR55NU-TkAi1+2g3_Z+YP3dGDjp8zXYBGQ@mail.gmail.com>
References: <CAOG=w-sfiUQQGUh=RR55NU-TkAi1+2g3_Z+YP3dGDjp8zXYBGQ@mail.gmail.com>
Date: Wed, 27 May 2015 10:04:09 +0200
Message-ID: <CAL6tygZbYOXh3bS50ejwS6aynhuxu2xCoAOV9Fb7hfLu-4RFpA@mail.gmail.com>
From: Telephone Lemien <lemientelephone@gmail.com>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a114089c40d333105170bb049
Subject: Re: [Bitcoin-development] Consensus-enforced transaction
 replacement via sequence numbers
Precedence: list

--001a114089c40d333105170bb049
Content-Type: text/plain; charset=UTF-8

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

--001a114089c40d333105170bb049
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Please remove me from the mailing list<br></div><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">2015-05-27 3:50 GMT+02:00 M=
ark Friedenbach <span dir=3D"ltr">&lt;<a href=3D"mailto:mark@friedenbach.or=
g" target=3D"_blank">mark@friedenbach.org</a>&gt;</span>:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div dir=3D"ltr">Sequence numbers appear to have been orig=
inally intended as a mechanism for transaction replacement within the conte=
xt of multi-party transaction construction, e.g. a micropayment channel. Th=
e idea is that a participant can sign successive versions of a transaction,=
 each time incrementing the sequence field by some amount. Relay nodes perf=
orm transaction replacement according to some policy rule making use of the=
 sequence numbers, e.g. requiring sequence numbers in a replacement to be m=
onotonically increasing.<br><br>As it happens, this cannot be made safe in =
the bitcoin protocol as deployed today, as there is no enforcement of the r=
ule that miners include the most recent transaction in their blocks. As suc=
h, any protocol relying on a transaction replacement policy can be defeated=
 by miners choosing not to follow that policy, which they may even be incen=
tivised to do so (if older transactions provide higher fee per byte, for ex=
ample). Transaction replacement is presently disabled in Bitcoin Core.<br><=
br>These shortcomings can be fixed in an elegant way by giving sequence num=
bers new consensus-enforced semantics as a relative lock-time: if a sequenc=
e number is non-final (MAX_INT), its bitwise inverse is interpreted as eith=
er a relative height or time delta which is added to the height or median t=
ime 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 nLoc=
kTime of the transaction itself if any input is non-final must be satisfied=
 for a transaction to be valid.<br><br>For example, a transaction with an t=
xin.nSequence set to 0xffffff9b [=3D=3D ~(uint32_t)100] is prevented by con=
sensus rule from being selected for inclusion in a block until the 100th bl=
ock following the one including the parent transaction referenced by that i=
nput.<br><br>In this way one may construct, for example, a bidirectional mi=
cropayment channel where each change of direction increments sequence numbe=
rs to make the transaction become valid prior to any of the previously exch=
anged transactions.<br><br>This also enables the discussed relative-form of=
 CHECKLOCKTIMEVERIFY to be implemented in the same way: by checking transac=
tion data only and not requiring contextual information like the block heig=
ht or timestamp.<br><br>An example implementation of this concept, as a pol=
icy change to the mempool processing of Bitcoin Core is available on github=
:<br><br><a href=3D"https://github.com/maaku/bitcoin/tree/sequencenumbers" =
target=3D"_blank">https://github.com/maaku/bitcoin/tree/sequencenumbers</a>=
<br></div>
<br>-----------------------------------------------------------------------=
-------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div>

--001a114089c40d333105170bb049--