On Tue, Jun 28, 2016 at 11:33 PM, Eric Voskuil <e...@voskuil.org> wrote: > I don't follow this comment. The BIP aims quite clearly at "SPV" wallets as > its justifying scenario.
It cites SPV as an example, doesn't mention bloom filters.. and sure-- sounds like the bip text should make the >> Without something like BIP151 network participants cannot have privacy for >> the transactions they originate within the protocol against network >> observers. > > And they won't get it with BIP151 either. Being a peer is easier than > observing the network. Not passively, undetectable, and against thousands of users at once at low cost. > If one can observe the encrypted traffic one can certainly use a timing > attack to determine what the node has sent. Not against Bitcoin Core, transactions are batched and relayed in sorted order. (obviously there are limits at what this provides; ironically, the lack of link encryption has been used to argue against privacy preserving relay behavior) >> Even if, through some extraordinary effort, their own first hop is >> encrypted, unencrypted later hops would rapidly >> expose significant information about transaction origins in the network. > > As will remain the case until all connections are encrypted and > authenticated, and all participants are known to be good guys. Starting to > sound like PKI? Huh? The first and subsequent hops obscures the origin and timing. >> Without something like BIP151 authenticated links are not possible, so >> manually curated links (addnode/connect) cannot be counted on to provide >> protection against partitioning sybils. > > If we trust the manual links we don't need/want the other links. In fact > retaining the other links enables the attack you described above. Of course > there is no need to worry about Sybil attacks when all of your peers are > authenticated. But again, let us not ignore the problems of requiring all > peers on the network be authenticated. Don't need and want them for what? For _partitioning_ resistance, you are not partitioned if you have one honest connection to the functional network. Additional peers purely reduce your partition vulnerability-- so long as an active network attacker isn't itercepting all your connections out. For privacy, you have improve transaction privacy so long as your transaction isn't initially relayed to a malicious peer-- but malicious peers can lie further out because transit nodes obscure the order of message creation. Bitcoin Core currently relays transactions first and more frequently to outbound and whitelisted peers. > Maybe I was insufficiently explicit. By "relies on identity" I meant that the > BIP is not effective without it. I did not mean to imply that the BIP itself > implements an identity scheme. I thought this was clear from the context. I understood that, but my point was that Bitcoin cannot be used at all_unless users have secure communication channels to share addresses. > then there is no reason to expect any effective improvement, since nodes will > necessarily have to connect with anonymous peers. They're not required to _only_ connect with anonymous peers. And partition resistance requires that you have any one good link. > Anyone with a node and the ability to monitor traffic should remain very > effective. Not via passive observation. > Defining an auth implementation is not a hard problem, nor is it the concern > I have raised. Glad you agree. We seem to be looping now. Feel free to not implement this proposal, no one suggests making it mandatory. _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
