In questi giorni sto smanettando coi sorgenti di bitcoin core per
ottenere un full node performante.
Nelle varie scorribande nel codice, ho scoperto questo,
che NON sapevo, e penso sia utile condividere:
Come sapete, con il segregate witness e' stato introdotto un nuovo
tipo di indirizzi, il bech32, che ultimamente inizia ad essere utilizzato in modo diffuso.
MA hanno scoperto che il bech32 ha un difetto (non da poco):
il chechsum in certi casi e' inefficace.
Quindi con la BIP 350 e' stato introdotto un nuovo tipo di indirizzo,
il bech32m che andra' a sostituire i bech32
https://github.com/bitcoin/bips/blob/master/bip-0350.mediawikiCompatibility
This document introduces a new encoding for v1 segregated witness outputs and higher versions. There should not be any compatibility issues on the receiver side; no wallets are creating v1 segregated witness addresses yet, as the output type is not usable on mainnet.
On the other hand, the Bech32m proposal breaks forward-compatibility for sending to v1 and higher version segregated witness addresses. This incompatibility is intentional. An alternative design was considered where Bech32 remained in use for certain subsets of future addresses, but ultimately discarded. By introducing a clean break, we protect not only new software but also existing senders from the mutation issue, as new addresses will be incompatible with the existing Bech32 address validation. Experiments by Taproot proponents had shown that hardly any wallets and services supported sending to higher segregated witness output versions, so little is lost by breaking forward-compatibility. Furthermore, those experiments identified cases in which segregated witness implementations would have caused wallets to burn funds when sending to version 1 addresses. In case it is still in use, the chosen approach will prevent such software from destroying funds when attempting to send to a Bech32m address.
