MIME-Version: 1.0
In-Reply-To: <CAE-z3OUG5p_hAOFvaE10kTT7sa=2GrzvZpis5FzATSEcNwZpyw@mail.gmail.com>
References: <CAOG=w-sfiUQQGUh=RR55NU-TkAi1+2g3_Z+YP3dGDjp8zXYBGQ@mail.gmail.com>
	<CANEZrP0QMHp9PwBr=ekkujtA+=LXbgiL4xkXRSmcOGqaLJEp0g@mail.gmail.com>
	<CAOG=w-s7JkB6SyEE0=KwmrasyH22aB2Zf3jBdKcXvrGoNhN_Nw@mail.gmail.com>
	<CANEZrP0zKe7hK0KjiXN9M6CHnJxKZfW9myez3G+GWpr3fugBCg@mail.gmail.com>
	<CAOG=w-vusO30sBZfsuP94wbkUUfHupmhQtScGsJ2463sO=EpzA@mail.gmail.com>
	<CAE-z3OUG5p_hAOFvaE10kTT7sa=2GrzvZpis5FzATSEcNwZpyw@mail.gmail.com>
Date: Thu, 28 May 2015 07:59:13 -0700
Message-ID: <CAOG=w-tQyrc8ncAFauDObmBYn3uSwBcLoWVqruaV6PcTUFbTKg@mail.gmail.com>
From: Mark Friedenbach <mark@friedenbach.org>
To: Tier Nolan <tier.nolan@gmail.com>
Content-Type: multipart/alternative; boundary=bcaec51dd23b4e09a70517259a7e
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Consensus-enforced transaction
 replacement via sequence numbers
Precedence: list

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

Why 3? Do we have a version 2?

As for doing it in serialization, that would alter the txid making it a
hard fork change.
On May 28, 2015 03:30, "Tier Nolan" <tier.nolan@gmail.com> wrote:

> Can you update it so that it only applies to transactions with version
> number 3 and higher.  Changing the meaning of a field is exactly what the
> version numbers are for.
>
> You could even decode version 3 transactions like that.
>
> Version 3 transactions have a sequence number of 0xFFFFFFFF and the
> sequence number field is re-purposed for relative lock time.
>
> This means that legacy transactions that have already been signed but have
> a locktime in the future will still be able to enter the blockchain
> (without having to wait significantly longer than expected).
>
> On Thu, May 28, 2015 at 10:56 AM, Mark Friedenbach <mark@friedenbach.org>
> wrote:
>
>> I have no problem with modifying the proposal to have the most
>> significant bit signal use of the nSequence field as a relative lock-time.
>> That leaves a full 31 bits for experimentation when relative lock-time is
>> not in use. I have adjusted the code appropriately:
>>
>> https://github.com/maaku/bitcoin/tree/sequencenumbers
>>
>> On Wed, May 27, 2015 at 10:39 AM, Mike Hearn <mike@plan99.net> wrote:
>>
>>> Mike, this proposal was purposefully constructed to maintain as well as
>>>> possible the semantics of Satoshi's original construction. Higher sequence
>>>> numbers -- chronologically later transactions -- are able to hit the chain
>>>> earlier, and therefore it can be reasonably argued will be selected by
>>>> miners before the later transactions mature. Did I fail in some way to
>>>> capture that original intent?
>>>>
>>>
>>> Right, but the original protocol allowed for e.g. millions of revisions
>>> of the transaction, hence for high frequency trading (that's actually how
>>> Satoshi originally explained it to me - as a way to do HFT - back then the
>>> channel concept didn't exist).
>>>
>>> As you point out, with a careful construction of channels you should
>>> only need to bump the sequence number when the channel reverses direction.
>>> If your app only needs to do that rarely, it's a fine approach.And your
>>> proposal does sounds better than sequence numbers being useless like at the
>>> moment. I'm just wondering if we can get back to the original somehow or at
>>> least leave a path open to it, as it seems to be a superset of all other
>>> proposals, features-wise.
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

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

<p dir=3D"ltr">Why 3? Do we have a version 2?</p>
<p dir=3D"ltr">As for doing it in serialization, that would alter the txid =
making it a hard fork change.</p>
<div class=3D"gmail_quote">On May 28, 2015 03:30, &quot;Tier Nolan&quot; &l=
t;<a href=3D"mailto:tier.nolan@gmail.com">tier.nolan@gmail.com</a>&gt; wrot=
e:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div><div><div>Can you update it so that it only applies to transactions wi=
th version number 3 and higher.=C2=A0 Changing the meaning of a field is ex=
actly what the version numbers are for.<br><br></div>You could even decode =
version 3 transactions like that.=C2=A0 <br><br></div>Version 3 transaction=
s have a sequence number of 0xFFFFFFFF and the sequence number field is re-=
purposed for relative lock time.=C2=A0 <br><br></div>This means that legacy=
 transactions that have already been signed but have a locktime in the futu=
re will still be able to enter the blockchain (without having to wait signi=
ficantly longer than expected).<br></div><div class=3D"gmail_extra"><br><di=
v class=3D"gmail_quote">On Thu, May 28, 2015 at 10:56 AM, Mark Friedenbach =
<span dir=3D"ltr">&lt;<a href=3D"mailto:mark@friedenbach.org" target=3D"_bl=
ank">mark@friedenbach.org</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><div dir=3D"ltr">I have no problem with modifying the proposal to ha=
ve the most significant bit signal use of the nSequence field as a relative=
 lock-time. That leaves a full 31 bits for experimentation when relative lo=
ck-time is not in use. I have adjusted the code appropriately:<br><br><a hr=
ef=3D"https://github.com/maaku/bitcoin/tree/sequencenumbers" target=3D"_bla=
nk">https://github.com/maaku/bitcoin/tree/sequencenumbers</a><br></div><div=
><div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, May=
 27, 2015 at 10:39 AM, Mike Hearn <span dir=3D"ltr">&lt;<a href=3D"mailto:m=
ike@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;</span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span><div class=3D"gmail_e=
xtra"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D=
"ltr"><div class=3D"gmail_extra">Mike, this proposal was purposefully const=
ructed to maintain as well as possible the semantics of Satoshi&#39;s origi=
nal construction. Higher sequence numbers -- chronologically later transact=
ions -- are able to hit the chain earlier, and therefore it can be reasonab=
ly argued will be selected by miners before the later transactions mature. =
Did I fail in some way to capture that original intent?<br></div></div>
</blockquote></div><br></div></span><div class=3D"gmail_extra">Right, but t=
he original protocol allowed for e.g. millions of revisions of the transact=
ion, hence for high frequency trading (that&#39;s actually how Satoshi orig=
inally explained it to me - as a way to do HFT - back then the channel conc=
ept didn&#39;t exist).</div><div class=3D"gmail_extra"><br></div><div class=
=3D"gmail_extra">As you point out, with a careful construction of channels =
you should only need to bump the sequence number when the channel reverses =
direction. If your app only needs to do that rarely, it&#39;s a fine approa=
ch.And your proposal does sounds better than sequence numbers being useless=
 like at the moment. I&#39;m just wondering if we can get back to the origi=
nal somehow or at least leave a path open to it, as it seems to be a supers=
et of all other proposals, features-wise.</div></div>
</blockquote></div><br></div>
</div></div><br>-----------------------------------------------------------=
-------------------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@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>
<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>

--bcaec51dd23b4e09a70517259a7e--