From: Jonas Nick <jonasd.nick@gmail•com>
To: bitcoindev@googlegroups.com
Subject: Re: [bitcoindev] P2QRH / BIP-360 Update
Date: Mon, 24 Feb 2025 13:17:07 +0000 [thread overview]
Message-ID: <5550807e-0655-4895-bc66-1b67bfde8c3e@gmail.com> (raw)
In-Reply-To: <16d7adca-a01e-40c5-9570-31967ee339ecn@googlegroups.com>
> What prevents arbitrary data being hashed and then included in the attestation
> is, each signature public key pair must be able to verify the transaction
> message in order to be considered a valid transaction.
This appears to contradict the selective disclosure mechanism described in the
BIP and this sentence in the "Script Validation" section:
> Public keys that are not needed can be excluded by including their hash in the
> attestation accompanied with an empty signature
Even if the selective disclosure vulnerability is fixed by committing to the
multisig semantics in the P2QRH output, any unopened public key commitment could
still be "abused" for arbitrary data storage. Similar to the scenario in my
previous post, if the root R is MerkleRoot([leafhash1, leafhash2]) and the
multisig policy is "1-of-2", then we can set
leafhash1 := data
leafhash2 := hash(public_key_secp256k1)
and post the data to the chain by spending the output using an attestation
structure that includes leafhash1, an empty signature, public_key_secp256k1 and
the corresponding signature.
> I will admit I don't understand this attack. Can you provide more details on
> how it works, and how it might be possible to mitigate?
To give more context, this attack is intended as a concrete demonstration of how
breaking the collision resistance of the hash function used in the Merkle tree
can enable an adversary to steal coins. Here's a different explanation for
essentially the same attack in the context of P2SH vs. P2WSH:
https://bitcoin.stackexchange.com/a/54847/35586
The attack against the BIP's proposed signature scheme (where the Merkle tree is
constructed from public keys and then an ordinary signature scheme is applied to
one or more of the committed public keys) can be mitigated by using a hash
function with a larger output space (e.g., SHA-512).
However, I'm not suggesting to do this. My point is that while the BIP aims for
256 bits of security by using NIST strength level V parameters, it does not
actually achieve that security level (when the adversary can affect any of the
leaves as in multisignatures, for example).
The Bitcoin protocol relies heavily on collision-resistance of SHA-256, which is
pretty much the definition of NIST strength level II [0].
[0] https://csrc.nist.gov/projects/post-quantum-cryptography/post-quantum-cryptography-standardization/evaluation-criteria/security-(evaluation-criteria)
--
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups•com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/5550807e-0655-4895-bc66-1b67bfde8c3e%40gmail.com.
prev parent reply other threads:[~2025-02-24 15:27 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-19 15:40 Hunter Beast
2025-02-19 17:23 ` Dustin Ray
2025-02-19 22:57 ` Hunter Beast
2025-02-20 22:11 ` Matt Corallo
2025-02-23 20:33 ` Hunter Beast
2025-02-21 8:54 ` Jonas Nick
2025-02-23 20:58 ` Hunter Beast
2025-02-24 13:17 ` Jonas Nick [this message]
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=5550807e-0655-4895-bc66-1b67bfde8c3e@gmail.com \
--to=jonasd.nick@gmail$(echo .)com \
--cc=bitcoindev@googlegroups.com \
/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