From: Jeremy <jlrubin@mit•edu>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Unlimited covenants, was Re: CHECKSIGFROMSTACK/{Verify} BIP for Bitcoin
Date: Tue, 6 Jul 2021 11:36:31 -0700 [thread overview]
Message-ID: <CAD5xwhhm+TejnVV-pxEmE0_msUzXU1njMDbjrYb4vd0Kti-Xkg@mail.gmail.com> (raw)
In-Reply-To: <CAMZUoKkAUodCT+2aQG71xwHYD8KXeTAdQq4NmXZ4GBe0pcD=9A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3233 bytes --]
heh -- I pointed out these evil multisig covenants in 2015 :)
https://medium.com/@jeremyrubin/regulating-bitcoin-by-mining-the-regulator-miner-attack-c8fd51185b78
I'm relatively unconcerned by it except to the extent that mining
centralizes to the point of censoring other traffic.
Overall, I think this is a great conversation to be having.
However, I want to push back on David's claim that "Respecting the
concerns of others doesn't require lobotomizing useful tools.".
CHECKSIGFROMSTACK is a primitive and the opcode is not being nerfed in any
way shape or form. The argument here is that doing CSFS and not CAT is
nerfing CSFS... but CSFS is an independently useful and cool opcode that
has many of it's own merits.
Further, as described in my [blog post](
https://rubin.io/blog/2021/07/02/covenants/), CSFS has very high "design
specificity"... that is there's not *that* many design choices that could
possibly go into it. It's checking a signature. From the stack. That's all
folks! There are no design compromises in it. No lobotomy.
OP_CAT is more or less completely unrelated to CSFS. As Andrew has
[demonstrated](
https://www.wpsoftware.net/andrew/blog/cat-and-schnorr-tricks-i.html),
*just* OP_CAT alone (no CSFS) gives you covenants (albeit in a hacky way)
with Schnorr.
I think roconnor agrees that CAT(+CSFS?) are not really a "fantastic" way
to do covenants, that there are more direct approaches that will be better
or neccessary such as TWEAK or UPDATETAPLEAF. Let's work on those! But
let's also not hold up progress on other useful things while those are
brewing.
Non-Redundancy should be a non-goal for script -- although we strive to be
minimal, redundancy is inevitable. For example, OP_SWAP has identical
semantics to <1> ROLL, but SWAP is a common enough use that it is pragmatic
to assign it an opcode and OP_ROLL does something distinctly enhanced.
Similarly, even if we add CAT we will surely come up with saner ways to
implement covenant logic than Andrew's Schnorr tricks.
CTV in particular is designed to be a part of that story -- enough
functionality w/o OP_CAT to work *today* and serve a purpose long into the
future, but with OP_CAT (or shastream preferably) enhances it's
functionality in a useful way and with introspection opcodes (perhaps like
those being developed by elements) further gains functionality. Perhaps the
functionality available today will be redundant with a future way of doing
things, but we can only see so far into the future. However, we can see
that there are good things to build with it today.
It's the inverse of a lobotomy. Independent components that can come
together for a newer greater purpose rather than parts being torn apart
irreparably.
In the future when we have specific use cases in mind that *aren't* served
well (either efficiently or at all) by the existing primitives, it's
completely acceptable to add something new even if it makes an existing
feature redundant. APO, for example, will be redundant (afaict) will Glen
Willen's [Bitmask SigHash Flags](
https://bc-2.jp/archive/season2/materials/0203_NewElementsFeaturesEn.pdf)
should we ever get those.
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
[-- Attachment #2: Type: text/html, Size: 6640 bytes --]
next prev parent reply other threads:[~2021-07-06 18:36 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-07-03 16:31 [bitcoin-dev] " Jeremy
2021-07-03 17:50 ` Russell O'Connor
2021-07-03 18:30 ` Jeremy
2021-07-03 20:12 ` Russell O'Connor
2021-07-04 17:30 ` Jeremy
2021-07-04 19:03 ` Russell O'Connor
2021-07-06 17:54 ` Jeremy
2021-07-06 18:21 ` Russell O'Connor
2021-07-06 18:53 ` Jeremy
2021-07-04 1:13 ` David A. Harding
2021-07-04 18:39 ` Jeremy
2021-07-04 20:32 ` [bitcoin-dev] Unlimited covenants, was " David A. Harding
2021-07-04 20:50 ` Billy Tetrud
2021-07-05 0:50 ` ZmnSCPxj
2021-07-05 1:02 ` Russell O'Connor
2021-07-05 2:10 ` Russell O'Connor
2021-07-05 2:39 ` ZmnSCPxj
2021-07-05 5:04 ` Anthony Towns
2021-07-05 13:46 ` Matt Corallo
2021-07-05 13:51 ` Greg Sanders
2022-02-03 6:17 ` Anthony Towns
2021-07-05 17:20 ` Russell O'Connor
2021-07-06 6:25 ` Billy Tetrud
2021-07-06 10:20 ` Sanket Kanjalkar
2021-07-06 11:26 ` Russell O'Connor
2021-07-06 18:36 ` Jeremy [this message]
2021-07-07 4:26 ` ZmnSCPxj
2021-07-07 6:12 ` Billy Tetrud
2021-07-07 13:12 ` Russell O'Connor
2021-07-07 14:24 ` Russell O'Connor
2021-07-07 17:26 ` Jeremy
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=CAD5xwhhm+TejnVV-pxEmE0_msUzXU1njMDbjrYb4vd0Kti-Xkg@mail.gmail.com \
--to=jlrubin@mit$(echo .)edu \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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