ZmnSCPxj [ARCHIVE] on Nostr: š
Original date posted:2019-06-06 š Original message:Good morning aj, Sent with ...
š
Original date posted:2019-06-06
š Original message:Good morning aj,
Sent with ProtonMail Secure Email.
āāāāāāā Original Message āāāāāāā
On Wednesday, June 5, 2019 5:30 PM, Anthony Towns via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, May 31, 2019 at 10:35:45PM -0700, Jeremy via bitcoin-dev wrote:
>
> > OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG*.
>
> I think you could generalise that slightly and make it fit in
> with the existing opcode naming by calling it something like
> "OP_CHECKTXDIGESTVERIFY" and pull a 33-byte value from the stack,
> consisting of a sha256 hash and a sighash-byte, and adding a new sighash
> value corresponding to the set of info you want to include in the hash,
> which I think sounds a bit like "SIGHASH_EXACTLY_ONE_INPUT | SIGHASH_ALL"
>
> FWIW, I'm not really seeing any reason to complicate the spec to ensure
> the digest is precommitted as part of the opcode.
>
I believe in combination with `OP_LEFT` and `OP_CAT` this allows Turing-complete smart contracts, in much the same way as `OP_CHECKSIGFROMSTACK`?
Pass in the spent transaction (serialised for txid) and the spending transaction (serialised for sighash) as part of the witness of the spending transaction.
Script verifies that the spending transaction witness value is indeed the spending transaction by `OP_SHA256 <SIGHASH_ALL> OP_SWAP OP_CAT OP_CHECKTXDIGESTVERIFY`.
Script verifies the spent transaction witness value is indeed the spent transaction by hashing it, then splitting up the hash with `OP_LEFT` into bytes, and comparing the bytes to the bytes in the input of the spending transaction witness value (txid being the bytes in reversed order).
Then the Script can extract a commitment of itself by extracting the output of the spent transaction.
This lets the Script check that the spending transaction also pays to the same script.
The Script can then access a state value, for example from an `OP_RETURN` output of the spent transaction, and enforce that a correct next-state is used in the spending transaction.
If the state is too large to fit in a standard `OP_RETURN`, then the current state can be passed in as a witness and validated against a hash commitment in an `OP_RETURN` output.
I believe this is the primary reason against not pulling data from the stack.
Regards,
ZmnSCPxj
Published at
2023-06-07 18:18:27Event JSON
{
"id": "73e415277e0fcbbfbbe45be4386105aa198cb71cf246cb73b293855d1720cf3b",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686161907,
"kind": 1,
"tags": [
[
"e",
"795f91cf98a58a02bc008ff719dc0f4282d730c0208950ac096ead04dbb580b7",
"",
"root"
],
[
"e",
"71018870ed589842f7f3407d393b0907b87690708bae855cccf1fe8c068d521e",
"",
"reply"
],
[
"p",
"f0feda6ad58ea9f486e469f87b3b9996494363a26982b864667c5d8acb0542ab"
]
],
"content": "š
Original date posted:2019-06-06\nš Original message:Good morning aj,\n\n\nSent with ProtonMail Secure Email.\n\nāāāāāāā Original Message āāāāāāā\nOn Wednesday, June 5, 2019 5:30 PM, Anthony Towns via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Fri, May 31, 2019 at 10:35:45PM -0700, Jeremy via bitcoin-dev wrote:\n\u003e\n\u003e \u003e OP_CHECKOUTPUTSHASHVERIFY is retracted in favor of OP_SECURETHEBAG*.\n\u003e\n\u003e I think you could generalise that slightly and make it fit in\n\u003e with the existing opcode naming by calling it something like\n\u003e \"OP_CHECKTXDIGESTVERIFY\" and pull a 33-byte value from the stack,\n\u003e consisting of a sha256 hash and a sighash-byte, and adding a new sighash\n\u003e value corresponding to the set of info you want to include in the hash,\n\u003e which I think sounds a bit like \"SIGHASH_EXACTLY_ONE_INPUT | SIGHASH_ALL\"\n\u003e\n\u003e FWIW, I'm not really seeing any reason to complicate the spec to ensure\n\u003e the digest is precommitted as part of the opcode.\n\u003e\n\nI believe in combination with `OP_LEFT` and `OP_CAT` this allows Turing-complete smart contracts, in much the same way as `OP_CHECKSIGFROMSTACK`?\n\nPass in the spent transaction (serialised for txid) and the spending transaction (serialised for sighash) as part of the witness of the spending transaction.\n\nScript verifies that the spending transaction witness value is indeed the spending transaction by `OP_SHA256 \u003cSIGHASH_ALL\u003e OP_SWAP OP_CAT OP_CHECKTXDIGESTVERIFY`.\nScript verifies the spent transaction witness value is indeed the spent transaction by hashing it, then splitting up the hash with `OP_LEFT` into bytes, and comparing the bytes to the bytes in the input of the spending transaction witness value (txid being the bytes in reversed order).\n\nThen the Script can extract a commitment of itself by extracting the output of the spent transaction.\nThis lets the Script check that the spending transaction also pays to the same script.\n\nThe Script can then access a state value, for example from an `OP_RETURN` output of the spent transaction, and enforce that a correct next-state is used in the spending transaction.\nIf the state is too large to fit in a standard `OP_RETURN`, then the current state can be passed in as a witness and validated against a hash commitment in an `OP_RETURN` output.\n\nI believe this is the primary reason against not pulling data from the stack.\n\nRegards,\nZmnSCPxj",
"sig": "afaee8777f453a2a42a2f57bf12bc87b74eb8a9f1173002faa2fbd829efd16242910376fea8e2e84735c85709831d66759cb672d35e7a51f1765a56ef0a1e49b"
}