Quote from: tiffy on Today at 12:03:51 PM

But with the first transaction, all kinds of other vins and vouts appear under non_witness_utxo. There are amounts that my transaction has nothing to do with. My data also appears there, of course, but so do many others.

Is there any way to prevent this?

No, it is there for security.

Transaction signing requires knowing the output script of the output being spent. Since this data is not part of transaction input, it must be provided as extra data, which is what PSBT does. Additionally, you probably want to know the amount of the output being spent to be able to verify the amounts and fees. However, with non-segwit signing, it is possible for whoever is providing the output script and the amount to provide the incorrect amount and trick you into signing a transaction that spends more coins to fees than you were expecting. Thus in order to prove that the amounts are correct, the PSBT must provide information that is directly committed to in the spending transaction. The only way to do that is by providing the full previous transaction so that its txid can be computed and compared to the txid in inputs of the spending transaction.

With segwit v0, this issue was partially resolved by having the signature commit to the amount of the previous output. However, an attack requiring multiple signing rounds was discovered where that was insufficient and you could still be tricked into spending more coins than expected. Thus the full previous transaction is also added for segwit v0 inputs for simplicity.

If your transaction uses non-segwit or segwit v0 inputs, then there is no way to avoid the non_witness_utxo.

Currently, the only input type that does not require the non_witness_utxo are Taproot (segwit v1). If your transaction spends taproot inputs, they will only contain the witness_utxo which will always be 45 bytes.

Quote from: tiffy on Today at 12:03:51 PM

And how big can it get?

Very

Quote from: tiffy on Today at 12:03:51 PM

Is there any limit?

PSBT does not define one, but it is likely that it will adhere to the consensus rules which limit the transaction size via the block size limit if 4 MB. Furthermore, transactions have a standardness size limit of 400 KB, so it is likely that the non_witness_utxo will not exceed that. However, as full previous transactions are included for non-segwit and segwit v0 inputs, if your transaction has multiple of them, and each one has a large previous transactions, then each input will contain those in their non_witness_utxo and the size of your PSBT will be quite large.

Quote from: tiffy on Today at 12:03:51 PM

Should I perhaps change the address format for air gapped wallets?

As I mentioned above, Taproot.

Quote from: tiffy on Today at 02:27:35 PM

Shouldn't legacy addresses according to BIP 44 solve this problem? The psbt file should remain small, shouldn't it? Do legacy addresses have any disadvantages for me apart from higher fees?

No, as I mentioned above,the problem is due to signing, not derivation paths which BIP 44 defines. Derivation path information is included in the PSBT, but it's relatively small.