(Migrated from green_qt issue at Blockstream/green_qt#185)
For a long time Green has deliberately prevented sending assets to unconfidential addresses in order to promote the use of CT.
With the advent of Simplicity in Liquid, this restriction appears too restrictive. There are many use cases in which Simplicity contracts require unblinded amount and asset information because they need to examine it in order to enforce policies related to the details of a transaction. The Simplicity contract has nowhere to store secrets, so the transaction details will sometimes need to be unblinded prior to sending them to the contract. We got a bug report about this from a contract developer who was hoping to fund a contract instance via a Blockstream App and could not complete the transaction due to the contract's address being unconfidential.
There are other possible solutions related to whitelisting Simplicity contracts (which may interact with future designs for UI around contract interaction), but I think the best case for now would be to change the strict prohibition on unconfidential destinations to a warning (that could say that the unconfidential transaction may reduce privacy unnecessarily if the recipient is an individual or organization, but that it may be appropriate if the destination is a smart contract).
(Migrated from green_qt issue at Blockstream/green_qt#185)
For a long time Green has deliberately prevented sending assets to unconfidential addresses in order to promote the use of CT.
With the advent of Simplicity in Liquid, this restriction appears too restrictive. There are many use cases in which Simplicity contracts require unblinded amount and asset information because they need to examine it in order to enforce policies related to the details of a transaction. The Simplicity contract has nowhere to store secrets, so the transaction details will sometimes need to be unblinded prior to sending them to the contract. We got a bug report about this from a contract developer who was hoping to fund a contract instance via a Blockstream App and could not complete the transaction due to the contract's address being unconfidential.
There are other possible solutions related to whitelisting Simplicity contracts (which may interact with future designs for UI around contract interaction), but I think the best case for now would be to change the strict prohibition on unconfidential destinations to a warning (that could say that the unconfidential transaction may reduce privacy unnecessarily if the recipient is an individual or organization, but that it may be appropriate if the destination is a smart contract).