Jeremy [ARCHIVE] on Nostr: 📅 Original date posted:2021-07-06 📝 Original message:heh -- I pointed out these ...
📅 Original date posted:2021-07-06
📝 Original message: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>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210706/4bf5525a/attachment.html>;
📝 Original message: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>;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210706/4bf5525a/attachment.html>;