Electrum should reopen PR #9900, Silent Payments sending support (BIP 352)

[nullius]

Despite the extreme dangers of JavaScript and utter foolishness of enabling it, I’m considering that I may enable it for just long enough to login to Github and give a thumbs-down reaction.  This is a travesty:

ecdsa commented March 15, 2026, 09:38:44 AM [Member]

Sorry but I do not want new plugins to be merged, unless they have shown to be extremely popular. Please distribute your plugin as an external plugin, and submit it to https://plugins.electrum.org

[...]
🔴 ecdsa closed this March 15, 2026, 09:38:44 AM
MorenoProg commented April 28, 2026, 09:04:56 PM [Author]

@ecdsa Thanks for the response.

Quite a bit of time went into this PR, not just from my side, but also from contributors [...]

More generally, this doesn’t seem like just a question of waiting for community demand. Electrum is in a position to shape that demand. If silent payments are something you want to see adopted, supporting them here would directly contribute to that.

I’m not an Electrum user.  I used to be, long ago—but I’m not anymore, and I have no intent to use Electrum in the foreseeable future.

Nonetheless, the refusal to merge #9900 affects me, and it affects everyone:

• The third merit I ever received was from ChipMixer’s CM for one of my Jr. Member posts against Bitcoin address reuse.  I’m still encountering this problem in the wild.  What can I do?  Send another link to the Bitcoin Wiki article against Bitcoin address reuse, which people rarely bother to read the first time they see it?  Shake my fist at the sky?  Absolutely refuse to deal with anything except ZEC and XMR, and maybe LTC MWEB, on grounds that in Current Year, any coin that doesn’t fully support at least a modicum of privacy with multi-use addresses is a shitcoin lacking basic functionality?  Decline to transact?  There needs to be a permanent solution for people to receive on-chain BTC with a multi-use address, without the horrific privacy damage of address reuse!
  
  I currently have no means to receive SP, nor even to send it myself.  But that’s a problem within my own power to solve.  If I do so, I will then face another problem:  Electrum has a huge proportion of users.  Its lack of support for sending SP may be a roadblock that I cannot clear independently of anyone else.
    
• I’m preparing to wage all-out war on Bitcoin address reuse.  Whatever it takes!  I’ll campaign to educate newbies so they don’t get bad habits.  And in the holy name of Eris, I’m gonna h4x0r the satoshin@gmx.com email account, and send theymos a message saying, “theymos, upgrade your forum signature to a BIP 352 Silent Payments address before I hitman you.”
  
  But what if theymos replies, “lolwut, Electrum users won’t be able to send me sats unless they install a plugin.  P.S., you’re BANED!!”

When such a popular wallet actively refuses to support sending SP out-of-the-box, it holds back the whole Bitcoin ecosystem from finally mass-deploying a minimal mitigation a major privacy disaster.

Accordingly, if I encounter any Electrum users on this issue, with apologies to NotATether, my advice will not be, “Install NotATether’s Silent Payments sending plugin.”  Instead, it will be, “Switch to Sparrow (onion).”  If sending to a Bitcoin address requires the friction of installing software, why not go all the way?

[NotATether]

I mean, you are right. It feels kind of wrong to have a Silent Payments sending plugin without any way to receive them.

I do have a completely different software for scanning for SP addresses, it's not published yet but that is going to have to run as a completely separate daemon instead of attached to Electrum.

Built-in solutions are much better than fragmented add-ons.

[nullius]

Built-in solutions are much better than fragmented add-ons.

I applaud your work to make the Electrum SP sending plugin, but this was indeed my point—as to the sending part only.  I doubt SP can attain practical adoption, without widespread, built-in light-client support for sending.

I mean, you are right. It feels kind of wrong to have a Silent Payments sending plugin without any way to receive them.

Sorry, I should have emphasized this again:  My OP is not about receiving.  My complaint is only about Electrum’s refusal to support sending to SP addresses—built-in, out-of-the-box, with no plugin.  #9900 is only for sending.

I think that widespread support to send to SP is a necessary, but not sufficient condition for growth of SP adoption.  There’s an asymmetry between the need for ecosystem support of sending and receiving.  If there is widespread support for sending, but not receiving, then individuals and businesses who want to receive SP can choose to make the extra effort to scan—but it’s outside of their control to make other people support sending to SP.  If most people can’t send SP, why bother making the effort to receive?  In the real world, “you need to install a wallet plugin to send me money” adds way too much friction to business—potentially even a dealbreaker.

Lack of built-in sending support creates a chicken-and-egg problem.  Receivers won’t accept SP, unless people can send them money.  Electrum actively rejects built-in SP send PR #9900, because SP is insufficiently “popular”.  It won’t become popular, if lack of widespread sending support disincentivizes receivers from the extra effort to receive SP.

I do have a completely different software for scanning for SP addresses, it's not published yet but that is going to have to run as a completely separate daemon instead of attached to Electrum.

I’m interested.  What strategy does your daemon use to scan for SP without leaking any identifying/transaction-linking info to an untrusted server?

I should ask, before potentially duplicating effort.  I actually just spent most of about the past six hours (plus a chunk of yesterday) investigating the feasibility of building my own receiving software.  I haven’t yet examined what data Frigate servers provide to light clients—i.e., whether or not they provide the tweak data discussed in BIP 352 Appendix A?

For my own part, I’m very interested in lightwallet support to receive SP—but not with Electrum Protocol.  Electrum Protocol wallets used with untrusted servers already have too little privacy for me; it’s why I’m currently not using a wallet!  No wallet at all.  I currently receive BTC with curl, by anonymously polling an Esplora API server by Bitcoin address on a SOCKS5-auth isolated Tor circuit; one rare query on one Tor circuit doesn’t leak much at all to link my addresses.  I currently send BTC by using an offline copy of Core with createrawtransaction and signrawtransactionwithkey, then curl -X POST to Esplora; I may soon switch to libbtc’s bitcoin-send-tx—maybe.

What I really want is a lightweight, portable C library with a well-designed API, BIP 157/BIP 158 compact block filters, and the BIP 352 (v1.1.2/2026-10-25) Appendix A suggested strategy for SP scanning with BIP 158.  However, I cannot find any such implementation.  Perhaps I can make one myself—perhaps, but it’s a very nontrivial project, and I already lack spare cycles.  At this time, I frankly can’t afford to undertake such a project unless it pays—in money, not merely in forum merits.  Then, I can eat my own dogfood with SP.

If, perhaps, I want to go ahead with that, then I’ll probably open a new thread in Project Development.  But if your daemon is already something I can somehow use with full privacy and minimal resources, I’d prefer to save the effort. 

[ABCbits]

I do have a completely different software for scanning for SP addresses, it's not published yet but that is going to have to run as a completely separate daemon instead of attached to Electrum.

I’m interested.  What strategy does your daemon use to scan for SP without leaking any identifying/transaction-linking info to an untrusted server?

I also curious about it. One naive approach that could be considered as private-respecting is by simply sending all TX that match criteria listed on https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki#scanning-silent-payment-eligible-transactions and optionally filter by minimum block height (e.g. when you create the wallet or share the "payment address" for first time). But it's naive because many TX would be eligible and it'll be more inefficient as Taproot adaption grow.

[satscraper]

Built-in solutions are much better than fragmented add-ons.

I applaud your work to make the Electrum SP sending plugin, but this was indeed my point—as to the sending part only.  I doubt SP can attain practical adoption, without widespread, built-in light-client support for sending.

Agreed, but community already has such client, ^{namely, Sparrow}  which ^{in my view} is more advanced than Electrum because, unlike the latter, it is descriptor-based. So one possible outcome of Electrum’s current development policy could be users percolation to Sparrow. I myself gave up Electrum four years ago and now use Sparrow.

[nullius]

One naive approach that could be considered as private-respecting is by simply sending all TX that match criteria listed on https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki#scanning-silent-payment-eligible-transactions and optionally filter by minimum block height (e.g. when you create the wallet or share the "payment address" for first time).

Please see BIP 352, Appendix A: Light Client Support.

But it's naive because many TX would be eligible and it'll be more inefficient as Taproot adaption grow.

Less naïve:

Transaction cut-through

It is unlikely a light client would need to scan every block and as such can take advantage of transaction cut-through, depending on how often they choose to scan for new blocks. Empirically, ~75% of transactions with at least one non-dust unspent taproot output will have spent all non-dust taproot UTXOs in 150 blocks or less^[24]. This means a client that only scans once per day could significantly cut down on the number of blocks and the number of transactions per block that they need to request by only asking for data on transactions that were created since their last scan and that still have at least one non-dust unspent taproot output as of the current block height. Based on taproot adoption as of July 2024, a light client scanning once every 3 days would use roughly 30 MB per month^[24].

I’m curious to see what NotATether’s unpublished code does.  I presume they are following some similar approach for tweak data, as it seems impossible to preserve privacy any other way—with requests to an untrusted server.

A source of tweak data is also necessary for a BIP 158 client, which is my own interest.

Agreed, but community already has such client, ^{namely, Sparrow}  which ^{in my view} is more advanced than Electrum [...]

You missed the point, which I have stated several times in OP and in my followup.

I myself gave up Electrum four years ago and now use Sparrow.

I myself use neither Electrum nor Sparrow.

If I want an Electrum user to send me money, I cannot command them, “Switch your wallet to Sparrow so that you can send to my SP address”—which is an even bigger problem than telling them, “Go install a wallet plugin to send me money.”  They may tell me, “Shut up and give me a normal Bitcoin address that works with my wallet, or else I will decline to deal with you.”  Then, if the address will be reused multiple times, that harms my privacy.

There are many Electrum users.  That means there are many people who cannot send to SP with built-in wallet functionality.  And that discourages SP adoption.  Who wants to use an address where other people can’t or won’t send them money?

Besides—not to knock Sparrow, but it is not suitable for everyone.  I’ve spoken privately to Electrum users who cannot use the Sparrow UI for their business.  It’s a business versus consumer use thing.  Electrum has the UI they need for their use case; Sparrow does not.