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 1YsFtP-0007D0-Ch for bitcoin-development@lists.sourceforge.net; Tue, 12 May 2015 19:31:03 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.216.53 as permitted sender) client-ip=209.85.216.53; envelope-from=btcdrak@gmail.com; helo=mail-vn0-f53.google.com; Received: from mail-vn0-f53.google.com ([209.85.216.53]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YsFtN-0004DS-RQ for bitcoin-development@lists.sourceforge.net; Tue, 12 May 2015 19:31:03 +0000 Received: by vnbf190 with SMTP id f190so1371561vnb.10 for ; Tue, 12 May 2015 12:30:56 -0700 (PDT) X-Received: by 10.52.26.132 with SMTP id l4mr12440932vdg.72.1431459056327; Tue, 12 May 2015 12:30:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.63.5 with HTTP; Tue, 12 May 2015 12:30:35 -0700 (PDT) In-Reply-To: References: <20150504050715.GA18856@savin.petertodd.org> <20150509091201.GA15088@savin.petertodd.org> From: Btc Drak Date: Tue, 12 May 2015 20:30:35 +0100 Message-ID: To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= Content-Type: multipart/alternative; boundary=20cf307c9fb09021dd0515e78849 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 HK_RANDOM_FROM From username looks random -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.6 HK_RANDOM_ENVFROM Envelope sender username looks random 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (btcdrak[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: 1YsFtN-0004DS-RQ Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] CLTV opcode allocation; long-term plans? 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, 12 May 2015 19:31:03 -0000 --20cf307c9fb09021dd0515e78849 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Gavin and @NicolasDorier have a point: If there isn't actually scarcity of NOPs because OP_NOP10 could become OP_EX (if we run out), it makes sense to chose the original unparameterised CLTV version #6124 which also has been better tested. It's cleaner, more readable and results in a slightly smaller script which has also got to be a plus. On Tue, May 12, 2015 at 8:16 PM, Jorge Tim=C3=B3n wrote: > This saves us ocodes for later but it's uglier and produces slightly > bigger scripts. > If we're convinced it's worth it, seems like the right way to do it, > and certainly cltv and rclv/op_maturity are related. > But let's not forget that we can always use this same trick with the > last opcode to get 2^64 brand new opcodes. > So I'm not convinced at all on whether we want #5496 or #6124. > But it would be nice to decide and stop blocking this. > > On Sat, May 9, 2015 at 11:12 AM, Peter Todd wrote: > > On Tue, May 05, 2015 at 01:54:33AM +0100, Btc Drak wrote: > >> > That said, if people have strong feelings about this, I would be > willing > >> > to make OP_CLTV work as follows: > >> > > >> > 1 OP_CLTV > >> > > >> > Where the 1 selects absolute mode, and all others act as OP_NOP's. A > >> > future relative CLTV could then be a future soft-fork implemented as > >> > follows: > >> > > >> > 2 OP_CLTV > >> > > >> > On the bad side it'd be two or three days of work to rewrite all the > >> > existing tests and example code and update the BIP, and (slightly) > gets > >> > us away from the well-tested existing implementation. It also may > >> > complicate the codebase compared to sticking with just doing a Scrip= t > >> > v2.0, with the additional execution environment data required for v2= .0 > >> > scripts cleanly separated out. But all in all, the above isn't too b= ig > >> > of a deal. > >> > >> > >> Adding a parameter to OP_CLTV makes it much more flexible and is the > most > >> economic use of precious NOPs. > >> The extra time required is ok and it would be good to make this change > to > >> the PR in time for the feature freeze. > > > > Done! > > > > https://github.com/bitcoin/bitcoin/pull/5496#issuecomment-100454263 > > > > -- > > 'peter'[:-1]@petertodd.org > > 000000000000000012c438a597ad15df697888be579f4f818a30517cd60fbdc8 > > > > > -------------------------------------------------------------------------= ----- > > One dashboard for servers and applications across Physical-Virtual-Clou= d > > Widest out-of-the-box monitoring support with 50+ applications > > Performance metrics, stats and reports that give you Actionable Insight= s > > Deep dive visibility with transaction tracing using APM Insight. > > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > --20cf307c9fb09021dd0515e78849 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Gavin and @NicolasDorier have a point: If there isn't = actually scarcity of NOPs because OP_NOP10 could become <type> OP_EX = (if we run out), it makes sense to chose the original unparameterised CLTV = version #6124 which also has been better tested. It's cleaner, more rea= dable and results in a slightly smaller script which has also got to be a p= lus.

On Tue,= May 12, 2015 at 8:16 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc>= wrote:
This saves us ocodes for later bu= t it's uglier and produces slightly
bigger scripts.
If we're convinced it's worth it, seems like the right way to do it= ,
and certainly cltv and rclv/op_maturity are related.
But let's not forget that we can always use this same trick with the last opcode to get 2^64 brand new opcodes.
So I'm not convinced at all on whether we want=C2=A0 #5496 or #6124. But it would be nice to decide and stop blocking=C2=A0 this.

On Sat, May 9, 2015 at 11:12 AM, Peter Todd <pete@petertodd.org> wrote:
> On Tue, May 05, 2015 at 01:54:33AM +0100, Btc Drak wrote:
>> > That said, if people have strong feelings about this, I would= be willing
>> > to make OP_CLTV work as follows:
>> >
>> >=C2=A0 =C2=A0 =C2=A0<nLockTime> 1 OP_CLTV
>> >
>> > Where the 1 selects absolute mode, and all others act as OP_N= OP's. A
>> > future relative CLTV could then be a future soft-fork impleme= nted as
>> > follows:
>> >
>> >=C2=A0 =C2=A0 =C2=A0<relative nLockTime> 2 OP_CLTV
>> >
>> > On the bad side it'd be two or three days of work to rewr= ite all the
>> > existing tests and example code and update the BIP, and (slig= htly) gets
>> > us away from the well-tested existing implementation. It also= may
>> > complicate the codebase compared to sticking with just doing = a Script
>> > v2.0, with the additional execution environment data required= for v2.0
>> > scripts cleanly separated out. But all in all, the above isn&= #39;t too big
>> > of a deal.
>>
>>
>> Adding a parameter to OP_CLTV makes it much more flexible and is t= he most
>> economic use of precious NOPs.
>> The extra time required is ok and it would be good to make this ch= ange to
>> the PR in time for the feature freeze.
>
> Done!
>
> https://github.com/bitcoin/bitcoin/pull/5496#is= suecomment-100454263
>
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000012c438a597ad15df697888be579f4f818a30517cd60fbdc8
>
> ------------------= ------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Clo= ud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insigh= ts
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y=
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-d= evelopment@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitco= in-development
>

--20cf307c9fb09021dd0515e78849--