From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id AB479C0878 for ; Tue, 26 Nov 2019 01:50:57 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 94C3C85F96 for ; Tue, 26 Nov 2019 01:50:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yi6fMe98-9U0 for ; Tue, 26 Nov 2019 01:50:56 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by whitealder.osuosl.org (Postfix) with ESMTPS id 6000985F8E for ; Tue, 26 Nov 2019 01:50:56 +0000 (UTC) Received: from mail-io1-f50.google.com (mail-io1-f50.google.com [209.85.166.50]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id xAQ1oqCE018775 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 25 Nov 2019 20:50:53 -0500 Received: by mail-io1-f50.google.com with SMTP id k13so18635705ioa.9 for ; Mon, 25 Nov 2019 17:50:53 -0800 (PST) X-Gm-Message-State: APjAAAWo7HGlzVyv2jdVaH/6bFbsopFNuJr9mKj87bZ9n1rbmzkdH3R9 mrijMhYVMFXIFIW7alYneVPHkNxPrgfLzgYllb0= X-Google-Smtp-Source: APXvYqzfpDbyf8WNGxQW+vnGajR+UKbXAVpMm4SkabnZLTszaEMH/yOJMP4TT1LtjzL5opm/y/AfUF1A58+0iaArJWw= X-Received: by 2002:a5d:9555:: with SMTP id a21mr19866571ios.49.1574733052020; Mon, 25 Nov 2019 17:50:52 -0800 (PST) MIME-Version: 1.0 From: Jeremy Date: Mon, 25 Nov 2019 17:50:40 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Bitcoin development mailing list Content-Type: multipart/alternative; boundary="0000000000002e8d260598361cd0" Subject: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2019 01:50:57 -0000 --0000000000002e8d260598361cd0 Content-Type: text/plain; charset="UTF-8" Bitcoin Developers, Pleased to announce refinements to the BIP draft for OP_CHECKTEMPLATEVERIFY (replaces previous OP_SECURETHEBAG BIP). Primarily: 1) Changed the name to something more fitting and acceptable to the community 2) Changed the opcode specification to use the argument off of the stack with a primitive constexpr/literal tracker rather than script lookahead 3) Permits future soft-fork updates to loosen or remove "constexpr" restrictions 4) More detailed comparison to alternatives in the BIP, and why OP_CHECKTEMPLATEVERIFY should be favored even if a future technique may make it semi-redundant. Please see: BIP: https://github.com/JeremyRubin/bips/blob/ctv/bip-ctv.mediawiki Reference Implementation: https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify I believe this addresses all outstanding feedback on the design of this opcode, unless there are any new concerns with these changes. I'm also planning to host a review workshop in Q1 2020, most likely in San Francisco. Please fill out the form here https://forms.gle/pkevHNj2pXH9MGee9 if you're interested in participating (even if you can't physically attend). And as a "but wait, there's more": 1) RPC functions are under preliminary development, to aid in testing and evaluation of OP_CHECKTEMPLATEVERIFY. The new command `sendmanycompacted` shows one way to use OP_CHECKTEMPLATEVERIFY. See: https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify-rpcs. `sendmanycompacted` is still under early design. Standard practices for using OP_CHECKTEMPLATEVERIFY & wallet behaviors may be codified into a separate BIP. This work generalizes even if an alternative strategy is used to achieve the scalability techniques of OP_CHECKTEMPLATEVERIFY. 2) Also under development are improvements to the mempool which will, in conjunction with improvements like package relay, help make it safe to lift some of the mempool's restrictions on longchains specifically for OP_CHECKTEMPLATEVERIFY output trees. See: https://github.com/bitcoin/bitcoin/pull/17268 This work offers an improvement irrespective of OP_CHECKTEMPLATEVERIFY's fate. Neither of these are blockers for proceeding with the BIP, as they are ergonomics and usability improvements needed once/if the BIP is activated. See prior mailing list discussions here: * https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016934.html * https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/016997.html Thanks to the many developers who have provided feedback on iterations of this design. Best, Jeremy -- @JeremyRubin --0000000000002e8d260598361cd0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bitcoin Developers,
=

Pleased to announce refinements to the BIP draft for OP_CHECKTEMPLATEVERIF= Y (replaces previous OP_SECURETHEBAG BIP). Primarily:

1) Changed the = name to something more fitting and acceptable to the community
2) Changed the opcode specification to use th= e argument off of the stack with a primitive constexpr/literal tracker rath= er than script lookahead
3) Permits f= uture soft-fork updates to loosen or remove "constexpr" restricti= ons
4) More detailed comparison to al= ternatives in the BIP, and why OP_CHECKTEMPLATEVERIFY should be favored eve= n if a future technique may make it semi-redundant.

Please see:
BIP: https://github.= com/JeremyRubin/bips/blob/ctv/bip-ctv.mediawiki

I = believe this addresses all outstanding feedback on the design of this opcod= e, unless there are any new concerns with these changes.

I&= #39;m also planning to host a review workshop in Q1 2020, most likely in Sa= n Francisco. Please fill out the form here https://forms.gle/pkevHNj2pXH9MGee9 if you're inter= ested in participating (even if you can't physically attend).
=

And as a "but wait, there's more":

1) = RPC functions are under preliminary development, to aid in testing and eval= uation of OP_CHECKTEMPLATEVERIFY. The new command `sendmanycompacted` shows= one way to use OP_CHECKTEMPLATEVERIFY. See: https:= //github.com/JeremyRubin/bitcoin/tree/checktemplateverify-rpcs. `sendma= nycompacted` is still under early design. Standard practices for using OP_C= HECKTEMPLATEVERIFY & wallet behaviors may be codified into a separate B= IP. This work generalizes even if an alternative strategy is used to achiev= e the scalability techniques of OP_CHECKTEMPLATEVERIFY.
2) Also under development are improvements to the= mempool which will, in conjunction with improvements like package relay, h= elp make it safe to lift some of the mempool's restrictions on longchai= ns specifically for OP_CHECKTEMPLATEVERIFY output trees. See: https://gith= ub.com/bitcoin/bitcoin/pull/17268 This work offers an improvement irres= pective of OP_CHECKTEMPLATEVERIFY's fate.


Neither of these are blockers for proceedi= ng with the BIP, as they are ergonomics and usability improvements needed o= nce/if the BIP is activated.
<= br>

Tha= nks to the many developers who have provided feedback on iterations of this= design.

Best,
Jeremy

--
@JeremyRubin<= a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank">
--0000000000002e8d260598361cd0--