The current interaction between simplewallet and bitmonerod is zero trust when it comes to receiving. The wallet just pulls all the blocks from the daemon and scans them itself. On sending there is some trust involved because the wallet pulls fake outputs from the daemon then constructs the transaction then sends it back to the daemon. So the daemon is well aware of which outputs were not among the fake ones it provided (and therefore those are the real ones). This could be avoided by the wallet collecting its own set of fake outputs to use, since in the current model it is receiving all of the blocks anyway. (Though there is an optimization where it doesn't receive blocks from before the wallet was created, which would get in the way.)
Is it possible to have low-trust SPV clients in Monero?
EhVedadoOAnonimato posted this 9 years ago
By low-trust, I mean a setup in which the servers that the SPV client is using do not receive information that would allow them to track the client transactions.
I imagine bloom filters with a very high false positive rate could do the trick, but I'm not sure, because when building the mixin set in order to send a payment, the client would be constrained to using only the false positive outputs it received. It wouldn't be a random distribution. I'm not sure that's acceptable. It would allow the servers to link the transactions of the wallet together by seeing the match with the filter, even if the wallet is accessing the servers through Tor.
How does the current communication between simplewallet and bitmonerod works, actually? I took a look here and didn't find anything that could hint the answer. Who constructs the transaction? I'd suppose it'd be simplewallet, but then how does it ask bitmonerod for the inputs for the mixin? If there's a RPC call of the kind "give me a random distribution of N inputs with X amount", perhaps SPV clients could send this call, with a high N to many different nodes, and then get only a few inputs from each node. Assuming the SPV wallet is not being sybil attacked, the servers would not know which is the true input.
What if the wallet was connected to multiple daemons (as an SPV should be), requested sets of outputs from different daemons, mixed some outputs from each of them (never using all outputs given by the same daemon), and finally broadcasted the transaction to another daemon from which it did not ask for outputs?
This way, the only way to track would be to Sybil attack it. Right?
About the current interaction between simplewallet and bitmonerod, by default, must it happen through localhost? Or, if somebody codes a bootstrap mechanism into simplewallet, could it go around finding bitmonerod nodes on the internet and connecting to them?
you'll probably have to dig into the code itself. Moo recently reworked the transaction construction, so his work is probably (hopefully) well documented.
The new tx construction keeps the same input selection algorithm. All the changes are in the way tx amounts are created - the step before input selection. Which currently is fone by the daemon (triangular distribution).
I added a comment saying this could be more clever though :)
Even if the wallet doesn't keep track of the outputs, I wonder how much traffic would be generated by getting all outputs of a given amount from the daemon, then doing selection locally.
In the current structure you don't need to get all the outputs, just the number of outputs of each size, which is a very small amount of data.
If you wanted to base the selection on the actual age of the outputs (which is not currently being done) then you could add some additional metrics for that, but you still wouldn't need the entire list.
> Even if the wallet doesn't keep track of the outputs, I wonder how much traffic would be generated by getting all outputs of a given amount from the daemon, then doing selection locally.
I'd say that's a no-go for a SPV wallet. It would be too much data to store.