path: root/ef/a58841d269ede8822c99f336f231895c0b236f

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mark@friedenbach.org>) id 1YxzHH-0006e6-HJ
	for bitcoin-development@lists.sourceforge.net;
	Thu, 28 May 2015 14:59:23 +0000
X-ACL-Warn: 
Received: from mail-ig0-f169.google.com ([209.85.213.169])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YxzHC-0004yI-VP
	for bitcoin-development@lists.sourceforge.net;
	Thu, 28 May 2015 14:59:23 +0000
Received: by igbpi8 with SMTP id pi8so114005840igb.1
	for <bitcoin-development@lists.sourceforge.net>;
	Thu, 28 May 2015 07:59:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:cc:content-type;
	bh=FS3pEo0baUWseoC9QLQ1VIcb/VEw0LgEMn7HuxgHTyg=;
	b=W9I+d/EjPmQCB14sjdq3SI5ONCSk6e38q2QPv1CrsByIAie/NJ6XQPqiErG27Rx+xH
	iEqqMt9yFZYu0BeRsb21EPl7zOiFH28lI1w7bk4lomfN0W/i/6PRZGau9yOlPQfZo+TD
	vgo5lexgA/h6i06V4q4Te1sM2SQwVjxPzngbCE8eg50LfQPN5f2E52XTgZa8gFaj7p7z
	WVGCLzwREzWPHFjZ1yJ9AwaTSouglfN7hfw6oW7lOalZmDwVcsW2cJKo1fhSxASyqnys
	FKJHbpurwsFG5KlHy9P0Lp//jQqTn5ryei1Pa2q722BqUVfn7pKVRGtFqTB71XgazSlk
	JnTQ==
X-Gm-Message-State: ALoCoQnPGPEIEeNLUq15Sv2MzB4TZ1UnIJaOnt9p+zxwqXgDExb2I3zGqR6ZFb7t8uG1WYAgEve/
MIME-Version: 1.0
X-Received: by 10.43.59.80 with SMTP id wn16mr9813634icb.40.1432825153581;
	Thu, 28 May 2015 07:59:13 -0700 (PDT)
Received: by 10.107.10.197 with HTTP; Thu, 28 May 2015 07:59:13 -0700 (PDT)
X-Originating-IP: [172.56.9.144]
Received: by 10.107.10.197 with HTTP; Thu, 28 May 2015 07:59:13 -0700 (PDT)
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
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	1.0 HTML_MESSAGE           BODY: HTML included in message
	0.2 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YxzHC-0004yI-VP
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Consensus-enforced transaction
 replacement via sequence numbers
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 28 May 2015 14:59:23 -0000

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