From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Yn0Br-0002jx-G4 for bitcoin-development@lists.sourceforge.net; Tue, 28 Apr 2015 07:44:23 +0000 Received: from mail-wg0-f44.google.com ([74.125.82.44]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Yn0Bp-0007mH-CM for bitcoin-development@lists.sourceforge.net; Tue, 28 Apr 2015 07:44:23 +0000 Received: by wgin8 with SMTP id n8so141205055wgi.0 for ; Tue, 28 Apr 2015 00:44:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=r/YotED90W5QlJvBy6MVIOVXYDxeTNevWjC2mX01bDE=; b=RGow2hgRRfCNTcHJoSroiGyKwgYxUOcprgUyZcXliEMYAlREfuVnWtLZ1u69CcY6lh DZwnd71sRwaLyA9wzR4l+e0piO4C3mnVAc3pGOY/yDA9Q3LdEpP0mQ13XBvz6u3UJ7L8 50+4k5TSyS8PfPtvbQVDwGWAhlkP4Z7riSnEIeQ6BJU3y2xm1v4+8msmEMvIPy/F9uES Zu0E+cQw4NuzAquMo0TDUiYlyEeJtT5eic6GYTl5WknjSTbN3HR8MF71VkMp6wALLawe SGwLojI3fKIIAj+C6tgursEVunt5Yx33DcaRKVMdffiRcFxip35IAoxjbAwcLxSKCbtJ hkAQ== X-Gm-Message-State: ALoCoQnaTB1WahQpkefd7R65p0C7hbcTBk2Y/60Xl9myR7gJoJOr13wtvHtkuA3y4miuITKZ0aNg MIME-Version: 1.0 X-Received: by 10.180.37.73 with SMTP id w9mr27239615wij.7.1430207055085; Tue, 28 Apr 2015 00:44:15 -0700 (PDT) Received: by 10.194.124.2 with HTTP; Tue, 28 Apr 2015 00:44:14 -0700 (PDT) Received: by 10.194.124.2 with HTTP; Tue, 28 Apr 2015 00:44:14 -0700 (PDT) In-Reply-To: <20150427193526.GH5223@muck> References: <20141001130826.GM28710@savin.petertodd.org> <55075795.20904@bluematt.me> <20150421075912.GA25282@savin.petertodd.org> <20150427193526.GH5223@muck> Date: Tue, 28 Apr 2015 09:44:14 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Peter Todd Content-Type: multipart/alternative; boundary=e89a8f502ee87954ee0514c4077e X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1Yn0Bp-0007mH-CM Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal) X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2015 07:44:23 -0000 --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" 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 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 > > > > 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

Even if it's new and has not received any feedback, I th= ink my solution to op_maturity is quite clean.
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.
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_matur= ity too, but that's the wingle decision about rcltv/maturity that affec= ts cltv so better solve that first.

On Apr 27, 2015 9:35 PM, "Peter Todd" = <pete@petertodd.org> wrote:=
On Sun, Apr 26, 201= 5 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= > wrote:
> > And a new softfork rule could enforce that all new CTxIn set nHei= ght
> > 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= safe
> > (apart from other ugly implementation details).
>
> Wait, wait, this can be made reorg-safe and more backards compatible.<= br> > 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<= br> 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<= br> 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]@pet= ertodd.org
00000000000000000e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7
--e89a8f502ee87954ee0514c4077e--