Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.220.173 as permitted sender)
	client-ip=209.85.220.173; envelope-from=tier.nolan@gmail.com;
	helo=mail-qk0-f173.google.com; 
MIME-Version: 1.0
In-Reply-To: <CAOG=w-tQyrc8ncAFauDObmBYn3uSwBcLoWVqruaV6PcTUFbTKg@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>
	<CAOG=w-tQyrc8ncAFauDObmBYn3uSwBcLoWVqruaV6PcTUFbTKg@mail.gmail.com>
Date: Thu, 28 May 2015 16:18:05 +0100
Message-ID: <CAE-z3OXO++0n+UVKe1KYyGv=GyHrZ-MsJtYELk+KC6cEV2UbHQ@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a1139594ec0ac55051725dd3e
Subject: Re: [Bitcoin-development] Consensus-enforced transaction
 replacement via sequence numbers
Precedence: list

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

On Thu, May 28, 2015 at 3:59 PM, Mark Friedenbach <mark@friedenbach.org>
wrote:

> Why 3? Do we have a version 2?
>
I meant whatever the next version is, so you are right, it's version 2.

> As for doing it in serialization, that would alter the txid making it a
> hard fork change.
>
The change is backwards compatible (since there is no restrictions on
sequence numbers).   This makes it a soft fork.

That doesn't change the fact that you are changing what a field in the
transaction represents.

You could say that the sequence number is no longer encoded in the
serialization, it is assumed to be 0xFFFFFFFF for all version 2+
transactions and the relative locktime is a whole new field that is the
same size (and position).

I think keeping some of the bytes for other uses is a good idea.  The
entire top 2 bytes could be ignored when working out relative locktime
verify.  That leaves them fully free to be set to anything.

It could be that if the MSB of the bottom 2 bytes is set, then that
activates the rule and the top 2 bytes are ignored.

Are there any use-cases which need a RLTV of more than 8191 blocks delay
(that can't be covered by the absolute version)?

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div>On Thu, May 28, 2015 at 3:=
59 PM, Mark Friedenbach <span dir=3D"ltr">&lt;<a href=3D"mailto:mark@friede=
nbach.org" target=3D"_blank">mark@friedenbach.org</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"><p dir=3D"ltr">Why 3? Do we have a version 2=
?</p></blockquote>I meant whatever the next version is, so you are right, i=
t&#39;s version 2. <br></div><div class=3D"gmail_quote"><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">
<p dir=3D"ltr">As for doing it in serialization, that would alter the txid =
making it a hard fork change.</p></blockquote><div>The change is backwards =
compatible (since there is no restrictions on sequence numbers).=C2=A0=C2=
=A0 This makes it a soft fork.<br><br>That doesn&#39;t change the fact that=
 you are changing what a field in the transaction represents.<br><br></div>=
<div>You could say that the sequence number is no longer encoded in the ser=
ialization, it is assumed to be 0xFFFFFFFF for all version 2+ transactions =
and the relative locktime is a whole new field that is the same size (and p=
osition).<br><br></div><div>I think keeping some of the bytes for other use=
s is a good idea.=C2=A0 The entire top 2 bytes could be ignored when workin=
g out relative locktime verify.=C2=A0 That leaves them fully free to be set=
 to anything.=C2=A0 <br><br>It could be that if the MSB of the bottom 2 byt=
es is set, then that activates the rule and the top 2 bytes are ignored.<br=
><br></div><div>Are there any use-cases which need a RLTV of more than 8191=
 blocks delay (that can&#39;t be covered by the absolute version)?=C2=A0 <b=
r></div></div></div></div>

--001a1139594ec0ac55051725dd3e--