Anthony Towns [ARCHIVE] on Nostr: 📅 Original date posted:2019-05-27 📝 Original message:On Wed, May 22, 2019 at ...
đź“… Original date posted:2019-05-27
📝 Original message:On Wed, May 22, 2019 at 05:01:21PM -0400, Russell O'Connor via bitcoin-dev wrote:
> Bitcoin Script appears designed to be a flexible programmable system that
> provides generic features to be composed to achieve various purposes.
Counterpoint: haven't the flexibly designed parts of script mostly been
a failure -- requiring opcodes to be disabled due to DoS vectors or
consensus bugs, and mostly not being useful in practice where they're
still enabled in BTC or on other chains where they have been re-enabled
(eg, Liquid and BCH)?
> Instead, I propose that, for the time being, we simply implement OP_CAT and
> OP_CHECKSIGFROMSTACKVERIFY.
FWIW, I'd like to see CAT enabled, though I'm less convinced about a
CHECKSIG that takes the message from the stack. I think CAT's plausibly
useful in practice, but a sig against data from the stack seems more
useful in theory than in practice. Has it actually seen use on BCH or
Liquid, eg? (Also, I think BCH's name for that opcode makes more sense
than Elements' -- all the CHECKSIG opcodes pull a sig from the stack,
after all)
> * Transaction introspection including:
> +Â Simulated SIGHASH_ANYPREVOUT, which are necessarily chaperoned simply by the
> nature of the construction.
I think simulating an ANYPREVOUT sig with a data signature means checking:
S1 P CHECKSIG -- to check S1 is a signature for the tx
S1 H_TapSighash(XAB) P CHECKDATASIG
-- to pull out the tx data "X", "A", "B")
S2 H_TapSighash(XCB) Q CHECKDATASIG
-- for the ANYPREVOUT sig, with A changed to C to
avoid committing to prevout info
X SIZE 42 EQUALVERIFY
B SIZE 47 EQUALVERIFY
-- to make sure only C is replaced from "XCB"
So to get all those conditions checked, I think you could do:
P 2DUP TOALT TOALT CHECKSIGVERIFY
SIZE 42 EQUALVERIFY
"TapSighash" SHA256 DUP CAT SWAP CAT TOALT
SIZE 47 EQUALVERIFY TUCK
CAT FROMALT TUCK SWAP CAT SHA256 FROMALT SWAP FROMALT
CHECKDATASIGVERIFY
SWAP TOALT SWAP CAT FROMALT CAT SHA256 Q CHECKDATASIG
Where the stack elements are, from top to bottom:
S1: (65B) signature by P of tx
X: (42B) start of TapSighash spec
B: (47B) end of TapSighash spec (amount, nSequence, tapleaf_hash,
key_version, codesep_pos)
A: (73B) middle of TapSighash spec dropped for ANYPREVOUT (spend_type,
scriptPubKey and outpoint)
C: (1B) alternate middle (different spend_type)
S2: (64B) signature of "XCB" by key Q
So 298B for the witness data, and 119B or so for the script (if I've not
made mistakes), versus "P CHECKSIGVERIFY Q CHECKSIG" and S2 and S1 on
the stack, for 132B of witness data and 70B of script, or half that if
the chaperone requirement is removed.
I think you'd need to complicate it a bit further to do the
ANYPREVOUTANYSCRIPT variant, where you retain the commitment to
amount/nseq but drop the commitment to tapleaf_hash.
> I feel that this style of generic building blocks truly embodies what is meant
> by "programmable money".
For practical purposes, this doesn't seem like a great level of
abstraction to me. It's certainly better at "permissionless innovation"
though.
You could make these constructions a little bit simpler by having a
"CHECK_SIG_MSG_VERIFY" opcode that accepts [sig msg key], and does "sig
key CHECKSIGVERIFY" but also checks the the provided msg was what was
passed into bip-schnorr.
Cheers,
aj
Published at
2023-06-07 18:18:19Event JSON
{
"id": "da3b749bb14ebe69eb550dc45f776dae74072765ec33275e7a18c5b8dea6de01",
"pubkey": "f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab",
"created_at": 1686161899,
"kind": 1,
"tags": [
[
"e",
"3bdc2663aa3c63ce143c0d0e20e9bd2ecde5b81cd9fa06d3a2acdbe95190a0e6",
"",
"root"
],
[
"e",
"6ca63f14754d608f7880df2764761ab729eb5f5653b60cd6ac8d8eb79d519da5",
"",
"reply"
],
[
"p",
"01f53a3166b3b23139201763777e070fcfed5555ad7555f7e90114c0c9e0e8b4"
]
],
"content": "📅 Original date posted:2019-05-27\n📝 Original message:On Wed, May 22, 2019 at 05:01:21PM -0400, Russell O'Connor via bitcoin-dev wrote:\n\u003e Bitcoin Script appears designed to be a flexible programmable system that\n\u003e provides generic features to be composed to achieve various purposes.\n\nCounterpoint: haven't the flexibly designed parts of script mostly been\na failure -- requiring opcodes to be disabled due to DoS vectors or\nconsensus bugs, and mostly not being useful in practice where they're\nstill enabled in BTC or on other chains where they have been re-enabled\n(eg, Liquid and BCH)?\n\n\u003e Instead, I propose that, for the time being, we simply implement OP_CAT and\n\u003e OP_CHECKSIGFROMSTACKVERIFY.\n\nFWIW, I'd like to see CAT enabled, though I'm less convinced about a\nCHECKSIG that takes the message from the stack. I think CAT's plausibly\nuseful in practice, but a sig against data from the stack seems more\nuseful in theory than in practice. Has it actually seen use on BCH or\nLiquid, eg? (Also, I think BCH's name for that opcode makes more sense\nthan Elements' -- all the CHECKSIG opcodes pull a sig from the stack,\nafter all)\n\n\u003e * Transaction introspection including:\n\u003e + Simulated SIGHASH_ANYPREVOUT, which are necessarily chaperoned simply by the\n\u003e nature of the construction.\n\nI think simulating an ANYPREVOUT sig with a data signature means checking:\n\n S1 P CHECKSIG -- to check S1 is a signature for the tx\n\n S1 H_TapSighash(XAB) P CHECKDATASIG\n -- to pull out the tx data \"X\", \"A\", \"B\")\n\n S2 H_TapSighash(XCB) Q CHECKDATASIG\n -- for the ANYPREVOUT sig, with A changed to C to\n\t avoid committing to prevout info\n\n X SIZE 42 EQUALVERIFY\n B SIZE 47 EQUALVERIFY\n -- to make sure only C is replaced from \"XCB\"\n\nSo to get all those conditions checked, I think you could do:\n\n P 2DUP TOALT TOALT CHECKSIGVERIFY\n SIZE 42 EQUALVERIFY\n \"TapSighash\" SHA256 DUP CAT SWAP CAT TOALT\n SIZE 47 EQUALVERIFY TUCK\n CAT FROMALT TUCK SWAP CAT SHA256 FROMALT SWAP FROMALT\n CHECKDATASIGVERIFY\n SWAP TOALT SWAP CAT FROMALT CAT SHA256 Q CHECKDATASIG\n \nWhere the stack elements are, from top to bottom:\n\n S1: (65B) signature by P of tx\n X: (42B) start of TapSighash spec\n B: (47B) end of TapSighash spec (amount, nSequence, tapleaf_hash,\n key_version, codesep_pos)\n A: (73B) middle of TapSighash spec dropped for ANYPREVOUT (spend_type,\n scriptPubKey and outpoint)\n C: (1B) alternate middle (different spend_type)\n S2: (64B) signature of \"XCB\" by key Q\n\nSo 298B for the witness data, and 119B or so for the script (if I've not\nmade mistakes), versus \"P CHECKSIGVERIFY Q CHECKSIG\" and S2 and S1 on\nthe stack, for 132B of witness data and 70B of script, or half that if\nthe chaperone requirement is removed.\n\nI think you'd need to complicate it a bit further to do the\nANYPREVOUTANYSCRIPT variant, where you retain the commitment to\namount/nseq but drop the commitment to tapleaf_hash.\n\n\u003e I feel that this style of generic building blocks truly embodies what is meant\n\u003e by \"programmable money\".\n\nFor practical purposes, this doesn't seem like a great level of\nabstraction to me. It's certainly better at \"permissionless innovation\"\nthough.\n\nYou could make these constructions a little bit simpler by having a\n\"CHECK_SIG_MSG_VERIFY\" opcode that accepts [sig msg key], and does \"sig\nkey CHECKSIGVERIFY\" but also checks the the provided msg was what was\npassed into bip-schnorr.\n\nCheers,\naj",
"sig": "5f14fd7934ef046dc4fe5cbbefc013a9629fb0bc3a067e6b5923c5f1c09c11587eb13d68a55b717b5c04c2c1e7b3402d9c0aa5a6d29fb14f88b95bc2b4ec9533"
}