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 ) 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 ; 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: References: Date: Thu, 28 May 2015 07:59:13 -0700 Message-ID: From: Mark Friedenbach To: Tier Nolan 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" 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 > 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 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

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" &l= t;tier.nolan@gmail.com> wrot= e:
=
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.

You could even decode = version 3 transactions like that.=C2=A0

Version 3 transaction= s have a sequence number of 0xFFFFFFFF and the sequence number field is re-= purposed for relative lock time.=C2=A0

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

On Thu, May 28, 2015 at 10:56 AM, Mark Friedenbach = <mark@friedenbach.org> wrote:
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:

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 const= ructed to maintain as well as possible the semantics of Satoshi'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?

Right, but t= he original protocol allowed for e.g. millions of revisions of the transact= ion, hence for high frequency trading (that's actually how Satoshi orig= inally explained it to me - as a way to do HFT - back then the channel conc= ept 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 approa= ch.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 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.


-----------------------------------------------------------= -------------------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment



-----------------------------------------------------------------------= -------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--bcaec51dd23b4e09a70517259a7e--