MIME-Version: 1.0
In-Reply-To: <CANEZrP0zKe7hK0KjiXN9M6CHnJxKZfW9myez3G+GWpr3fugBCg@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>
From: Mark Friedenbach <mark@friedenbach.org>
Date: Thu, 28 May 2015 02:56:36 -0700
Message-ID: <CAOG=w-vusO30sBZfsuP94wbkUUfHupmhQtScGsJ2463sO=EpzA@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=90e6ba6e86423ec12505172161ea
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Consensus-enforced transaction
 replacement via sequence numbers
Precedence: list

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

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

<div dir=3D"ltr">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:<br><br><a href=3D"h=
ttps://github.com/maaku/bitcoin/tree/sequencenumbers">https://github.com/ma=
aku/bitcoin/tree/sequencenumbers</a><br></div><div class=3D"gmail_extra"><b=
r><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:mike@plan99.net" target=3D"_blank">m=
ike@plan99.net</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
 dir=3D"ltr"><span class=3D""><div class=3D"gmail_extra"><div class=3D"gmai=
l_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmai=
l_extra">Mike, this proposal was purposefully constructed to maintain as we=
ll as possible the semantics of Satoshi&#39;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?<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>

--90e6ba6e86423ec12505172161ea--