📅 Original date posted:2022-08-09
📝 Original message:> 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 at 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 at lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
vjudeu at gazeta.pl [ARCHIVE] /
npub135…nssga
2023-06-07 23:12:37
in reply to nevent1q…584m
Author Public Key
npub1357006afyypkgz03lmq8fnuvlkyjt0rukx8rt56ck8xv396jaceqmnssgaPublished at
2023-06-07 23:12:37Event JSON
{
"id": "e07e669938e422067011af382b0a319ecba526b8526e1125316d148dc7216a3c",
"pubkey": "8d3cf7eba921036409f1fec074cf8cfd8925bc7cb18e35d358b1ccc89752ee32",
"created_at": 1686179557,
"kind": 1,
"tags": [
[
"e",
"7911c55f95e735ed41026f38b07f1268ccff18d71d8415399db75a1d32939c97",
"",
"root"
],
[
"e",
"1bbd0a9085e2e190bd91425df17b9f0fbc2466fc845c7b8b4b680477e57dc4c4",
"",
"reply"
],
[
"p",
"300ba94cc910da0a8903ca9e40487283545661c726c81fd5942e11a0683ad617"
]
],
"content": "📅 Original date posted:2022-08-09\n📝 Original message:\u003e I'm not sure what is to be gained from adding an opcode\n\nBackward 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.\n\n\nOn 2022-08-09 22:53:34 user Ali Sherief via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e 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.\n\nSo 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:\n\n\u003e TODO: How does this interact with as-of-yet-unspecified \"Silent Transactions\"?\n\u003e TODO: Some invalid opcode to allow only in various proof types?\n\u003e TODO: A way for the initial signer to delegate to another scriptPubKey; needed for better privacy and CoinJoin/Lightning compatibility\n\nSo 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.\n\nOf 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.\n\nFor 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).\n\nIn 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.\n\n- Ali\n\n_______________________________________________\nbitcoin-dev mailing list\nbitcoin-dev at lists.linuxfoundation.org\nhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev",
"sig": "5c7d8c0ec54b247cbee7d816ee0c2260acf9b03da7b35f4e5ad3a9dd9673d7436451dc39b71577762b4e384e7fcf4ea1836ee852e52e3fb670201aab1b60877b"
}