From mboxrd@z Thu Jan 1 00:00:00 1970 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 1YxuYh-0008NI-4l for bitcoin-development@lists.sourceforge.net; Thu, 28 May 2015 09:57:03 +0000 X-ACL-Warn: Received: from mail-ie0-f176.google.com ([209.85.223.176]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YxuYf-0001yL-Pg for bitcoin-development@lists.sourceforge.net; Thu, 28 May 2015 09:57:03 +0000 Received: by ieczm2 with SMTP id zm2so34241135iec.1 for ; Thu, 28 May 2015 02:56:56 -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:from:date :message-id:subject:to:cc:content-type; bh=F06pwZJl/MrEXjVNV6Fb4vlj0DqyhtMKFmI56M5xShM=; b=O+t3nbJHHQllNn1fE8qjXz/aeNxSxUIYUYImNTgD2PZYlVUr1tL4TtzJmNFzQoMiyK DRDYGXWg+CFf8Qcb8FU4jqRuAL23YsYrEXkkXRkU459aT+Wrwo4E7gjvVvEKKa8LDHcy vuvn1cptp6gmrJ7b27upZ5T0KFSCPVBLYNgLlCo8yO97rnr/L1E1l3CTK+LCXO6ccPUv T9+Z4RMwR3MwV3LPYzSisQfgLXH+ngpq3ppVRmPXcsQvnakWx+mDcfEISvCbD1Gr8X50 yZsARl7QGvwM6gzlUyujQ9BCzvwkPfqCEVh/rIGSVlNzJCNw4TMtoISn/Cfx2wg0Z7ua VR5Q== X-Gm-Message-State: ALoCoQk9646rP14fw9svHd9l4Hwl8AsRvJ5p4OETw5LhnHJo/OJ5u8RgDAzf350oQBItKddMnZPt X-Received: by 10.42.176.8 with SMTP id bc8mr8056822icb.22.1432807016408; Thu, 28 May 2015 02:56:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.10.197 with HTTP; Thu, 28 May 2015 02:56:36 -0700 (PDT) X-Originating-IP: [50.0.37.37] In-Reply-To: References: From: Mark Friedenbach Date: Thu, 28 May 2015 02:56:36 -0700 Message-ID: To: Mike Hearn Content-Type: multipart/alternative; boundary=90e6ba6e86423ec12505172161ea X-Spam-Score: 1.0 (+) 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 X-Headers-End: 1YxuYf-0001yL-Pg 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 09:57:03 -0000 --90e6ba6e86423ec12505172161ea Content-Type: text/plain; charset=UTF-8 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. > --90e6ba6e86423ec12505172161ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have no problem with modifying the proposal to have the = most significant bit signal use of the nSequence field as a relative lock-t= ime. 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/ma= aku/bitcoin/tree/sequencenumbers
On Wed, May 27, 2015 at 10:39 AM, Mike Hearn <= span dir=3D"ltr"><m= ike@plan99.net> wrote:
Mike, this proposal was purposefully constructed to maintain as we= ll 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 select= ed by miners before the later transactions mature. Did I fail in some way t= o 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.

--90e6ba6e86423ec12505172161ea--