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 <btcdrak@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>; 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: <CABm2gDqVu9OqNpOgCa6hMw3CXp7ePWTaAGPtMq4T9rG658K=ow@mail.gmail.com> References: <20150504050715.GA18856@savin.petertodd.org> <CADJgMzs3D=6pNOQhU3ubi6=C8javRtwL0VuGFWvU+6SiuB0YWg@mail.gmail.com> <20150509091201.GA15088@savin.petertodd.org> <CABm2gDqVu9OqNpOgCa6hMw3CXp7ePWTaAGPtMq4T9rG658K=ow@mail.gmail.com> From: Btc Drak <btcdrak@gmail.com> Date: Tue, 12 May 2015 20:30:35 +0100 Message-ID: <CADJgMzv1NdoXKDScQ1+OycijzME=W2YSut3GMF=EEuKQf6VeUg@mail.gmail.com> To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc> 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 <bitcoin-development@lists.sourceforge.net> 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: <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, 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 <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 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 <jtimon@jtimon.cc> 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 <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: > >> > > >> > <nLockTime> 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: > >> > > >> > <relative nLockTime> 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 <div dir=3D"ltr">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.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue,= May 12, 2015 at 8:16 PM, Jorge Tim=C3=B3n <span dir=3D"ltr"><<a href=3D= "mailto:jtimon@jtimon.cc" target=3D"_blank">jtimon@jtimon.cc</a>></span>= wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor= der-left:1px #ccc solid;padding-left:1ex">This saves us ocodes for later bu= t it's uglier and produces slightly<br> bigger scripts.<br> If we're convinced it's worth it, seems like the right way to do it= ,<br> and certainly cltv and rclv/op_maturity are related.<br> But let's not forget that we can always use this same trick with the<br= > last opcode to get 2^64 brand new opcodes.<br> So I'm not convinced at all on whether we want=C2=A0 #5496 or #6124.<br= > But it would be nice to decide and stop blocking=C2=A0 this.<br> <div class=3D"HOEnZb"><div class=3D"h5"><br> On Sat, May 9, 2015 at 11:12 AM, Peter Todd <<a href=3D"mailto:pete@pete= rtodd.org">pete@petertodd.org</a>> wrote:<br> > On Tue, May 05, 2015 at 01:54:33AM +0100, Btc Drak wrote:<br> >> > That said, if people have strong feelings about this, I would= be willing<br> >> > to make OP_CLTV work as follows:<br> >> ><br> >> >=C2=A0 =C2=A0 =C2=A0<nLockTime> 1 OP_CLTV<br> >> ><br> >> > Where the 1 selects absolute mode, and all others act as OP_N= OP's. A<br> >> > future relative CLTV could then be a future soft-fork impleme= nted as<br> >> > follows:<br> >> ><br> >> >=C2=A0 =C2=A0 =C2=A0<relative nLockTime> 2 OP_CLTV<br> >> ><br> >> > On the bad side it'd be two or three days of work to rewr= ite all the<br> >> > existing tests and example code and update the BIP, and (slig= htly) gets<br> >> > us away from the well-tested existing implementation. It also= may<br> >> > complicate the codebase compared to sticking with just doing = a Script<br> >> > v2.0, with the additional execution environment data required= for v2.0<br> >> > scripts cleanly separated out. But all in all, the above isn&= #39;t too big<br> >> > of a deal.<br> >><br> >><br> >> Adding a parameter to OP_CLTV makes it much more flexible and is t= he most<br> >> economic use of precious NOPs.<br> >> The extra time required is ok and it would be good to make this ch= ange to<br> >> the PR in time for the feature freeze.<br> ><br> > Done!<br> ><br> > <a href=3D"https://github.com/bitcoin/bitcoin/pull/5496#issuecomment-1= 00454263" target=3D"_blank">https://github.com/bitcoin/bitcoin/pull/5496#is= suecomment-100454263</a><br> ><br> > --<br> > 'peter'[:-1]@<a href=3D"http://petertodd.org" target=3D"_blank= ">petertodd.org</a><br> > 000000000000000012c438a597ad15df697888be579f4f818a30517cd60fbdc8<br> ><br> </div></div><div class=3D"HOEnZb"><div class=3D"h5">> ------------------= ------------------------------------------------------------<br> > One dashboard for servers and applications across Physical-Virtual-Clo= ud<br> > Widest out-of-the-box monitoring support with 50+ applications<br> > Performance metrics, stats and reports that give you Actionable Insigh= ts<br> > Deep dive visibility with transaction tracing using APM Insight.<br> > <a href=3D"http://ad.doubleclick.net/ddm/clk/290420510;117567292;y" ta= rget=3D"_blank">http://ad.doubleclick.net/ddm/clk/290420510;117567292;y</a>= <br> > _______________________________________________<br> > Bitcoin-development mailing list<br> > <a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-d= evelopment@lists.sourceforge.net</a><br> > <a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-develo= pment" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitco= in-development</a><br> ><br> </div></div></blockquote></div><br></div> --20cf307c9fb09021dd0515e78849--