Privacy best practices?
--
One group of planned features on ElectrumSV’s roadmap is related to privacy. It’s been a while since I thought about these, so there’s value in revisiting them. Especially since payment protocols are a hot topic for Bitcoin SV these days.
Potential best practices
There are no formal best practices in Bitcoin SV application development. However, these might be considered to be best practices in coin management aimed at ensuring privacy is natural in the way we use Bitcoin SV.
I have written articles on privacy-related topics before, but they were based on my understanding at that time and I’ve avoided rereading them so I can flesh this out and hopefully arrive at a fresh view. While this will of course be ElectrumSV-centric, I think that it will also be generally relevant.
Transaction exchange and merge avoidance
ElectrumSV does not currently do merge avoidance. Merge avoidance is where you have the ability to pay someone with a group of transactions, and not just one transaction. Ideally, you spend one coin in each transaction and this way none of your coins are linked together.
The reason we do not handle it is that payment protocols do not exist that allow this. It was not even on the radar when both Paymail and BIP270 were formalised at the first wallet workshop that CoinGeek held. I do have a vague memory of Ryan X. Charles mentioning Mike Hearn’s article on the subject to me there (skip to that article’s Merge Avoidance section).
We probably need a modified BIP270 to support multi-transaction payments, in order to be able to use this in an SPV future.
Benford’s law and change management
There is no ability in our current payments to provide privacy to the recipient. What I mean by this is that when you send a payment to a recipient in ElectrumSV, it just sends one coin with the value they asked for. This value is revealed, and if the recipient’s transactions can be identified on the blockchain in some way, it might be that the value can be mapped to what they were paid for. Or for that matter, what you are paying them for.
The observer might see that one payment transaction resembles the price of a coffee, another resembles the price of a bus ticket to wherever and yet another the uniquely priced subscription to “tingtanglers.example.com”.
How Benford’s law helps here is that it provides a way to break up a larger value into a given number of smaller values, and it chooses amounts for each of those smaller values that follow a pattern of meaningless relevance. So rather than paying the requested value as one coin, the recipient can receive a range of privacy-adding values that make up the requested value. Mike Hearn points out that the recipient should be able to state the values they want to receive rather than the payer deciding, which on reflection seems obvious.
This adds two requirements for a payment protocol, the ability to support multi-transaction payments, and the ability for the recipient to know that even though there is no coin of the value they requested in any one of those transactions, which of the smaller privacy-enhancing values included in them they are receiving. Craig talks about this in his article Bitcoin’s Privacy Model (read the Coin splitting and Randomised more private splitting sections in that article).
There are probably many nuances that need best practice definitions, like what if the number of outputs provided by the recipient is lower than the number of spent coins. Programmers know how it is, before you can come up with a workable model you need to consider all the edge cases.
SPV
SPV does not necessarily add any extra privacy. However, Craig does suggest (read the Maintaining privacy; ensuring scalability section in that article) that when you pay a merchant, the merchant should be left to broadcast the transaction.
As the merchant, Bob sends the transactions to the blockchain, and not Alice; she has more privacy than if she sent it herself. … As Bob sends the transactions, and as he is likely to be a merchant with many transactions, his IP address is made public, not Alice’s.
There is the question of what Craig is talking about here, how is an IP address made public? Presumably this is to the service used to broadcast. Currently for ElectrumSV this is still whatever ElectrumX indexer they are connected to, but in the near future this would be the chosen MAPI host presumably always run by a miner.
The payer only cares whether the transaction is broadcast if they have change that they want to spend, because they want the merkle proof for those change coins in order to spend them again with SPV. There’s an advantage in the payer broadcasting for that reason. Now we come back to multi-transaction payments, it is likely that only one of those transactions would include change to the payer. And in theory, if one pre-splits larger coins into usefully sized change coins ready for use in payment transactions (again see the Coin splitting section of Craig’s Bitcoin’s Privacy Model article), that change should be minimally sized and it should be possible to evaluate the value of broadcasting it.
At this point if you really wanted, you could derive a heuristic for when to broadcast the transaction, but chances are most merchants will have to broadcast them and provide you with any merkle proofs you need in any viable protocol. The cases where this does not happen should be easily identifiable and in those cases, the payer can broadcast themselves and complain about the recipient on Twitter or something if they even notice.
Dust
You have probably heard about dust spam. The way it works is that someone with some Bitcoin SV to burn scans the blockchain and identifies a large number of payment destinations (likely those that have addresses) that coins have been sent to. Then they send very small amounts to all those payment destinations, with the aim that they are spent along with other coins held by the owner of each address. There is probably an increasing benefit in doing this, where the more addresses that are tagged the more chance there is of inferring spending links.
This is a problem for ElectrumSV 1.3 as it still uses the legacy model of listening to the blockchain for reuse of any payment destination in the wallet, and we use the single transaction payments mentioned above. This means that if someone sends you dust spam, it gets mixed in with your other coins and spent revealing information about you.
In our yet to be officially released ElectrumSV 1.4 code we still use blockchain monitoring to work out when you receive a payment, but we stop monitoring a payment destination when the expected payment is received. The reason we still monitor the blockchain is that we currently have no other way to detect incoming payments, but as SPV and payment protocol standards are released and useful hosted services become available for us to use we will switch away from this. ElectrumSV has other complications like the unique need we have to support seed-based wallet restoration moving into the future, and the ability we offer to do a scan for payments over all possible used keys. These leave us with a residual cases where we may still receive spam transactions where most other wallets never will.
The simplest approach is to freeze any unexpected payments, which means that they will not be counted in the wallet balance nor considered for use in any payments that are made. We are however wanting to move towards a default interface designed for regular people, which means we will want to present this in a way where why what happens, happens, is clear. And there is already a formal way to dispose of dust spam privately, which the wallet can do automatically, ideally also in a user-friendly manner. You can see Matej and Steve discuss this topic and the solution at BSV DevCon 2021.
I do wonder if ElectrumSV will be the only wallet using this solution though, because we do have a level of advanced functionality that other wallets may never need. Why would they be listening to or scanning the blockchain for address reuse? Will they ever see dust spam? I do not know.
Final thoughts
The key requirement for this model of normalised privacy to proceed is that we get payment protocols that support recipient provided outputs (including the value for each) over multi-transaction payments. Beyond that, most of the work is perhaps in coming up with a user-friendly user interface that makes it seem effortless to users who are regular people and not developers or who have had to be indoctrinated into Bitcoin technicalities.
Other priorities are higher
This is something I want to see in ElectrumSV as soon as possible, but in terms of priority it falls behind SPV support and user-friendly backups. There are however benefits in writing an article like this long before we are going to work on these things:
- It highlights that we may need to push for the prerequisites as soon as possible, like multi-transaction payments and recipient provided outputs.
- If community members with a minimal required level of development skill wish to learn Bitcoin SV it’s part of a wider pool of tasks that they could pick from and attempt to develop, with mentoring from my co-developer AustEcon [SV] and I.
That is assuming that no-one comes forward with better ideas, or shows that the assumptions made were mistaken!
What do you think?
Is this a valid set of best practices for normalising privacy expectations from all the people you exchange coins with? Maybe. It could also be riddled with misconceptions, this is where you come in.. let me know either way. Comment below, or discuss it on Unwriter’s Slack, or the Metanet.ICU Slack. Twitter is very unusable for any discussion, but you can comment on this article on Medium if you are not interested in joining those Slacks.
