From: Ali Sherief <ali@notatether•com>
To: vjudeu@gazeta•pl
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Regarding BIP322 edge cases
Date: Wed, 10 Aug 2022 13:53:19 +0000 [thread overview]
Message-ID: <20220810135313.qxhshtuq3wx64osz@artanis> (raw)
In-Reply-To: <mailman.5.1660132803.3395.bitcoin-dev@lists.linuxfoundation.org>
> 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
next parent reply other threads:[~2022-08-10 13:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.5.1660132803.3395.bitcoin-dev@lists.linuxfoundation.org>
2022-08-10 13:53 ` Ali Sherief [this message]
2022-08-10 15:05 vjudeu
2022-08-10 16:42 ` Ali Sherief
-- strict thread matches above, loose matches on Subject: below --
2022-08-09 13:09 Ali Sherief
2022-08-10 2:59 ` vjudeu
2022-08-10 23:11 ` Ryan Grant
2022-08-11 16:56 ` Ali Sherief
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220810135313.qxhshtuq3wx64osz@artanis \
--to=ali@notatether$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=vjudeu@gazeta$(echo .)pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox