MIME-Version: 1.0
In-Reply-To: <20150427193526.GH5223@muck>
References: <20141001130826.GM28710@savin.petertodd.org>
	<55075795.20904@bluematt.me>
	<20150421075912.GA25282@savin.petertodd.org>
	<CABm2gDo22grffq4j+Jy_HBD-VrROh32Dbseoa=g-5HXA9Uud1w@mail.gmail.com>
	<CABm2gDovFzpL_7KFqPXxhu4VohRfcE5S_PLAUgjgo_b84GaYeQ@mail.gmail.com>
	<20150427193526.GH5223@muck>
Date: Tue, 28 Apr 2015 09:44:14 +0200
Message-ID: <CABm2gDqTz9hDK0auje7OodKS935XFjcR818WsTb6FKDz=qO_SA@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=e89a8f502ee87954ee0514c4077e
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV
	proposal)
Precedence: list

--e89a8f502ee87954ee0514c4077e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Even if it's new and has not received any feedback, I think my solution to
op_maturity is quite clean.
But anyway, yes, the non-relative cltv is much simpler in design and
doesn't have to wait for the other. On the other hand, I would upgrade it
to absolute cltv like you suggested and take the current height as a
parameter to verifyScript instead of using the nLockTime as reference.
If we know we're going to use it for rcltv/op_maturity, better put add soon
rather than later, specially if that will give us a more powerful cltv.
If we don't want that height param, we can leave it out of for op_maturity
too, but that's the wingle decision about rcltv/maturity that affects cltv
so better solve that first.
On Apr 27, 2015 9:35 PM, "Peter Todd" <pete@petertodd.org> wrote:

> On Sun, Apr 26, 2015 at 02:20:04PM +0200, Jorge Tim=C3=B3n wrote:
> > On Sun, Apr 26, 2015 at 1:35 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc> wr=
ote:
> > > And a new softfork rule could enforce that all new CTxIn set nHeight
> > > to the correct height in which its corresponding prevout got into the
> > > chain.
> > > That would remove the need for the TxOutputGetter param in
> > > bitcoinconsensus_verify_script, but unfortunately it is not reorg saf=
e
> > > (apart from other ugly implementation details).
> >
> > Wait, wait, this can be made reorg-safe and more backards compatible.
> > The new validation rule at the tx validation level (currently in
> > main::CheckInputs()) would be
>
> <snip>
>
> So, seems to me that RCLTV opens up a whole rats nest of design
> decisions and compromises that CLTV doesn't. Yet CLTV itself is a big
> step forward, it's been implemented on Viacoin for the past few months
> with no issues found, and has an extremely simple and easy to audit
> implementation.
>
> I think I'm going to argue we implement it as-is in a soft-fork. Pieter
> Wuille's been working on a new way to handle soft-fork upgrades in the
> block nVersion field, so this would be a good opportunity to add
> something simple and well tested, and also make sure the new nVersion
> soft-fork mechanism works. Equally, doing both at the same time ensures
> we don't burn yet another version bit.
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000000e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7
>

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

<p dir=3D"ltr">Even if it&#39;s new and has not received any feedback, I th=
ink my solution to op_maturity is quite clean. <br>
But anyway, yes, the non-relative cltv is much simpler in design and doesn&=
#39;t have to wait for the other. On the other hand, I would upgrade it to =
absolute cltv like you suggested and take the current height as a parameter=
 to verifyScript instead of using the nLockTime as reference.<br>
If we know we&#39;re going to use it for rcltv/op_maturity, better put add =
soon rather than later, specially if that will give us a more powerful cltv=
.<br>
If we don&#39;t want that height param, we can leave it out of for op_matur=
ity too, but that&#39;s the wingle decision about rcltv/maturity that affec=
ts cltv so better solve that first.</p>
<div class=3D"gmail_quote">On Apr 27, 2015 9:35 PM, &quot;Peter Todd&quot; =
&lt;<a href=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>&gt; wrote:=
<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, Apr 26, 201=
5 at 02:20:04PM +0200, Jorge Tim=C3=B3n wrote:<br>
&gt; On Sun, Apr 26, 2015 at 1:35 PM, Jorge Tim=C3=B3n &lt;jtimon@jtimon.cc=
&gt; wrote:<br>
&gt; &gt; And a new softfork rule could enforce that all new CTxIn set nHei=
ght<br>
&gt; &gt; to the correct height in which its corresponding prevout got into=
 the<br>
&gt; &gt; chain.<br>
&gt; &gt; That would remove the need for the TxOutputGetter param in<br>
&gt; &gt; bitcoinconsensus_verify_script, but unfortunately it is not reorg=
 safe<br>
&gt; &gt; (apart from other ugly implementation details).<br>
&gt;<br>
&gt; Wait, wait, this can be made reorg-safe and more backards compatible.<=
br>
&gt; The new validation rule at the tx validation level (currently in<br>
&gt; main::CheckInputs()) would be<br>
<br>
&lt;snip&gt;<br>
<br>
So, seems to me that RCLTV opens up a whole rats nest of design<br>
decisions and compromises that CLTV doesn&#39;t. Yet CLTV itself is a big<b=
r>
step forward, it&#39;s been implemented on Viacoin for the past few months<=
br>
with no issues found, and has an extremely simple and easy to audit<br>
implementation.<br>
<br>
I think I&#39;m going to argue we implement it as-is in a soft-fork. Pieter=
<br>
Wuille&#39;s been working on a new way to handle soft-fork upgrades in the<=
br>
block nVersion field, so this would be a good opportunity to add<br>
something simple and well tested, and also make sure the new nVersion<br>
soft-fork mechanism works. Equally, doing both at the same time ensures<br>
we don&#39;t burn yet another version bit.<br>
<br>
--<br>
&#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org" target=3D"_blank">pet=
ertodd.org</a><br>
00000000000000000e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7<br>
</blockquote></div>

--e89a8f502ee87954ee0514c4077e--