Re: [bitcoin-dev] Regarding BIP322 edge cases

Re: [bitcoin-dev] Regarding BIP322 edge cases

[Ali Sherief]

> Backward compatibility. If we don't have OP_CHECKDATASIG, then it has to be somehow introduced to make it compatible with "Bitcoin Message".

I suppose in the case of legacy P2PKH signing, a hypothetical OP_CHECKDATASIG can take <signature> <pubkeyhash> off the stack and perform an ECDSA public key recovery, followed by SHA256/RIPEMD160, kind of like a hybrid between OP_DUP/OP_HASH160/OP_EQUALVERIFY and OP_CHECKSIG.

But the implementations would have to decode the Base58 address into "0x00" plus the address hash. As the only supported invoice type for the Legacy signing methods, this should be straight forward to do.

> And we have opcodes like OP_RESERVED, that can be wrapped in OP_IF, then it is "conditionally valid transaction".

I'm not sure how an OP_RESERVED in an unexcuted OP_IF is going to help implement an ECDSA pubkey recovery + DUP/HASH160/EQUALVERIFY hybrid instruction.

- Ali

On Wed, 10 Aug 2022 04:59:46 +0200, vjudeu@gazeta.pl wrote:
> > I'm not sure what is to be gained from adding an opcode
>
> Backward compatibility. If we don't have OP_CHECKDATASIG, then it has to be somehow introduced to make it compatible with "Bitcoin Message". And we have opcodes like OP_RESERVED, that can be wrapped in OP_IF, then it is "conditionally valid transaction". It is also possible to assign some unused opcode, but then it will be more complex, because in Script, those opcodes make transaction invalid, but inside TapScript, those opcodes are defined as OP_SUCCESS, and make things automatically valid.
>
>
> On 2022-08-09 22:53:34 user Ali Sherief via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Although there is a Github issue/PR at https://github.com/bitcoin/bips/pull/1347 for addressing all the TODO items of BIP322, I decided to throw it in the mailing list again to see if anyone else has suggestions for dealing with them.
>
> So in an older copy of the draft at https://github.com/bitcoin/bips/blob/b6b0126e2d04793ba52a40f05d24538fa3f2c9ad/bip-0322.mediawiki , I found the some TODO items, and I will copy-paste the ones in the Specification section (for full proofs) here:
>
> > TODO: How does this interact with as-of-yet-unspecified "Silent Transactions"?
> > TODO: Some invalid opcode to allow only in various proof types?
> > TODO: A way for the initial signer to delegate to another scriptPubKey; needed for better privacy and CoinJoin/Lightning compatibility
>
> So to start with, I believe it will be very helpful to limit what opcodes scriptPubKeys to be elligible to sign from them. The specification already does so to a point, but in order for these to be recognizable, it's my opinion that one of the NOPs should be placed at the beginning of the script to activate proof parsing mode.
>
> Of course, an opcode is not necessary at all, if the program is able to infer from context where the proof is coming from. After all, since they cannot be broadcasted, they can't be mined in blocks, so will never be encountered in a full node's usual verifier. I'm not sure what is to be gained from adding an opcode - the only source for real transactions is from P2P-obtained blocks, so when a human inputs a signature to be verified, it can check that a real transaction is not being inserted by looking for the invalid input.
>
> For Silent Transactions, I have already given my suggestion in the PR, that some subsection can be made saying that it can operate with them by using its scriptPubKey (and other stuff that may be necessary - I am not excatly sure what goes inside the Witness stack of message_signature).
>
> In the case of the last TODO, related to delegation to another scriptPubKey, I am not quite sure at the moment what to do about it - perhaps you guys can place a MAST (two Merkle branches, to be specific) - the first branch has the original signer's scriptPubKey, the second branch contains the delegated signer's scriptPubKey.
>
> - Ali

Re: [bitcoin-dev] Regarding BIP322 edge cases

[vjudeu]

> I suppose in the case of legacy P2PKH signing, a hypothetical OP_CHECKDATASIG can take <signature> <pubkeyhash> off the stack and perform an ECDSA public key recovery

You can always perform key recovery for legacy ECDSA: "<signature> OP_SWAP OP_CHECKSIG" is always spendable, for any valid <r,s> DER-encoded pair. Here, if "<signature> <messageHash> <pubkey> OP_CHECKDATASIG" works for signature verification BIP, then you only need to provide "<signature>" as an input, the rest could be placed in some output, and your program could easily compute that. Or you can use "OP_DUP OP_HASH160 <address> OP_EQUALVERIFY <messageHash> OP_SWAP OP_CHECKDATASIG" as your output script, then the signer has to provide a valid signature, and a valid public key explicitly, but if you only have some signature, then you can always recover that key by yourself.

Because if OP_CHECKDATASIG is not handled, then still, signing by scripts can handle that, but the Script would be unnecessarily complex. And because there is no need to introduce OP_CHECKDATASIG on-chain, it can be safely done inside this BIP.

> I'm not sure how an OP_RESERVED in an unexcuted OP_IF is going to help implement an ECDSA pubkey recovery + DUP/HASH160/EQUALVERIFY hybrid instruction.

Because if you want to support any script, and you want to add a new opcode, you have to make it somehow compatible with existing schemes. You have to assign some byte for OP_CHECKDATASIG or for any new opcodes you want to add. And you don't want to assign just the next free opcode, because you will get OP_CHECKSIGADD or other opcodes from TapScript, so your script decoder will no longer handle two script versions at once. Unless you want to make it also compatible with altcoins like BCH, but I guess it is not needed.


On 2022-08-10 15:53:31 user Ali Sherief <ali@notatether.com> wrote:
> > Backward compatibility. If we don't have OP_CHECKDATASIG, then it has to be somehow introduced to make it compatible with "Bitcoin Message".

I suppose in the case of legacy P2PKH signing, a hypothetical OP_CHECKDATASIG can take <signature> <pubkeyhash> off the stack and perform an ECDSA public key recovery, followed by SHA256/RIPEMD160, kind of like a hybrid between OP_DUP/OP_HASH160/OP_EQUALVERIFY and OP_CHECKSIG.

But the implementations would have to decode the Base58 address into "0x00" plus the address hash. As the only supported invoice type for the Legacy signing methods, this should be straight forward to do.

> And we have opcodes like OP_RESERVED, that can be wrapped in OP_IF, then it is "conditionally valid transaction".

I'm not sure how an OP_RESERVED in an unexcuted OP_IF is going to help implement an ECDSA pubkey recovery + DUP/HASH160/EQUALVERIFY hybrid instruction.

- Ali

On Wed, 10 Aug 2022 04:59:46 +0200, vjudeu@gazeta.pl wrote:
> > I'm not sure what is to be gained from adding an opcode
>
> Backward compatibility. If we don't have OP_CHECKDATASIG, then it has to be somehow introduced to make it compatible with "Bitcoin Message". And we have opcodes like OP_RESERVED, that can be wrapped in OP_IF, then it is "conditionally valid transaction". It is also possible to assign some unused opcode, but then it will be more complex, because in Script, those opcodes make transaction invalid, but inside TapScript, those opcodes are defined as OP_SUCCESS, and make things automatically valid.
>
>
> On 2022-08-09 22:53:34 user Ali Sherief via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Although there is a Github issue/PR at https://github.com/bitcoin/bips/pull/1347 for addressing all the TODO items of BIP322, I decided to throw it in the mailing list again to see if anyone else has suggestions for dealing with them.
>
> So in an older copy of the draft at https://github.com/bitcoin/bips/blob/b6b0126e2d04793ba52a40f05d24538fa3f2c9ad/bip-0322.mediawiki , I found the some TODO items, and I will copy-paste the ones in the Specification section (for full proofs) here:
>
> > TODO: How does this interact with as-of-yet-unspecified "Silent Transactions"?
> > TODO: Some invalid opcode to allow only in various proof types?
> > TODO: A way for the initial signer to delegate to another scriptPubKey; needed for better privacy and CoinJoin/Lightning compatibility
>
> So to start with, I believe it will be very helpful to limit what opcodes scriptPubKeys to be elligible to sign from them. The specification already does so to a point, but in order for these to be recognizable, it's my opinion that one of the NOPs should be placed at the beginning of the script to activate proof parsing mode.
>
> Of course, an opcode is not necessary at all, if the program is able to infer from context where the proof is coming from. After all, since they cannot be broadcasted, they can't be mined in blocks, so will never be encountered in a full node's usual verifier. I'm not sure what is to be gained from adding an opcode - the only source for real transactions is from P2P-obtained blocks, so when a human inputs a signature to be verified, it can check that a real transaction is not being inserted by looking for the invalid input.
>
> For Silent Transactions, I have already given my suggestion in the PR, that some subsection can be made saying that it can operate with them by using its scriptPubKey (and other stuff that may be necessary - I am not excatly sure what goes inside the Witness stack of message_signature).
>
> In the case of the last TODO, related to delegation to another scriptPubKey, I am not quite sure at the moment what to do about it - perhaps you guys can place a MAST (two Merkle branches, to be specific) - the first branch has the original signer's scriptPubKey, the second branch contains the delegated signer's scriptPubKey.
>
> - Ali

Re: [bitcoin-dev] Regarding BIP322 edge cases

[Ali Sherief]

Wait a minute. I did some lookup on OP_CHECKDATASIG to see if it's in some btc BIP draft somewhere, and it is actually an opcode in Bitcoin Cash since some years ago - https://mengerian.medium.com/the-story-of-op-checkdatasig-c2b1b38e801a

I think we can safely assume that Kalle and the other major BIP322 proponents do not have BCH script compatibility on a high prioirty, perhaps not even medium prioity, so we should be able to make an opcode called OP_CHECKDATASIG for this BIP's internal purposes.

However, a new opcode cannot be created without a lengthy soft-fork (which requires miner signalling - but for what use here, this BIP does not directly impact miners?) with an activation height. If we want to redefine an existing opcode, we must also make a similar soft-fork. Because consensus rules are being modified here.

At the same time, a message signing/verifying algorithm using Script must implement some way to verify a *single* ECDSA or Schnorr signature that is on the stack. The existing opcodes such as OP_CHECKSIG verify all of the inputs and outputs, and this won't work here since there's a deliberate invalid iput in "to_spend".

I tried to research if there is any known use of OP_RESERVED in a script, even if it's only of academic origin, but I unfortunately could not find any references except for https://bitcoin.stackexchange.com/questions/105778/why-were-op-reserved-op-reserved1-and-op-reserved2-originally-reserved .

So this is now an open problem: How should Script verify a single signature that is on the stack without touching any of the inputs or outputs?

- Ali

On Wed, Aug 10, 2022 at 05:05:59PM +0200, vjudeu@gazeta.pl wrote:
> > I suppose in the case of legacy P2PKH signing, a hypothetical OP_CHECKDATASIG can take <signature> <pubkeyhash> off the stack and perform an ECDSA public key recovery
>
> You can always perform key recovery for legacy ECDSA: "<signature> OP_SWAP OP_CHECKSIG" is always spendable, for any valid <r,s> DER-encoded pair. Here, if "<signature> <messageHash> <pubkey> OP_CHECKDATASIG" works for signature verification BIP, then you only need to provide "<signature>" as an input, the rest could be placed in some output, and your program could easily compute that. Or you can use "OP_DUP OP_HASH160 <address> OP_EQUALVERIFY <messageHash> OP_SWAP OP_CHECKDATASIG" as your output script, then the signer has to provide a valid signature, and a valid public key explicitly, but if you only have some signature, then you can always recover that key by yourself.
>
> Because if OP_CHECKDATASIG is not handled, then still, signing by scripts can handle that, but the Script would be unnecessarily complex. And because there is no need to introduce OP_CHECKDATASIG on-chain, it can be safely done inside this BIP.
>
> > I'm not sure how an OP_RESERVED in an unexcuted OP_IF is going to help implement an ECDSA pubkey recovery + DUP/HASH160/EQUALVERIFY hybrid instruction.
>
> Because if you want to support any script, and you want to add a new opcode, you have to make it somehow compatible with existing schemes. You have to assign some byte for OP_CHECKDATASIG or for any new opcodes you want to add. And you don't want to assign just the next free opcode, because you will get OP_CHECKSIGADD or other opcodes from TapScript, so your script decoder will no longer handle two script versions at once. Unless you want to make it also compatible with altcoins like BCH, but I guess it is not needed.
>
>
> On 2022-08-10 15:53:31 user Ali Sherief <ali@notatether.com> wrote:
> > > Backward compatibility. If we don't have OP_CHECKDATASIG, then it has to be somehow introduced to make it compatible with "Bitcoin Message".
>
> I suppose in the case of legacy P2PKH signing, a hypothetical OP_CHECKDATASIG can take <signature> <pubkeyhash> off the stack and perform an ECDSA public key recovery, followed by SHA256/RIPEMD160, kind of like a hybrid between OP_DUP/OP_HASH160/OP_EQUALVERIFY and OP_CHECKSIG.
>
> But the implementations would have to decode the Base58 address into "0x00" plus the address hash. As the only supported invoice type for the Legacy signing methods, this should be straight forward to do.
>
> > And we have opcodes like OP_RESERVED, that can be wrapped in OP_IF, then it is "conditionally valid transaction".
>
> I'm not sure how an OP_RESERVED in an unexcuted OP_IF is going to help implement an ECDSA pubkey recovery + DUP/HASH160/EQUALVERIFY hybrid instruction.
>
> - Ali
>
> On Wed, 10 Aug 2022 04:59:46 +0200, vjudeu@gazeta.pl wrote:
> > > I'm not sure what is to be gained from adding an opcode
> >
> > Backward compatibility. If we don't have OP_CHECKDATASIG, then it has to be somehow introduced to make it compatible with "Bitcoin Message". And we have opcodes like OP_RESERVED, that can be wrapped in OP_IF, then it is "conditionally valid transaction". It is also possible to assign some unused opcode, but then it will be more complex, because in Script, those opcodes make transaction invalid, but inside TapScript, those opcodes are defined as OP_SUCCESS, and make things automatically valid.
> >
> >

[bitcoin-dev] Regarding BIP322 edge cases

[Ali Sherief]

Although there is a Github issue/PR at https://github.com/bitcoin/bips/pull/1347 for addressing all the TODO items of BIP322, I decided to throw it in the mailing list again to see if anyone else has suggestions for dealing with them.

So in an older copy of the draft at https://github.com/bitcoin/bips/blob/b6b0126e2d04793ba52a40f05d24538fa3f2c9ad/bip-0322.mediawiki , I found the some TODO items, and I will copy-paste the ones in the Specification section (for full proofs) here:

> TODO: How does this interact with as-of-yet-unspecified "Silent Transactions"?
> TODO: Some invalid opcode to allow only in various proof types?
> TODO: A way for the initial signer to delegate to another scriptPubKey; needed for better privacy and CoinJoin/Lightning compatibility

So to start with, I believe it will be very helpful to limit what opcodes scriptPubKeys to be elligible to sign from them. The specification already does so to a point, but in order for these to be recognizable, it's my opinion that one of the NOPs should be placed at the beginning of the script to activate proof parsing mode.

Of course, an opcode is not necessary at all, if the program is able to infer from context where the proof is coming from. After all, since they cannot be broadcasted, they can't be mined in blocks, so will never be encountered in a full node's usual verifier. I'm not sure what is to be gained from adding an opcode - the only source for real transactions is from P2P-obtained blocks, so when a human inputs a signature to be verified, it can check that a real transaction is not being inserted by looking for the invalid input.

For Silent Transactions, I have already given my suggestion in the PR, that some subsection can be made saying that it can operate with them by using its scriptPubKey (and other stuff that may be necessary - I am not excatly sure what goes inside the Witness stack of message_signature).

In the case of the last TODO, related to delegation to another scriptPubKey, I am not quite sure at the moment what to do about it - perhaps you guys can place a MAST (two Merkle branches, to be specific) - the first branch has the original signer's scriptPubKey, the second branch contains the delegated signer's scriptPubKey.

- Ali

Re: [bitcoin-dev] Regarding BIP322 edge cases

[vjudeu]

> I'm not sure what is to be gained from adding an opcode

Backward compatibility. If we don't have OP_CHECKDATASIG, then it has to be somehow introduced to make it compatible with "Bitcoin Message". And we have opcodes like OP_RESERVED, that can be wrapped in OP_IF, then it is "conditionally valid transaction". It is also possible to assign some unused opcode, but then it will be more complex, because in Script, those opcodes make transaction invalid, but inside TapScript, those opcodes are defined as OP_SUCCESS, and make things automatically valid.


On 2022-08-09 22:53:34 user Ali Sherief via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> Although there is a Github issue/PR at https://github.com/bitcoin/bips/pull/1347 for addressing all the TODO items of BIP322, I decided to throw it in the mailing list again to see if anyone else has suggestions for dealing with them.

So in an older copy of the draft at https://github.com/bitcoin/bips/blob/b6b0126e2d04793ba52a40f05d24538fa3f2c9ad/bip-0322.mediawiki , I found the some TODO items, and I will copy-paste the ones in the Specification section (for full proofs) here:

> TODO: How does this interact with as-of-yet-unspecified "Silent Transactions"?
> TODO: Some invalid opcode to allow only in various proof types?
> TODO: A way for the initial signer to delegate to another scriptPubKey; needed for better privacy and CoinJoin/Lightning compatibility

So to start with, I believe it will be very helpful to limit what opcodes scriptPubKeys to be elligible to sign from them. The specification already does so to a point, but in order for these to be recognizable, it's my opinion that one of the NOPs should be placed at the beginning of the script to activate proof parsing mode.

Of course, an opcode is not necessary at all, if the program is able to infer from context where the proof is coming from. After all, since they cannot be broadcasted, they can't be mined in blocks, so will never be encountered in a full node's usual verifier. I'm not sure what is to be gained from adding an opcode - the only source for real transactions is from P2P-obtained blocks, so when a human inputs a signature to be verified, it can check that a real transaction is not being inserted by looking for the invalid input.

For Silent Transactions, I have already given my suggestion in the PR, that some subsection can be made saying that it can operate with them by using its scriptPubKey (and other stuff that may be necessary - I am not excatly sure what goes inside the Witness stack of message_signature).

In the case of the last TODO, related to delegation to another scriptPubKey, I am not quite sure at the moment what to do about it - perhaps you guys can place a MAST (two Merkle branches, to be specific) - the first branch has the original signer's scriptPubKey, the second branch contains the delegated signer's scriptPubKey.

- Ali

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Regarding BIP322 edge cases

[Ryan Grant]

>> TODO: A way for the initial signer to delegate to another
>> scriptPubKey; needed for better privacy and CoinJoin/Lightning
>> compatibility

I need more documentation to understand this motivation.

On Tue, Aug 9, 2022 at 8:46 PM Ali Sherief via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> In the case of the last TODO, related to delegation to another
> scriptPubKey, I am not quite sure at the moment what to do about
> it - perhaps you guys can place a MAST (two Merkle branches, to be
> specific) - the first branch has the original signer's scriptPubKey,
> the second branch contains the delegated signer's scriptPubKey.

I don't understand this requirement, but it seems that whatever
parties are involved can make signatures on the delegating and
delegated keys.

Re: [bitcoin-dev] Regarding BIP322 edge cases

[Ali Sherief]

Earlier last year on March, there was a post here by Jeremy Rubin that explains how a person could delegate its UTXO to some script, by (AFAICT) creating a new transaction using that UTXO, with whatever script you want it to have.

It was written in terms of normal transactions, but can be extended to message signing transactions too.

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018615.html

Only the beginning of the post is relevant here.

- Ali

On Wed, Aug 10, 2022 at 11:11:10PM +0000, Ryan Grant wrote:
> >> TODO: A way for the initial signer to delegate to another
> >> scriptPubKey; needed for better privacy and CoinJoin/Lightning
> >> compatibility
>
> I need more documentation to understand this motivation.
>
> On Tue, Aug 9, 2022 at 8:46 PM Ali Sherief via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > In the case of the last TODO, related to delegation to another
> > scriptPubKey, I am not quite sure at the moment what to do about
> > it - perhaps you guys can place a MAST (two Merkle branches, to be
> > specific) - the first branch has the original signer's scriptPubKey,
> > the second branch contains the delegated signer's scriptPubKey.
>
> I don't understand this requirement, but it seems that whatever
> parties are involved can make signatures on the delegating and
> delegated keys.