Published on: 2013-07-30T20:12:50+00:00
In a 2013 email thread, Peter Todd discusses a potential improvement to Simplified Payment Verification (SPV) security. He suggests requesting the history of a given transaction output (txout), including the previous transactions that funded it. This could be done using a non-interactive proof and sampling a subset of the prior transactions. However, the infrastructure is not currently set up for this, and txids are not constructed in ways that make these proofs cheap. Peter suggests implementing this as a soft-fork in the future.The email exchange between Wendell and Peter Todd revolves around Tor and its applicability to full and SPV nodes. Peter notes that while both types of nodes can use Tor, SPV nodes are generally less safe as they rely solely on confirmations for security. He explains how an attacker can target multiple entities using SPV by creating an invalid block header with fake payments. To improve SPV security, Peter suggests requesting the history of a txout using a zero-knowledge proof and sampling a subset of the prior transactions. However, this feature is not currently available. Peter advises against trusting zero-conf transactions and recommends using Tor to preserve privacy.The discussion on Tor in Bitcoinj focuses on the need for SOCKS support and hidden peers. It is noted that Tor doesn't act as an effective man-in-the-middle for nodes connecting to hidden services. Gregory Maxwell's idea of adding .onion addresses of seed nodes alongside DNS seeds table is mentioned as a way to establish an MITM-proof channel to a trusted seed. The suggestion is that ideally, those .onion addresses would be run by the same people as the existing seeds. Bitcoin relays .onion addresses over the P2P network, providing additional peers that are MITM-resistant. There is also a mention of adding node identities in the future to prevent sybil attacks.The conversation on the Bitcoin-development mailing list centers around the need for better configurability in Tor. Jeff Garzik suggests exploring linking directly with a Tor library instead of relying on an external process. Wendell shares a Tor.framework for Cocoa developers that embeds existing tor code and reroutes internal internet communication via Tor's proxy. Some participants feel that more significant configurability is needed in Tor itself. The release of a new Tor.framework for Cocoa developers, similar to BitcoinKit, is announced by Wendell.In July 2013, Mike Hearn suggests talking directly to the Tor protocol and choosing diverse exit nodes. However, this is complicated as Tor doesn't provide a library or API. Some believe that linking directly with a Tor library would be superior to an external process. Without such a library, one must be written.The article discusses various ideas to prevent a theoretical attack on Bitcoin, including using Tor SOCKS proxy and hard-coded long-term stable hidden peers run by trusted community members. Talking directly with the Tor protocol to choose diverse exit nodes is also suggested. While the attack is theoretical, the author is not aware of any countries blocking Bitcoin. Support for SOCKS and SSL is seen as beneficial.The discussion raises the question of whether it is advisable for SPV wallets to use Tor. Mike Hearn warns about the potential risks of connecting outbound from Tor, including being logged and MITMd by exit nodes. To support Tor well in bitcoinj, hidden peers and an anti-sybil heuristic would need to be added. The comments of Gregory Maxwell on hidden service support for bitcoind are suggested as interesting to explore further.
Updated on: 2023-08-01T05:28:06.242364+00:00