📅 Original date posted:2017-09-12
📝 Original message:> On 8 Sep 2017, at 4:04 AM, Mark Friedenbach via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> If I understand the revised attack description correctly, then there
> is a small window in which the attacker can create a script less than
> 55 bytes in length, where nearly all of the first 32 bytes are
> selected by the attacker, yet nevertheless the script seems safe to
> the counter-party. The smallest such script I was able to construct
> was the following:
>
> <fake-pubkey> CHECKSIGVERIFY HASH160 <preimage> EQUAL
>
> This is 56 bytes and requires only 7 bits of grinding in the fake
> pubkey. But 56 bytes is too large. Switching to secp256k1 serialized
> 32-byte pubkeys (in a script version upgrade, for example) would
> reduce this to the necessary 55 bytes with 0 bits of grinding. A
> smaller variant is possible:
>
> DUP HASH160 <fake-pubkey-hash> EQUALVERIFY CHECKSIGVERIFY HASH160 <preimage> EQUAL
>
> This is 46 bytes, but requires grinding 96 bits, which is a bit less
> plausible.
>
> Belts and suspenders are not so terrible together, however, and I
> think there is enough of a justification here to look into modifying
> the scheme to use a different IV for hash tree updates. This would
> prevent even the above implausible attacks.
>
I think you overestimated the difficulty. Consider this MAST branch (an example in BIP114)
"Timestamp" CHECKLOCKTIMEVERIFY <fake-pubkey> CHECKSIGVERIFY
This requires just a few bytes of collision.
Johnson Lau [ARCHIVE] /
npub1fy…p2mv9
2023-06-07 18:05:44
in reply to nevent1q…9rrd
Author Public Key
npub1fyh6gqhg8zgyhhywkty047s64z2a7fjr307enrr3kqwtnk64plmsup2mv9Published at
2023-06-07 18:05:44Event JSON
{
"id": "226d73354f2a03fc1b3388422006945c60f4c2ef1e6003076b41e28020fb898e",
"pubkey": "492fa402e838904bdc8eb2c8fafa1aa895df26438bfd998c71b01cb9db550ff7",
"created_at": 1686161144,
"kind": 1,
"tags": [
[
"e",
"825a0a580a35c1399d7ead6bfccb66b0f57217d2e5df4783a984d32afbb5a960",
"",
"root"
],
[
"e",
"edf7720e5506080c6edf256aa30de9dcb1bafc42068bde2da642734b10e7adc4",
"",
"reply"
],
[
"p",
"1c61d995949cbfaf14f767784e166bde865c7b8783d7aa3bf0a1d014b70c0069"
]
],
"content": "📅 Original date posted:2017-09-12\n📝 Original message:\u003e On 8 Sep 2017, at 4:04 AM, Mark Friedenbach via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \n\u003e If I understand the revised attack description correctly, then there\n\u003e is a small window in which the attacker can create a script less than\n\u003e 55 bytes in length, where nearly all of the first 32 bytes are\n\u003e selected by the attacker, yet nevertheless the script seems safe to\n\u003e the counter-party. The smallest such script I was able to construct\n\u003e was the following:\n\u003e \n\u003e \u003cfake-pubkey\u003e CHECKSIGVERIFY HASH160 \u003cpreimage\u003e EQUAL\n\u003e \n\u003e This is 56 bytes and requires only 7 bits of grinding in the fake\n\u003e pubkey. But 56 bytes is too large. Switching to secp256k1 serialized\n\u003e 32-byte pubkeys (in a script version upgrade, for example) would\n\u003e reduce this to the necessary 55 bytes with 0 bits of grinding. A\n\u003e smaller variant is possible:\n\u003e \n\u003e DUP HASH160 \u003cfake-pubkey-hash\u003e EQUALVERIFY CHECKSIGVERIFY HASH160 \u003cpreimage\u003e EQUAL\n\u003e \n\u003e This is 46 bytes, but requires grinding 96 bits, which is a bit less\n\u003e plausible.\n\u003e \n\u003e Belts and suspenders are not so terrible together, however, and I\n\u003e think there is enough of a justification here to look into modifying\n\u003e the scheme to use a different IV for hash tree updates. This would\n\u003e prevent even the above implausible attacks.\n\u003e \n\nI think you overestimated the difficulty. Consider this MAST branch (an example in BIP114)\n\n\"Timestamp\" CHECKLOCKTIMEVERIFY \u003cfake-pubkey\u003e CHECKSIGVERIFY\n\nThis requires just a few bytes of collision.",
"sig": "c1b66b0cd6275e00d1ed2965fda4e0c281237004fa3dc4ff15285c7e1958eb62be4cbb9ad6d4c187aca6e8228029022f872a1742cf05cb4a054b86ee72640d86"
}