<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Let's put the UTXO commitments/anti-fraud proofs to one side for a moment. I would like to see them happen one day, but they aren't critical to these protocols and are just proving to be a distraction.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Then they make fresh random connections to different nodes and request<br>
download of the respective individual transactions from the full node.<br></blockquote><div><br></div><div>...</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">About privacy the node can make different random connections to<br>
different nodes to fetch addresses ..... The full node cant<br>
correlate the addresses as belonging to the same person by correlating<br>
the download requests for them, because they are made via different<br>
nodes.</blockquote><div><br></div><div>Apologies for the wall of text, but I don't think this will work nor solve any real problem. And I must justify such a strong statement clearly.</div><div><br></div><div><b>First: technical issues</b></div><div><br></div><div>When you download the per-block Bloom filter and test, what you get back is a set of script elements (addresses, keys, OP_RETURN tags etc). But then in the next step you are saying that you connect to random peers and request individual transactions. We don't know that at this point. All we know are a set of addresses that possibly matched. So I think what you mean is "wallets connect to random peers and request transactions in block N that match a given set of addresses". </div><div><br></div><div>This is what Bloom filtering already does, of course. Doing the test against the per-block filter first doesn't seem to buy us much because with thousands of transactions per block, even a very tiny FP rate will still trigger a match on every single one.</div><div><br></div><div>The second problem I see is that we can't do this in parallel because of the following edge case: wallet contains key K and someone sends it money using an OP_CHECKSIG output. The input which spends this output does not contain any predictable data, thus we do not know what to look for in the following blocks to detect a spend of it until we have seen the first transaction and know its hash. </div><div><br></div><div>In practice this means we must either scan through the chain in sequence and update our matching criteria if we see such an output (this is what the Bloom filtering protocol already does server-side), or we must constrain the user such that output scripts always force repetition of predictable data - this is what mostly happens today due to pay-to-address outputs, but not always, and correctness is more important than completeness.</div><div><br></div><div>If we can't do it in parallel then we must suffer a node round-trip for every single block we traverse, because we can't request long runs of blocks with a single command. That latency will kill performance dead. It's a non starter.</div><div><br></div><div>But let's imagine we don't care about OP_CHECKSIG outputs and are willing to ignore them. There are cases where they are the best and most efficient technical solution, but let's put that to one side.</div><div><br></div><div>The primary difference after making the above changes are that no one node gets a filter containing <i>all</i> our keys and addresses. I don't think a per block pre-test filter would gain us much efficiency so from a privacy perspective this is what it boils down to - sharding of the scan.</div><div><br></div><div>But we can already do this with the current Bloom filtering protocol. BitcoinJ doesn't do so because having multiple parallel scans uses up network IOPs which are a resource of unknown quantity, and because stepping through the chain in parallel with multiple peers complicates the chain sync implementation quite a bit.</div><div><br></div><div><b>Second: this doesn't solve any real problem</b></div><div><br></div><div>Who cares about collecting Bloom filters off the wire?</div><div><br></div><div>Commercial fraudsters? Doubtful. There are much easier ways to steal money.</div><div><br></div><div>Spies? Yes! Without a doubt NSA/GCHQ are building or have built databases of IP addresses to Bitcoin addresses and are correlating it via XKEYSCORE with other identifiable information.</div><div><br></div><div>However, just requesting data from different nodes doesn't help with that, because they are doing DPI and can still see all the connections, so can still combine all the filters or received transactions.</div><div><br></div><div>Ah, you say, but we're requesting everything via Tor. </div><div><br></div><div>Yes, about that. We've implemented that already. Some wallets even use it by default, like Alon & Chris' Bitcoin Authenticator wallet. It's just one line of code to activate.</div><div><br></div><div>Unfortunately there are severe practical problems to using Tor:</div><div><ol><li>If you don't have a warm consensus then booting it up is very slow. We're already slower than our competitors like <a href="http://blockchain.info">blockchain.info</a> and VISA/MasterCard, we can't make this any worse.<br><br>This one is possibly not that big a deal and can be solved with more technical tricks.<br><br></li><li>Bitcoin Core's DoS strategy means anyone can block all of Tor quite trivially. So we'd need some complicated fallback mechanism to disable Tor remotely, in case someone did this.<br><br></li><li>Bitcoin wire traffic isn't encrypted or authenticated so it makes it much easier for trolls to tamper with lots of wire traffic at once, whereas without Tor it's much harder.<br></li></ol><div>Let's ignore the fact that the Tor project insists on poking the law enforcement bear with rusty nails, and has been receiving tipoffs about plans to seize directory authorities. How much Bitcoin wallets should rely on Tor sticking around is a debate for some other time.</div></div><div><br></div><div>There's a much simpler way to fix all of this - add opportunistic encryption to the wire protocol.</div></div></div></div>