Michael Grønager [ARCHIVE] on Nostr: 📅 Original date posted:2012-02-20 📝 Original message:> How will the code ...
đź“… 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
đź“ť 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