After discussion with Andrew Poelstra it became obvious that the previous decision of storing public key tweak information within PSBT as a single value (https://github.com/LNP-BP/rust-lnpbp/issues/86) will be insecure and incompatible with hardware signing units, wallets or airgapped solutions. The problems is that the device must be able to verify what is hidden behind the tweak, otherwise it will be possible for a malware to change the tweak in such a way that it will substitue the underlying state transition with some other (assigning assets to the thief-controlled UTXOs) or, even, apply some taproot-based alternative spending conditions.
Thus, first, we must extend PSBT standard in a way that it will contain all state transition(s) to which transaction will be committing to, and the device must have a software able to parse and present user with this data.
It seems that this is not the same problem for inputs, as for outputs; and it will be sufficient to present device with the tweak only when it will be spending some of existing outputs containing the tweak.
Basically, for RGB we need to define a standard for custom PSBT keys providing all the required information.
After discussion with Andrew Poelstra it became obvious that the previous decision of storing public key tweak information within PSBT as a single value (https://github.com/LNP-BP/rust-lnpbp/issues/86) will be insecure and incompatible with hardware signing units, wallets or airgapped solutions. The problems is that the device must be able to verify what is hidden behind the tweak, otherwise it will be possible for a malware to change the tweak in such a way that it will substitue the underlying state transition with some other (assigning assets to the thief-controlled UTXOs) or, even, apply some taproot-based alternative spending conditions.
Thus, first, we must extend PSBT standard in a way that it will contain all state transition(s) to which transaction will be committing to, and the device must have a software able to parse and present user with this data.
It seems that this is not the same problem for inputs, as for outputs; and it will be sufficient to present device with the tweak only when it will be spending some of existing outputs containing the tweak.
Basically, for RGB we need to define a standard for custom PSBT keys providing all the required information.