[ Feature Request ] Implement BIP352 sending (send to silent payment address)

[cygnet3]

BIP352 (silent payments) is entering its last revision stage and probably won't change from now, so it's time to start a discussion about possibly integrating it with wallets such as electrum.

The BIP is split in a 'sending' and a 'receiving' section which can be integrated by wallets independently. Adding 'sending' support to electrum can probably be done quite easily and with minimal impact to the internals of electrum. Receiving is more sophisticated, and is outside the scope of this issue.

@Sosthene00 and I have been working on a rust library (cygnet3/rust-silentpayments) that is intended to be used by wallets to add BIP352 support. We can use this library along with Python bindings (e.g. with mozilla/uniffi-rs) to add sending support. Another option is to write a python native implementation.

[edwargix]

Since libsecp256k1 is already a required dependency, I assume electrum can use the send/receive functionality implemented in bitcoin-core/secp256k1#1519 (once it's merged) (?)

[SomberNight]

Note: naively RBF-ing a tx (in a way the changes the input set) that pays to a silent payment address will ~burn the coins.

This means that when having the same Electrum wallet on both a laptop and a phone (or after restoring from seed), the device that did not create the tx - at the very least - would need to know not to allow RBF-ing it.

We have a similar problem for LN funding txs (#7072), where we decided to store this data in the input nSequence by not opting into RBF.

[siwatanejo]

This means that when having the same Electrum wallet on both a laptop and a phone (or after restoring from seed), the device that did not create the tx - at the very least - would need to know not to allow RBF-ing it.

We have a similar problem for LN funding txs (#7072), where we decided to store this data in the input nSequence by not opting into RBF.

What happens if fullRBF gets activated?