Why does Wasabi only use SegWit Bech32 addresses?

[BTCparadigm]

Why does Wasabi only use SegWit Bech32 addresses?

[RiccardoMasutti]

Wasabi was created after the activation of SegWit, and it makes sense to support the most advanced address type, which has numerous benefits. For example, due to the malleability fix of SegWit, you can now remix CoinJoin outputs which are currently unconfirmed. There are also large savings on mining fees for SegWit transactions.

[molnard]

@RiccardoMasutti is right. Besides, that without Native SegWit (bech32) Wasabi CoinJoins would be impossible to create. At the Signing phase, everyone gets the unsigned CoinJoin and all the clients send their signature to the Coordinator thus added to the final CJ transaction. If everyone signed then the backend broadcast the signed CoinJoin.

Every single tx has a hash that is calculated by the "content" of the transaction. When the Wasabi client signs an input the signature also guarantees that it is valid only for the tx with that specific hash. So if the tx changed later on by the coordinator the input signature would become invalid. Without bech32 every signature addition would change the content thus invalidating the collected signatures. This is the so-called "Transaction Malleability Issue". However, with bech32 the signature was "taken out" of the tx thus it does not affect the hash of the tx - so the signatures can be gathered and added one-by-one.

[lontivero]

Where it says bech32 read segwit.

[molnard]

Isn't bech32 = Native SegWit?

[lontivero]

No. bech32 is just a better encoder than base58 for encoding bitcoin addresses. Segwit is a new transaction structure that puts the signatures in a different place, what allows to achieve what you described above.

[ghost]

All points mentioned above are important reasons why Wasabi is segwit only.

One further point, is that we are using BIP 158 block filters. If Wasabi would support all output types, then we would have to create basic block filters, with ALL the transactions of the block referenced. However, thanks to segwit only, the backend creates filters of ONLY native segwit single public key transactions. [notice, not even native segwit multisig or other advanced script types.] Therefore these filters are substantially smaller in size. This saves both the backend and the clients substantial bandwidth, computational, and storage costs.

I don't know the exact numbers in mind, but a the Bitcoin Core generated basic block filters [from genesis!] are at over 5 GB currently. While Wasabi's segwit block filters [since segwit activation] are only 250 MB.