You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
After discussion with Andrew Poelstra it became obvious that the previous decision of storing public key tweak information within PSBT as a single value (LNP-BP/rust-lnpbp#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.
The text was updated successfully, but these errors were encountered:
Agenda of the call:
1. RGB [branding](https://github.com/LNP-BP/FAQ/tree/master/RGB%20Branding%20%26%20Logo) update
2. [Reduce asset name length limit] (LNP-BP/LNPBPs#74)
3. [Support for asset name registries] (LNP-BP/LNPBPs#75)
4. [PSBT and deterministic bitcoin commitments / public key tweaks] (LNP-BP/LNPBPs#69)
5. RGB Schema update:
- Removed dust limit
- Multiple inflation rights with better control over total inflation
- Epoch-based burn and burn-and-replace procedures; enhanced with UTXO set and versioned proofs of burn data, supporting up to 15 burn proof variants (+"no proofs" option)
- Asset renomination procedure, for changing asset names or splitting stock shares after @sabina_sa proposal
- Standardization of contract text URL and commitment format
- Rights split procedure
After discussion with Andrew Poelstra it became obvious that the previous decision of storing public key tweak information within PSBT as a single value (LNP-BP/rust-lnpbp#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.
The text was updated successfully, but these errors were encountered: