path: root/ca/f4bfc833d15626852ffd31343ca113cebb6f26

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <stephencalebmorse@gmail.com>) id 1YzduT-0000A2-Gk
	for bitcoin-development@lists.sourceforge.net;
	Tue, 02 Jun 2015 04:34:41 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.160.173 as permitted sender)
	client-ip=209.85.160.173;
	envelope-from=stephencalebmorse@gmail.com;
	helo=mail-yk0-f173.google.com; 
Received: from mail-yk0-f173.google.com ([209.85.160.173])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YzduS-0006LN-1E
	for bitcoin-development@lists.sourceforge.net;
	Tue, 02 Jun 2015 04:34:41 +0000
Received: by yken206 with SMTP id n206so50234585yke.2
	for <bitcoin-development@lists.sourceforge.net>;
	Mon, 01 Jun 2015 21:34:34 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.45.2 with SMTP id o2mr26388912yhb.194.1433219674556;
	Mon, 01 Jun 2015 21:34:34 -0700 (PDT)
Received: by 10.13.245.70 with HTTP; Mon, 1 Jun 2015 21:34:34 -0700 (PDT)
In-Reply-To: <CAOG=w-tDdJTkkqGaEEpDZ6pX0kXT7f2wvoN_cEpd6+MVnu1CdQ@mail.gmail.com>
References: <CAOG=w-uufDPkQSEi1K_L82j4OXObGmESnfYyxi1z99fcBCotcg@mail.gmail.com>
	<CABHVRKQD4YPt0NA8VnXW4VYx0fmCgSHUYq-73F2esHZqX-FUxw@mail.gmail.com>
	<CAOG=w-tDdJTkkqGaEEpDZ6pX0kXT7f2wvoN_cEpd6+MVnu1CdQ@mail.gmail.com>
Date: Tue, 2 Jun 2015 00:34:34 -0400
Message-ID: <CABHVRKSXdtJvp_FY=OHQ2ZAGWTRMP4XdSzUeOij__47aQPSVag@mail.gmail.com>
From: Stephen Morse <stephencalebmorse@gmail.com>
To: Mark Friedenbach <mark@friedenbach.org>
Content-Type: multipart/alternative; boundary=089e0122f52e964ef605178175d4
X-Spam-Score: -0.6 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(stephencalebmorse[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YzduS-0006LN-1E
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [BIP draft] Consensus-enforced
 transaction replacement signalled 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: Tue, 02 Jun 2015 04:34:41 -0000

--089e0122f52e964ef605178175d4
Content-Type: text/plain; charset=UTF-8

I see, so OP_SEQUENCEVERIFY will have a value pushed on the stack right
before, and then check that the input spending the prevout has nSequence
corresponds to at least the sequence specified by the stack value. Good
idea! Keeps the script code from depending on external chain specific data,
which is nice.

Hopefully we can repurpose one of the OP_NOPs for CHECKLOCKTIMEVERIFY and
one for OP_CHECKSEQUENCEVERIFY. Very complementary.

Best,
Stephen


On Tue, Jun 2, 2015 at 12:16 AM, Mark Friedenbach <mark@friedenbach.org>
wrote:

> You are correct! I am maintaining a 'checksequenceverify' branch in my git
> repository as well, an OP_RCLTV using sequence numbers:
>
> https://github.com/maaku/bitcoin/tree/checksequenceverify
>
> Most of the interesting use cases for relative lock-time require an RCLTV
> opcode. What is interesting about this architecture is that it possible to
> cleanly separate the relative lock-time (sequence numbers) from the RCLTV
> opcode (OP_CHECKSEQUENCEVERIFY) both in concept and in implementation. Like
> CLTV, the CSV opcode only checks transaction data and requires no
> contextual knowledge about block headers, a weakness of the other RCLTV
> proposals that violate the clean separation between libscript and
> libconsensus. In a similar way, this BIP proposal only touches the
> transaction validation logic without any impact to script.
>
> I would like to propose an additional BIP covering the CHECKSEQUENCEVERIFY
> opcode and its enabling applications. But, well, one thing at a time.
>
> On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse <stephencalebmorse@gmail.com
> > wrote:
>
>> Hi Mark,
>>
>> Overall, I like this idea in every way except for one: unless I am
>> missing something, we may still need an OP_RCLTV even with this being
>> implemented.
>>
>> In use cases such as micropayment channels where the funds are locked up
>> by multiple parties, the enforcement of the relative locktime can be done
>> by the first-signing party. So, while your solution would probably work in
>> cases like this, where multiple signing parties are involved, there may be
>> other, seen or unforeseen, use cases that require putting the relative
>> locktime right into the spending contract (the scriptPubKey itself).
>> When there is only one signer, there's nothing that enforces using an
>> nSequence and nVersion=2 that would prevent spending the output until a
>> certain time.
>>
>> I hope this is received as constructive criticism, I do think this is an
>> innovative idea. In my view, though, it seems to be less fully-featured
>> than just repurposing an OP_NOP to create OP_RCLTV. The benefits are
>> obviously that it saves transaction space by repurposing unused space, and
>> would likely work for most cases where an OP_RCLTV would be needed.
>>
>> Best,
>> Stephen
>>
>> On Mon, Jun 1, 2015 at 9:49 PM, Mark Friedenbach <mark@friedenbach.org>
>> wrote:
>>
>>> I have written a reference implementation and BIP draft for a soft-fork
>>> change to the consensus-enforced behaviour of sequence numbers for the
>>> purpose of supporting transaction replacement via per-input relative
>>> lock-times. This proposal was previously discussed on the mailing list in
>>> the following thread:
>>>
>>> http://sourceforge.net/p/bitcoin/mailman/message/34146752/
>>>
>>> In short summary, this proposal seeks to enable safe transaction
>>> replacement by re-purposing the nSequence field of a transaction input to
>>> be a consensus-enforced relative lock-time.
>>>
>>> The advantages of this approach is that it makes use of the full range
>>> of the 32-bit sequence number which until now has rarely been used for
>>> anything other than a boolean control over absolute nLockTime, and it does
>>> so in a way that is semantically compatible with the originally envisioned
>>> use of sequence numbers for fast mempool transaction replacement.
>>>
>>> The disadvantages are that external constraints often prevent the full
>>> range of sequence numbers from being used when interpreted as a relative
>>> lock-time, and re-purposing nSequence as a relative lock-time precludes its
>>> use in other contexts. The latter point has been partially addressed by
>>> having the relative lock-time semantics be enforced only if the
>>> most-significant bit of nSequence is set. This preserves 31 bits for
>>> alternative use when relative lock-times are not required.
>>>
>>> The BIP draft can be found at the following gist:
>>>
>>> https://gist.github.com/maaku/be15629fe64618b14f5a
>>>
>>> The reference implementation is available at the following git
>>> repository:
>>>
>>> https://github.com/maaku/bitcoin/tree/sequencenumbers
>>>
>>> I request that the BIP editor please assign a BIP number for this work.
>>>
>>> Sincerely,
>>> Mark Friedenbach
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> Bitcoin-development mailing list
>>> Bitcoin-development@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>>
>>>
>>
>

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

<div dir=3D"ltr">I see, so OP_SEQUENCEVERIFY will have a value pushed on th=
e stack right before, and then check that the input spending the prevout ha=
s nSequence corresponds to at least the sequence specified by the stack val=
ue. Good idea! Keeps the script code from depending on external chain speci=
fic data, which is nice.=C2=A0<div><br></div><div>Hopefully we can repurpos=
e one of the OP_NOPs for CHECKLOCKTIMEVERIFY and one for OP_CHECKSEQUENCEVE=
RIFY. Very complementary.=C2=A0</div><div><br></div><div>Best,<br>Stephen</=
div><div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail=
_quote">On Tue, Jun 2, 2015 at 12:16 AM, Mark Friedenbach <span dir=3D"ltr"=
>&lt;<a href=3D"mailto:mark@friedenbach.org" target=3D"_blank">mark@frieden=
bach.org</a>&gt;</span> wrote:<br><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><div>You are correct! I am maintaining a &#39;checksequenceve=
rify&#39; branch in my git repository as well, an OP_RCLTV using sequence n=
umbers:<br><br><a href=3D"https://github.com/maaku/bitcoin/tree/checksequen=
ceverify" target=3D"_blank">https://github.com/maaku/bitcoin/tree/checksequ=
enceverify</a><br><br></div>Most of the interesting use cases for relative =
lock-time require an RCLTV opcode. What is interesting about this architect=
ure is that it possible to cleanly separate the relative lock-time (sequenc=
e numbers) from the RCLTV opcode (OP_CHECKSEQUENCEVERIFY) both in concept a=
nd in implementation. Like CLTV, the CSV opcode only checks transaction dat=
a and requires no contextual knowledge about block headers, a weakness of t=
he other RCLTV proposals that violate the clean separation between libscrip=
t and libconsensus. In a similar way, this BIP proposal only touches the tr=
ansaction validation logic without any impact to script.<br><br></div>I wou=
ld like to propose an additional BIP covering the CHECKSEQUENCEVERIFY opcod=
e and its enabling applications. But, well, one thing at a time.<br></div><=
div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extra"><br><div =
class=3D"gmail_quote">On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse <span d=
ir=3D"ltr">&lt;<a href=3D"mailto:stephencalebmorse@gmail.com" target=3D"_bl=
ank">stephencalebmorse@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr">Hi Mark,<br><br>Overall, I like this idea in=
 every way except for one: unless I am missing something, we may still need=
 an <font face=3D"monospace, monospace">OP_RCLTV</font> even with this bein=
g implemented.=C2=A0<div><br></div><div>In use cases such as micropayment c=
hannels where the funds are locked up by multiple parties, the enforcement =
of the relative locktime can be done by the first-signing party. So, while =
your solution would probably work in cases like this, where multiple signin=
g parties are involved, there may be other, seen or unforeseen, use cases t=
hat require putting the relative locktime right into the spending contract =
(the <font face=3D"monospace, monospace">scriptPubKey</font> itself). When =
there is only one signer, there&#39;s nothing that enforces using an nSeque=
nce and nVersion=3D2 that would prevent spending the output until a certain=
 time.=C2=A0</div><div><br></div><div>I hope this is received as constructi=
ve criticism, I do think this is an innovative idea. In my view, though, it=
 seems to be less fully-featured than just repurposing an <font face=3D"mon=
ospace, monospace">OP_NOP</font> to create <font face=3D"monospace, monospa=
ce">OP_RCLTV</font>. The benefits are obviously that it saves transaction s=
pace by repurposing unused space, and would likely work for most cases wher=
e an <font face=3D"monospace, monospace">OP_RCLTV</font> would be needed.</=
div><div><br></div><div>Best,<br>Stephen</div></div><div class=3D"gmail_ext=
ra"><br><div class=3D"gmail_quote"><div><div>On Mon, Jun 1, 2015 at 9:49 PM=
, Mark Friedenbach <span dir=3D"ltr">&lt;<a href=3D"mailto:mark@friedenbach=
.org" target=3D"_blank">mark@friedenbach.org</a>&gt;</span> wrote:<br></div=
></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div><div><div dir=3D"ltr"><div>I hav=
e written a reference implementation and BIP draft for a soft-fork change t=
o the consensus-enforced behaviour of sequence numbers for the purpose of s=
upporting transaction replacement via per-input relative lock-times. This p=
roposal was previously discussed on the mailing list in the following threa=
d:<br><br><a href=3D"http://sourceforge.net/p/bitcoin/mailman/message/34146=
752/" target=3D"_blank">http://sourceforge.net/p/bitcoin/mailman/message/34=
146752/</a><br><br></div><div>In short summary, this proposal seeks to enab=
le safe transaction replacement by re-purposing the nSequence field of a tr=
ansaction input to be a consensus-enforced relative lock-time.<br><br>The a=
dvantages of this approach is that it makes use of the full range of the 32=
-bit sequence number which until now has rarely been used for anything othe=
r than a boolean control over absolute nLockTime, and it does so in a way t=
hat is semantically compatible with the originally envisioned use of sequen=
ce numbers for fast mempool transaction replacement.<br><br></div><div>The =
disadvantages are that external constraints often prevent the full range of=
 sequence numbers from being used when interpreted as a relative lock-time,=
 and re-purposing nSequence as a relative lock-time precludes its use in ot=
her contexts. The latter point has been partially addressed by having the r=
elative lock-time semantics be enforced only if the most-significant bit of=
 nSequence is set. This preserves 31 bits for alternative use when relative=
 lock-times are not required.<br></div><div><br></div><div>The BIP draft ca=
n be found at the following gist:<br><br><a href=3D"https://gist.github.com=
/maaku/be15629fe64618b14f5a" target=3D"_blank">https://gist.github.com/maak=
u/be15629fe64618b14f5a</a><br><br></div><div>The reference implementation i=
s available at the following git repository:<br></div><div><br><a href=3D"h=
ttps://github.com/maaku/bitcoin/tree/sequencenumbers" target=3D"_blank">htt=
ps://github.com/maaku/bitcoin/tree/sequencenumbers</a><br><br></div><div>I =
request that the BIP editor please assign a BIP number for this work.<br><b=
r></div><div>Sincerely,<br></div><div>Mark Friedenbach<br></div></div>
<br></div></div>-----------------------------------------------------------=
-------------------<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>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--089e0122f52e964ef605178175d4--