path: root/93/6236728e730a334899fdedfca961ea64a2de68

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <tier.nolan@gmail.com>) id 1YzoL6-0000Hr-KX
	for bitcoin-development@lists.sourceforge.net;
	Tue, 02 Jun 2015 15:42:52 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.220.181 as permitted sender)
	client-ip=209.85.220.181; envelope-from=tier.nolan@gmail.com;
	helo=mail-qk0-f181.google.com; 
Received: from mail-qk0-f181.google.com ([209.85.220.181])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1YzoL4-0003UV-Um
	for bitcoin-development@lists.sourceforge.net;
	Tue, 02 Jun 2015 15:42:52 +0000
Received: by qkoo18 with SMTP id o18so103179976qko.1
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 02 Jun 2015 08:42:45 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.55.19.82 with SMTP id d79mr49108795qkh.21.1433259765541;
	Tue, 02 Jun 2015 08:42:45 -0700 (PDT)
Received: by 10.140.85.241 with HTTP; Tue, 2 Jun 2015 08:42:45 -0700 (PDT)
In-Reply-To: <CABHVRKSXdtJvp_FY=OHQ2ZAGWTRMP4XdSzUeOij__47aQPSVag@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>
	<CABHVRKSXdtJvp_FY=OHQ2ZAGWTRMP4XdSzUeOij__47aQPSVag@mail.gmail.com>
Date: Tue, 2 Jun 2015 16:42:45 +0100
Message-ID: <CAE-z3OU9yDMV7GhFgZECON47wDL8aV6Ri8kaxOEtP4BF4TmD1A@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a114008ca32307f05178acb35
X-Spam-Score: 3.3 (+++)
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
	(tier.nolan[at]gmail.com)
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.2 MISSING_HEADERS        Missing To: header
	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
	2.7 MALFORMED_FREEMAIL Bad headers on message from free email service
X-Headers-End: 1YzoL4-0003UV-Um
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 15:42:52 -0000

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

I am glad to see the transaction version number increase.  The commit
doesn't update the default transaction version though.  The node would
still produce version 1 transactions.

Does the reference client already produce transactions with final sequence
numbers?  If so, then they will be valid version 2 transactions.  If it
sets the sequence to all zeros, then it won't trigger the new code either.
I think simply bumping the default version number to 2 would be safe.

For the timestamp locktime, median block time would be better than raw
block time.  Median time is the median timestamp of the previous 11
blocks.  This reduces the incentive to mess with the timestamp.  Median
time is earlier than block time, but since things are relative, it should
balance out.

Miners have around 2 hours worth of flexibility when setting the
timestamps, so it may not be that big a deal.



On Tue, Jun 2, 2015 at 5:34 AM, Stephen Morse <stephencalebmorse@gmail.com>
wrote:

> 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
>>>>
>>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

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

<div dir=3D"ltr"><div><div><div>I am glad to see the transaction version nu=
mber increase.=C2=A0 The commit doesn&#39;t update the default transaction =
version though.=C2=A0 The node would still produce version 1 transactions.<=
br><br></div>Does the reference client already produce transactions with fi=
nal sequence numbers?=C2=A0 If so, then they will be valid version 2 transa=
ctions.=C2=A0 If it sets the sequence to all zeros, then it won&#39;t trigg=
er the new code either.=C2=A0 I think simply bumping the default version nu=
mber to 2 would be safe.<br><br></div>For the timestamp locktime, median bl=
ock time would be better than raw block time.=C2=A0 Median time is the medi=
an timestamp of the previous 11 blocks.=C2=A0 This reduces the incentive to=
 mess with the timestamp.=C2=A0 Median time is earlier than block time, but=
 since things are relative, it should balance out.<br><br></div><div>Miners=
 have around 2 hours worth of flexibility when setting the timestamps, so i=
t may not be that big a deal.<br></div><div><div><div><br><br></div></div><=
/div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue=
, Jun 2, 2015 at 5:34 AM, Stephen Morse <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:stephencalebmorse@gmail.com" target=3D"_blank">stephencalebmorse@gmail=
.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r">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 co=
rresponds to at least the sequence specified by the stack value. Good idea!=
 Keeps the script code from depending on external chain specific data, whic=
h is nice.=C2=A0<div><br></div><div>Hopefully we can repurpose one of the O=
P_NOPs for CHECKLOCKTIMEVERIFY and one for OP_CHECKSEQUENCEVERIFY. Very com=
plementary.=C2=A0</div><div><br></div><div>Best,<br>Stephen</div><div><br><=
/div></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_extr=
a"><br><div class=3D"gmail_quote">On Tue, Jun 2, 2015 at 12:16 AM, Mark Fri=
edenbach <span dir=3D"ltr">&lt;<a href=3D"mailto:mark@friedenbach.org" targ=
et=3D"_blank">mark@friedenbach.org</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div><div>You are correct! I am maintainin=
g a &#39;checksequenceverify&#39; branch in my git repository as well, an O=
P_RCLTV using sequence numbers:<br><br><a href=3D"https://github.com/maaku/=
bitcoin/tree/checksequenceverify" target=3D"_blank">https://github.com/maak=
u/bitcoin/tree/checksequenceverify</a><br><br></div>Most of the interesting=
 use cases for relative lock-time require an RCLTV opcode. What is interest=
ing about this architecture is that it possible to cleanly separate the rel=
ative lock-time (sequence numbers) from the RCLTV opcode (OP_CHECKSEQUENCEV=
ERIFY) both in concept and in implementation. Like CLTV, the CSV opcode onl=
y checks transaction data and requires no contextual knowledge about block =
headers, a weakness of the other RCLTV proposals that violate the clean sep=
aration between libscript and libconsensus. In a similar way, this BIP prop=
osal only touches the transaction validation logic without any impact to sc=
ript.<br><br></div>I would like to propose an additional BIP covering the C=
HECKSEQUENCEVERIFY opcode and its enabling applications. But, well, one thi=
ng at a time.<br></div><div><div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Mon, Jun 1, 2015 at 8:45 PM, Stephen Morse <span dir=3D=
"ltr">&lt;<a href=3D"mailto:stephencalebmorse@gmail.com" target=3D"_blank">=
stephencalebmorse@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div dir=3D"ltr">Hi Mark,<br><br>Overall, I like this idea in ever=
y 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 being imp=
lemented.=C2=A0<div><br></div><div>In use cases such as micropayment channe=
ls where the funds are locked up by multiple parties, the enforcement of th=
e relative locktime can be done by the first-signing party. So, while your =
solution would probably work in cases like this, where multiple signing par=
ties are involved, there may be other, seen or unforeseen, use cases that r=
equire 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 nSequence a=
nd 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 constructive cr=
iticism, I do think this is an innovative idea. In my view, though, it seem=
s to be less fully-featured than just repurposing an <font face=3D"monospac=
e, monospace">OP_NOP</font> to create <font face=3D"monospace, monospace">O=
P_RCLTV</font>. The benefits are obviously that it saves transaction space =
by repurposing unused space, and would likely work for most cases where 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_extra"><=
br><div class=3D"gmail_quote"><div><div>On Mon, Jun 1, 2015 at 9:49 PM, Mar=
k 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></di=
v><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 have wri=
tten a reference implementation and BIP draft for a soft-fork change to the=
 consensus-enforced behaviour of sequence numbers for the purpose of suppor=
ting transaction replacement via per-input relative lock-times. This propos=
al was previously discussed on the mailing list in the following thread:<br=
><br><a href=3D"http://sourceforge.net/p/bitcoin/mailman/message/34146752/"=
 target=3D"_blank">http://sourceforge.net/p/bitcoin/mailman/message/3414675=
2/</a><br><br></div><div>In short summary, this proposal seeks to enable sa=
fe transaction replacement by re-purposing the nSequence field of a transac=
tion input to be a consensus-enforced relative lock-time.<br><br>The advant=
ages 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 tha=
n a boolean control over absolute nLockTime, and it does so in a way that i=
s semantically compatible with the originally envisioned use of sequence nu=
mbers for fast mempool transaction replacement.<br><br></div><div>The disad=
vantages are that external constraints often prevent the full range of sequ=
ence 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 c=
ontexts. The latter point has been partially addressed by having the relati=
ve lock-time semantics be enforced only if the most-significant bit of nSeq=
uence 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 can be =
found at the following gist:<br><br><a href=3D"https://gist.github.com/maak=
u/be15629fe64618b14f5a" target=3D"_blank">https://gist.github.com/maaku/be1=
5629fe64618b14f5a</a><br><br></div><div>The reference implementation is ava=
ilable at the following git repository:<br></div><div><br><a href=3D"https:=
//github.com/maaku/bitcoin/tree/sequencenumbers" target=3D"_blank">https://=
github.com/maaku/bitcoin/tree/sequencenumbers</a><br><br></div><div>I reque=
st that the BIP editor please assign a BIP number for this work.<br><br></d=
iv><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>
</div></div><br>-----------------------------------------------------------=
-------------------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@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>

--001a114008ca32307f05178acb35--