pull down to refresh
1008 sats \ 2 replies \ @0260378aef 26 Dec 2021
If you chase up the details shown in that post, you will find it is truly a disgrace on the part of Binance.
Here's some technical context for those who aren't too clear:
In the original definitions of segwit BIP141, the two scriptPubKey types (they're the outputs; they're strings of bytes that can get converted into addresses, but on chain they're just strings of bytes) were recognized like this:
if it starts with a '0' for version 0, then:
- if what's left is 20 bytes, interpret it as a P2WPKH (the 20 bytes is a hash of a public key, just like the old legacy 1 addresses, except using segwit)
- if what's left is 32 bytes, interpret it as a P2WSH (the 32 bytes is the hash of a script, just like the old legacy '3' addresses, except using segwit)
With taproot there's only 1 type, not 2, it's always:
if it starts with a '1' for version 1, then: interpret the remaining 32 bytes as a public key (the new schnorr type as in BIP340).
(Deliberately missing out the full set of rules, part of which is to allow future upgrades)
So this poor guy sends them a withdrawal address of that latter type: starts with '1', then 32 bytes public key.
They then UNILATERALLY DECIDE to change the '1' to a '0', and what is left is a valid address, because it is 32 bytes, so it gets interpreted as the second of the two segwit options above: i.e. it's a p2wsh and the 32 bytes are a hash, not a public key. This is unspendable unless you can break sha256.
reply
1 sat \ 1 reply \ @0260378aef 26 Dec 2021
Btw a technical detail: they didn't only swap 'p' for 'q' in the address; the checksum (the last 6 characters) is also changed. Which almost certainly means they just swapped out the existing scriptPubKey for one where the version byte was changed from 1 to 0, and then their software created the 'correct' address for that, including the new checksum.
reply
0 sats \ 0 replies \ @cameri 27 Dec 2021
that's truly fucked up
reply