From: Jeremy <jlrubin@mit.edu>
To: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY
Date: Mon, 25 Nov 2019 17:50:40 -0800 [thread overview]
Message-ID: <CAD5xwhjXidpeLLUr4TO30t7U3z_zUxTpU9GBpLxu3MWX3ZFeTA@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2659 bytes --]
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 <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
[-- Attachment #2: Type: text/html, Size: 7629 bytes --]
next reply other threads:[~2019-11-26 1:50 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-26 1:50 Jeremy [this message]
2019-11-27 21:32 ` [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY Russell O'Connor
2019-11-28 19:59 ` Jeremy
2019-12-11 0:37 ` Jeremy
2019-12-13 23:06 ` Jeremy
2019-12-19 20:08 ` Jeremy
[not found] ` <20191214122546.5e72eb93@simplexum.com>
[not found] ` <CAD5xwhgwhOwuPjKz-0_y7HP=jTi=6wJo8uH6HqCvOndr6wo0+Q@mail.gmail.com>
2020-02-14 11:18 ` Dmitry Petukhov
2020-02-14 19:16 ` Jeremy
2020-09-03 14:42 ` Dmitry Petukhov
2020-09-03 17:34 ` Jeremy
2020-09-03 17:47 ` Jeremy
2020-02-15 0:24 ` ZmnSCPxj
2020-06-07 16:51 ` Joachim Strömbergson
2020-06-07 22:45 ` Jeremy
2020-06-08 6:05 ` Dmitry Petukhov
2020-06-08 6:43 ` [bitcoin-dev] [was BIP OP_CHECKTEMPLATEVERIFY] Fee Bumping Operation Jeremy
2020-06-08 7:15 ` Dmitry Petukhov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAD5xwhjXidpeLLUr4TO30t7U3z_zUxTpU9GBpLxu3MWX3ZFeTA@mail.gmail.com \
--to=jlrubin@mit.edu \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox