Walletwasabi: SegWit inputs in PSBT must provide full UTXO

[matejcik]

A security issue* in the design of BIP-143 allows an attacker to lie about segwit input amounts and get the user to pay an unexpectedly high transaction fee. The problem affects all HWW vendors.

For Trezor, we are fixing this by requiring the full UTXO for all types of inputs, so we can validate that the input amount is correct.

To facilitate that, we need Wasabi to provide full UTXOs for all input types.
This goes against the recommendation in BIP-174, saying that NON_WITNESS_UTXO should not be provided for SegWit inputs. Nevertheless, the resulting PSBT is still valid AFAICT.

Without this modification, it will be impossible to sign SegWit transactions on Trezor firmwares starting with 1.9.1 and 2.3.1. Also, an issue in HWI must be fixed first: https://github.com/bitcoin-core/HWI/issues/338

*) Details in our blogpost: https://blog.trezor.io/details-of-firmware-updates-for-trezor-one-version-1-9-1-and-trezor-model-t-version-2-3-1-1eba8f60f2dd

[lontivero]

Thanks for let us know. @molnard @nopara73 we should review whether this affects us and our users or not, and if it does then how. The first thing that comes to my mind is the size of the pbst for Wasabi users. I assume most(?) Wasabi users' coins come from Wasabi coinjoin transactions (25kilobytes avg each) and the average postmix consolidation is about 4 (it would be good to have the stdev here) that mean the resulting raw transaction will be around 100kb (the psbt is larger of course). Do the rest of the HW have any restriction about the size of the psbt?
We should also verify if our transaction builder works ok with such a monster transactions because I have some concerns about it.

[MaxHillebrand]

Thanks @matejcik for letting us know about this.

I agree with @lontivero concerns... because WW CJ tx are so damn large, this might indeed be tricky. well... let's see, I don't know the details.

For sure priority that should be in the v1.1.12 release.

[Kukks]

Thanks for let us know. @molnard @nopara73 we should review whether this affects us and our users or not, and if it does then how. The first thing that comes to my mind is the size of the pbst for Wasabi users. I assume most(?) Wasabi users' coins come from Wasabi coinjoin transactions (25kilobytes avg each) and the average postmix consolidation is about 4 (it would be good to have the stdev here) that mean the resulting raw transaction will be around 100kb (the psbt is larger of course). Do the rest of the HW have any restriction about the size of the psbt?
We should also verify if our transaction builder works ok with such a monster transactions because I have some concerns about it.

I would argue the change should be specific to Trezor devices as other HW vendors are not requiring this change in PSBT format (and may be incompatible with it)

[nopara73]

So, as a summary (correct me if I misunderstand something.) In theory we should be able to keep supporting Trezor assuming our deps (HWI + NBitcoin) also decide to do so.

[NicolasDorier]

@nopara73 you should be able. That said, some of NBitcoin code specifically try to slim down the PSBT by removing the transaction, so you need to test it.

Last point you need to test: In Wasabi wallet case, the mix transactions are 25KB of size. Imagine you sign 10 input (sending one BTC), then it is 250 KB sent to the hardware wallet. It is possible that you will hit some limit over the size of the PSBT somewhere down the pipe. (Say, too long to verify for Trezor, or maybe some limit over the parameter size to programs on some platforms)

In BTCPayServer we will not support is as we don't have previous transactions.

[RiccardoMasutti]

I'm available to test with Trezor One and T.

[nopara73]

@molnard You marked the dev meeting, because you want to assign this task to someone, right?

[nopara73]

Btw, whoever will tackle it, as a motivation (or demotivation, your choice) be aware that this story got picked up by the media.

[molnard]

Marked it as to have a discussion about it, if we shall put any effort to make it work or not. Also, an option can be to wait how HWI is handling this issue, we are relying on it.