Timeline for Identifying address types using v1+ segwit outputs
Current License: CC BY-SA 4.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 13, 2021 at 20:49 | history | edited | Antoine Poinsot | CC BY-SA 4.0 |
added 19 characters in body
|
| Jun 1, 2021 at 18:57 | vote | accept | jurgendonnings2321 | ||
| Jun 1, 2021 at 18:56 | comment | added | jurgendonnings2321 |
Sorry, in that case I should indeed specify that by "native-segwit" in the first comment I was referring to the two "spending scripts" (again, not sure if correct terminology) currently used with witness version 0. Taking ... is unspendable Okay fascinating, so they just sent to <0> <32-bytes push> instead of <1> <32-bytes push> because the version was hardcoded or similar on their end, and because that is actually just a valid P2WSH v0 encoding there was nothing that invalidated the payment? Think I got it.
|
|
| Jun 1, 2021 at 18:42 | comment | added | Pieter Wuille | The burning of funds was due to some services incorrectly implementing BIP173 in a way that resulted in bech32 v1+ addresses being turned into native v0 witness outputs (regardless of the version in the address). Taking a P2TR output (which stores a tweaked xonly pubkey) and changing the version to zero causes it to be interpreted as a P2WSH (with as script "hash" that tweaked key), which is unspendable. | |
| Jun 1, 2021 at 18:38 | comment | added | Pieter Wuille | Taproot outputs (P2TR) are native segwit v1 with 32-byte programs. That's how these outputs are defined. They're not "P2WSH v1", because P2WSH is defined as "Native or P2SH segwit v0 outputs with 32-byte programs". | |
| Jun 1, 2021 at 17:58 | comment | added | jurgendonnings2321 | All my sources are from the BIP readme detailing bech32m, so that would be github and this email | |
| Jun 1, 2021 at 17:54 | comment | added | Antoine Poinsot | It's not whatever i want to call it, i try to use specific terms to not cause (additional) confusion (too many terms are already overloaded in Bitcoin-land). I don't know what you are talking about, could you provide a link to a discussion about this loss? | |
| Jun 1, 2021 at 17:50 | comment | added | jurgendonnings2321 | Okay, that was what I was wondering - native segwit cannot use version 1 and above and subsequently do not use bech32m encodings (which is just a different checksum), else they are seen as invalid, (or a taproot address which is actually unspendable). I still don't fully understand what happend that caused P2TR "scripts" (pubkey, whatever you want to call it) encoded using standard bech32 (so checksum of 1) to burn funds because they were decoded wrong by wallets, if anyone could clarify the technicalities of that, and why that would be changed by bech32m, aside from breaking forwar-compat | |
| Jun 1, 2021 at 16:28 | history | answered | Antoine Poinsot | CC BY-SA 4.0 |