Topic: Confusing SPV server spies? - page 2. (Read 387 times)

Nothing short of mixing your coins after every transaction and running your own node will fix the problem.
Everything else just makes it harder to be tracked.

And that still comes back to who is tracking you. Big government or your ex wife.
Not to mention this all assumes you are not making traceable purchases.

-Dave

In addition to the replies above, if you don't want to broadcast a transaction via Electrum, then once you have signed it you can simply export the raw transaction hex and then use a link such as one of the following to broadcast it instead:
https://mempool.space/tx/push
https://blockchair.com/broadcast
https://blockstream.info/tx/push
https://coinb.in/#broadcast

You can do things such as alternate SPV servers each time you make a query to reduce the amount of information any single entity will collect about you.[/quote]
In addition to different servers, it would be wise to use a different Tor circuit for each query. Querying only a single address at a time is not the usual behavior of most users, and so would stand out from the crowd. The same IP address querying a single address each time would be fairly easy to link, especially since given the limited number of Electrum servers you will still end up using the same one repeatedly.

The bottom line is all of these methods are complicated, time consuming, and do not actually fix the problem.

The problem with your suggestion is that it is not possible to know which other addresses received transactions around the same time your address received a transaction. If you had this information, you would not need to query an SPV server in the first place because you would have access to all transaction information.

Even waiting until your address has received a transaction is difficult because, in most cases, you will not know for sure if you have actually received a transaction (if you knew you did, why would you be asking an SPV server for this information?) -- you might have been told that a transaction was sent to you, however in these cases, there will sometimes be a delay between when someone tells you they sent a transaction, and when a transaction is first seen on the network.

---

SPV nodes, by their nature trade privacy for resources required to run the node.

I think the best way to maximize privacy while using an SPV client (given the limitations of SPV clients) is to query a single address at a time after you have reason to believe the address has received a transaction. You can do things such as alternate SPV servers each time you make a query to reduce the amount of information any single entity will collect about you.

They are not "servers" that run separately from the network, they are simply bitcoin full nodes that are part of the bitcoin network. When you send your transaction to a Electrum node you are sending it to the bitcoin network. The only difference is that these full nodes have an extra layer which has implemented Electrum protocol.

You can technically connect to any other regular full node and send your transaction that way but it would only complicate client implementation and your client has to perform extra steps and this whole process's contribution to your privacy is very small so it is not worth implementing.

There is no point trying to obfuscate addresses by sending redundant data, that would just massively increase server load for honest SPV servers while doing little to nothing for the malicious SPV servers. You absolutely can push your transactions to a random node, assuming you're not actively having a targeted sybil attack on you. There was a wallet that actually did exactly this, but I forgot what wallet it was (only vaguely remember looking through the code for that).

The problem is that bloom filter or whatever methods being used by most wallets uses are fundamentally flawed. The onus should be on the wallet to change their ways of querying the server in a bid to improve privacy. Wasabi for example, uses BIP158 which requests for the entire block as well as additional decoys from their peers. This would be far more effective at tackling the root of the issue.

Let's say the bot always queries the same addresses. So every time I query addresses 1, 2, and 3, my bot queries addresses 6, 8, and 2. That doesn't do much for my privacy - addresses 1, 2, and 3, are still linked together by the malicious server, even if it wrongly thinks addresses 6 and 8 are also linked.

Let's say on the other hand, the bot queries different addresses. So the first time I query addresses 1, 2, and 3, and my bot queries address 6, 8, and 2. The next time I connect, I still query 1, 2, and 3, but my bot queries 5, 9, and 1. The next time, 1, 2, 3, and 4, 8, 9. Over time, it is obvious which addresses are the ones I am actually interested in and which are just being added to obfuscate things.

There is also the issue as PN7 rightly points out, that your bot will be querying addresses which have either already received a transaction or will never receive a transaction, whereas you will likely be querying addresses which have not received a transaction but then later do. The way around both these issues that I see would be to create a wallet while offline, pull out a single address to use, and then only after you have received coins to that address, import that address to a new watch only wallet along with 10+ other random addresses which first received coins around the same time as your address did. Then you would be querying 10+ unrelated addresses, all of which were brand new but just received coins around the same time. This is still far from perfect though and seems like an incredibly clunky way to do things when you could just run your own node instead.

I don't think it would work very well.

I don't think a spying SPV server is going to care about any address query of an address that has already received one or more transactions. By the time an address receives a transaction, it will be public knowledge that the address exists.

I think it would be more efficient for a spying SPV server to keep track of unfunded (never used) addresses that receive a transaction after an inquiry is made about the address. So if Bob asks about a particular address that has never been used, that later receives a transaction, there is a very small number of people who would know ahead of time that address will receive a transaction.

The above is possible because SPV nodes will ask about all addresses that have been used plus additional x addresses (the gap limit).

Again, I know how the protocol is written, but I don't understand why it's written that way. Why can't it connect with the peers from the Bitcoin network? It doesn't have to receive any blocks just to send them a transaction. It remains a lightweight client, it just doesn't send the transaction to a server, but broadcasts them instead.

The lightweight client could also have the set of rules and could return an error in case the full nodes you sent the transaction reject it.

You don't need to run a node to have a list of peers.

Because that is how the protocol was written. The client just has a list of private keys and knows nothing else.

If you want to create the transaction and send it there are many places that you can do that manually. But if there is an issue you have to track it down and figure it out yourself.
If you are sending it out through a fully synced node that has a known set of protocols / commands then is there is an issue you can reply with a known error code.

Otherwise if you want to transmit to the network you still need a list of nodes that will accept it, or you have to run your own node or at least get a list of peers you can transmit to.

Or you can just run your own full node and call it a day. As has been discussed, you can get an old machine with a 1TB drive for well under $100 and do it yourself if you are worried.

I just setup an electrum server last night for a test. Went for an old Dell 3rd gen core i5 laptop $45 and and used an old spinning drive that I had sitting around. But if I needed the drive it would have only been another $25 or so. If you are concerned about privacy then it's not that difficult to do. I cheat and just copy the blockchain from an existing node I have but outside the sync time it's not that long a process and not that tough. What I wanted to do didn't work but that's another story.

-Dave

I know how they work, what I don't understand is why you should send the transaction raw to an SPV server which will then send it to the Bitcoin network. Why don't you send it to the Bitcoin network in the first place?

The SPV server's job should only be to return you your balance.

Because that is how electrum (and other light wallets) work.
They don't hold any blockchain data and connect to the servers to get balances and transmit transactions.

You can get around this by running your own server but at that point you don't have to worry about SPV spies.

Side note, but if you are concerned about privacy when using things that rely on other servers then you should be sure your client allows you to select which server you connect to.

-Dave

Yeah, about that... Why do the transaction has to necessarily be transmitted through an SPV server?

In addition to the Electrum SPV servers, now there is also a bot that knows the IP addresses of those who connect to it (unless TOR or VPN is used).
It will make surveillance a little less hard, but it's safe to assume that among those addresses that will be queried, Alice or Bob will also check on the balance of their own set of addresses.   

You don't but at least you can reduce the risk of being connected to the same entity by choosing another Electrum node. It is also possible to connect to any regular nodes (not Electrum ones) and send your transaction to them by sending a tx message which would reduce the risk even more.

How do you know that the other node doesn't belong to the same evil spying entity?

They would only ban you if you are spamming them with requests. There is no need to do that, the bot could add a long delay and query each node for addresses once.
But I agree that this doesn't seem like a productive way.

In my opinion the best option still remains to be including more irrelevant addresses in your query somehow. For example your own client could ask bc1q6, bc1q8, bc1q2 balances where bc1q6, bc1q8 are not yours and then when spending from bc1q2 it broadcasts the tx to another node.

They will still know what addresses are connected when you make and sign a transaction that is transmitted through their server.
And
If you just keep making queries and never send a TX it would be trivial to figure out that they are just bots.
And
If you ask about some of my addresses that are going out through a known server then they know at that point that you are not 100% legit. So if other addresses are known to be transacting through certain servers and you ask about them it will also be obvious that you are just looking.

I'm sure there are more issues out there too with this.
Good in theory, do not see any real way of implementing it.

-Dave

It would probably still be easy to separate the two/three/etc. given some time. The nodes would also start banning you. In theory PIR could be better if it could work in practice (resources being the limit). Best to just run your own node.

I was wondering if it'd be effective to enhance everyone's privacy by making the chain analysis companies' job harder. Say, for instance, to setup a bot that randomly picks funded addresses and queries them into those SPV servers.

Example:  Bob is the owner of bc1q1, bc1q2 and bc1q3. Alice is the owner of bc1q4, bc1q5, bc1q6. Charlie is the owner of bc1q7, bc1q8, bc1q9.

If they select a server, which is a spy one in this case, their addresses will be linked and they will, therefore, lose privacy. What I propose is to setup a bot that queries those addresses in a random order to make it harder for the server to recognize which address is who.

Bob's query:
Give me the balances of bc1q1, bc1q2 and bc1q3.

Bot's query:
Give me the balances of bc1q6, bc1q8, bc1q2.

etc. Can this really work in the least or there's a flaw I have not thought of?