đź“… Original date posted:2012-02-20
đź“ť Original message:> How will the code distinguish between the old scheme:
> [one-byte-version][20-byte-hash][4-byte-checksum]
> and the new?
>
> 1 in 256 old addresses will have a first-byte-of-checksum that matches the new address class; I guess the code would do something like:
>
> a) If the 4-byte checksum matches, then assume it is a singlesig address (1 in 2^32 multisig addresses will incorrectly match)
> b) If the one-byte-address-class and 3-byte checksum match, then it is a valid p2sh
> c) Otherwise, invalid address
Exactly!
>
> The 1 in 2^32 multisig addresses also being valid singlesig addresses makes me think this scheme won't work-- an attacker willing to generate 8 billion or so ECDSA keys could generate a single/multisig collision. I'm not sure how that could be leveraged to their advantage, but I bet they'd find a way.
Nope - its almost like calling the version:0+5 possible collision with new evil, say "ponzicoin" with version=5 a possible flaw that could be exploited... And you can already create non-existing addresses with a matching checksum...
> I'd also encourage you to actually implement your idea between steps 3 and 4. But in this particular case, I think an attacker being able to create singlesig/p2sh address collisions counts as a major flaw.
I will rest my case, not due to the "flaw", but I got some info on the bitfields of the "version" (thanks Luke!) - this makes the +5 less arbitrary, however, I don't think the bitfield interpretation is that well known, so there might already be "version"-collisions...:
Network class:
00xxxxxx - main network
01xxxxxx - reserved
10xxxxxx - reserved
11xxxxxx - test network
Network:
xx00xxxx - bitcoin
xx01xxxx - reserved
xx10xxxx - OTHER (next octet)
xx11xxxx - Namecoin
Network specific:
xxxx000y - PubKeyHash
xxxx001y - reserved
xxxx010y - p2sh
xxxx011y - public key (raw)
xxxx100y - signature
xxxx101y - reserved
xxxx110y - private key (raw)
xxxx111y - OTHER (next octet)
y = 0/1 depending on aesthetics (I guess to force the address to be either 1 or 3).
This also opens up for extensions - (if xx10xxxx or xxxx111x) the next byte will be part of the version.
/M
>
> --
> --
> Gavin Andresen
Michael Grønager [ARCHIVE] /
npub15f…xlq6h
2023-06-07 03:08:24
in reply to nevent1q…zz8f
Author Public Key
npub15fmnxm546tg2sv0l7elusrvqsgezdzdg3m0flpml5fr2qf3f5slskxlq6hPublished at
2023-06-07 03:08:24Event JSON
{
"id": "4705ab0d2278663457be24f9099e8d39546df296dafe6b050a438b327c312bd7",
"pubkey": "a277336e95d2d0a831fff67fc80d8082322689a88ede9f877fa246a02629a43f",
"created_at": 1686107304,
"kind": 1,
"tags": [
[
"e",
"02827371c6a4dadf4370012ad20068cb130d335969263f3423ec10b269e811dc",
"",
"root"
],
[
"e",
"573f364b34b8db93e07451363cf59c47fddd80a3fc3e1d11276e427bb5b3a055",
"",
"reply"
],
[
"p",
"857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4"
]
],
"content": "đź“… Original date posted:2012-02-20\nđź“ť Original message:\u003e How will the code distinguish between the old scheme:\n\u003e [one-byte-version][20-byte-hash][4-byte-checksum]\n\u003e and the new?\n\u003e \n\u003e 1 in 256 old addresses will have a first-byte-of-checksum that matches the new address class; I guess the code would do something like:\n\u003e \n\u003e a) If the 4-byte checksum matches, then assume it is a singlesig address (1 in 2^32 multisig addresses will incorrectly match)\n\u003e b) If the one-byte-address-class and 3-byte checksum match, then it is a valid p2sh\n\u003e c) Otherwise, invalid address\n\nExactly!\n\n\u003e \n\u003e The 1 in 2^32 multisig addresses also being valid singlesig addresses makes me think this scheme won't work-- an attacker willing to generate 8 billion or so ECDSA keys could generate a single/multisig collision. I'm not sure how that could be leveraged to their advantage, but I bet they'd find a way.\n\nNope - its almost like calling the version:0+5 possible collision with new evil, say \"ponzicoin\" with version=5 a possible flaw that could be exploited... And you can already create non-existing addresses with a matching checksum...\n\n\u003e I'd also encourage you to actually implement your idea between steps 3 and 4. But in this particular case, I think an attacker being able to create singlesig/p2sh address collisions counts as a major flaw.\n\nI will rest my case, not due to the \"flaw\", but I got some info on the bitfields of the \"version\" (thanks Luke!) - this makes the +5 less arbitrary, however, I don't think the bitfield interpretation is that well known, so there might already be \"version\"-collisions...:\n\nNetwork class:\n00xxxxxx - main network\n01xxxxxx - reserved\n10xxxxxx - reserved\n11xxxxxx - test network\n\nNetwork:\nxx00xxxx - bitcoin\nxx01xxxx - reserved\nxx10xxxx - OTHER (next octet)\nxx11xxxx - Namecoin\n\nNetwork specific:\nxxxx000y - PubKeyHash\nxxxx001y - reserved\nxxxx010y - p2sh\nxxxx011y - public key (raw)\nxxxx100y - signature\nxxxx101y - reserved\nxxxx110y - private key (raw)\nxxxx111y - OTHER (next octet)\n\ny = 0/1 depending on aesthetics (I guess to force the address to be either 1 or 3). \n\nThis also opens up for extensions - (if xx10xxxx or xxxx111x) the next byte will be part of the version.\n\n/M\n\n\u003e \n\u003e -- \n\u003e --\n\u003e Gavin Andresen",
"sig": "20502624228fbc7e2d11bc82df19fd68c62aabc419e58d89ffe0960245c2b179b5f23ade692c72f041616a401916b982a68ae2cb56130843e287a138c257a9bb"
}