Russell O'Connor [ARCHIVE] on Nostr: 📅 Original date posted:2019-06-24 📝 Original message:OP_SECURETHEBAG doesn't ...
📅 Original date posted:2019-06-24
📝 Original message:OP_SECURETHEBAG doesn't include the script being executed (i.e the
scriptPubKey specified in the output that is redeemed by this input) in its
hash like ordinary signatures do
<https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1271>;.
Of course, this ScriptPubKey is indirectly committed to through the input's
prevoutpoint. However Script isn't able to reconstruct this script being
executed from the prevoutpoint in tapscript without an implementation of
public key tweeking in Bitcoin Script.
On Sun, Jun 23, 2019 at 2:41 AM Jeremy Rubin <jeremy.l.rubin at gmail.com>
wrote:
> Can you clarify this comment?
>
> We do in fact commit to the script and scriptsig itself (not the witness
> stack) in OP_SECURETHEBAG (unless I'm missing what you meant)?
>
> On Thu, Jun 20, 2019, 10:59 AM Russell O'Connor via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Just to be clear, while OP_CHECKTXDIGESTVERIFY would enable this style
>> of covenants if it pulled data from the stack, the OP_SECURETHEBAG
>> probably cannot create covenants even if it were to pull the data from the
>> stack unless some OP_TWEEKPUBKEY operation is added to Script because the
>> "commitment of the script itself" isn't part of the OP_SECURETHEBAG.
>>
>> So with regards to OP_SECURETHEBAG, I am also "not really seeing any
>> reason to complicate the spec to ensure the digest is precommitted as part
>> of the opcode."
>>
>> On Thu, Jun 6, 2019 at 3:33 AM ZmnSCPxj via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> 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
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190624/f738daa1/attachment-0001.html>;
📝 Original message:OP_SECURETHEBAG doesn't include the script being executed (i.e the
scriptPubKey specified in the output that is redeemed by this input) in its
hash like ordinary signatures do
<https://github.com/bitcoin/bitcoin/blob/master/src/script/interpreter.cpp#L1271>;.
Of course, this ScriptPubKey is indirectly committed to through the input's
prevoutpoint. However Script isn't able to reconstruct this script being
executed from the prevoutpoint in tapscript without an implementation of
public key tweeking in Bitcoin Script.
On Sun, Jun 23, 2019 at 2:41 AM Jeremy Rubin <jeremy.l.rubin at gmail.com>
wrote:
> Can you clarify this comment?
>
> We do in fact commit to the script and scriptsig itself (not the witness
> stack) in OP_SECURETHEBAG (unless I'm missing what you meant)?
>
> On Thu, Jun 20, 2019, 10:59 AM Russell O'Connor via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Just to be clear, while OP_CHECKTXDIGESTVERIFY would enable this style
>> of covenants if it pulled data from the stack, the OP_SECURETHEBAG
>> probably cannot create covenants even if it were to pull the data from the
>> stack unless some OP_TWEEKPUBKEY operation is added to Script because the
>> "commitment of the script itself" isn't part of the OP_SECURETHEBAG.
>>
>> So with regards to OP_SECURETHEBAG, I am also "not really seeing any
>> reason to complicate the spec to ensure the digest is precommitted as part
>> of the opcode."
>>
>> On Thu, Jun 6, 2019 at 3:33 AM ZmnSCPxj via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> 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
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190624/f738daa1/attachment-0001.html>;