I agree.
enough for the costs to be justified.
transmission of bitcoin addresses.
identity of other nodes in that web.
*Then* you can slap an encryption layer on top of it. Once you have
identity & P2P verified pub keys for nodes, encryption becomes easy.
Post by Eric Voskuil via bitcoin-devwallets as its justifying scenario.
Post by Gregory Maxwell via bitcoin-devIt cites SPV as an example, doesn't mention bloom filters.. and sure--
sounds like the bip text should make the
The Bitcoin network does not encrypt communication between peers today.
This opens up security issues (eg: traffic manipulation by others) and
allows for mass surveillance / analysis of bitcoin users. Mostly this is
negligible because of the nature of Bitcoins trust model, however for SPV
nodes this can have significant privacy impacts [1] and could reduce the
censorship-resistance of a peer."
This is not an example, this is the exception that is described as
"significant" in comparison to the other issues, which are described as
"negligible".
The Bloom filters messages are of course the unique aspects of the
protocol as it pertains to "SPV".
The RISKS section declares that the BIP cannot prevent MITM attacks and
that "identity authentication" will be defined in a forthcoming BIP.
The obvious implication (accepted by the author) is that authentication is
required to prevent a MITM attack, and furthermore establishment of
identity will be required to ensure that the authenticated party is not a
bad actor.
for the transactions they originate within the protocol against network
observers.
observing the network.
Post by Gregory Maxwell via bitcoin-devNot passively, undetectable, and against thousands of users at once at
low cost.
This is a straw man, as the BIP does not state that its objective is to
moderately raise the cost of passive attack against large numbers of users.
It is also a red herring, as passivity is not itself a benefit. It implies
that the attack is easier and therefore less costly. But a trivial active
attack may be a larger security problem than a complex passive attack.
Attacks against privacy under this BIP (and with authentication) can be
carried out by passively monitoring traffic and operating one or more
nodes. Operating a node may be considered "active" because the node
communicates, but technically it is not. In either case the activeness
itself hardly raises the difficulty, especially for a global (thousands of
users) passive attacker.
Depending on the attacker, cost may not be an issue at all, so raising it
can have zero effect. Certainly we are not talking about prohibitive
(cryptographically hard) cost. Raising the cost *any* amount is not likely
a reasonable cost-benefit tradeoff.
Privacy attacks would remain entirely undetectable under this proposal,
and under any additional proposal that required authentication in the
absence of identity. Only with all users of the network identified as
"good" would such proposals be effective. Until that point any bad actors
can become an integral part of the network. I will investigate the question
of identity in a follow-up to an independent post.
attack to determine what the node has sent.
Post by Gregory Maxwell via bitcoin-devNot 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)
It cannot be both impossible ("not against Bitcoin Core") and limited in
effectiveness ("obviously there are limits").
We should be clear at this point that the transaction-posting security
provided against a privacy attack, based on the assumption of "good"
(identified) peers in the first few hops, derives entirely from the ability
of the good peers to break the timing attack, which is itself "limited".
This is a compound pair of weak assumptions, that to be made stronger will
require widespread use of identity (not just authentication).
The proliferation of node identity is my primary concern - this relates to
privacy and the security of the network. Secondarily I am concerned about
users operating under a false assumption about the strength of privacy.
Thirdly I am concerned about the risk of vulnerability introduced by the
integration into the P2P network layer of an totally new network security
scheme. Fourthly I'm concerned about the cost of the above based on the
belief that the benefit may not be material and that it may lead to
increased centralization.
encrypted, unencrypted later hops would rapidly
network.
authenticated, and all participants are known to be good guys. Starting to
sound like PKI?
Post by Gregory Maxwell via bitcoin-devHuh? The first and subsequent hops obscures the origin and timing.
Described as "limited" in effectiveness, and clearly useful only if these
hops are not attacker nodes.
So back to my comment on how we maintain a pool of "good" nodes for people
to connect to, and raising the question of how effective is this strategy
(which is itself unspecified and so cannot be assumed to even exist in the
context of the BIP).
Post by Gregory Maxwell via bitcoin-devPost by Eric Voskuil via bitcoin-devPost by Gregory Maxwell via bitcoin-devWithout something like BIP151 authenticated links are not possible, so
manually curated links (addnode/connect) cannot be counted on to
provide protection against partitioning sybils.
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.
Post by Gregory Maxwell via bitcoin-devDon'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
Don't want them as peers for the purpose of tx relay. As I said this,
"enables the attack you described above."
Post by Gregory Maxwell via bitcoin-devFor 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.
This whitelisting is simply a stand-in for a more formal identity system.
One doesn't whitelist anonymous peers, one whitelists peers controlled by
trusted parties. Preferring trusted peers is another aspect of trying to
break the timing attack. So I would lump this under the same analysis as
above (batching).
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.
Post by Gregory Maxwell via bitcoin-devI understood that, but my point was that Bitcoin cannot be used at
all_unless users have secure communication channels to share addresses.
This is true but not relevant. The parties with whom we transact are not
in the same space as the nodes with which we connect. The fact that I am
face-to-face with a counterparty does not help me find a "good" node, nor
does my ability to PGP email a payment address or to send a stealth address
in the clear.
But the fact that you raise this point is itself instructive. The solution
that was devised to resolve the problem of verifying that a counterparty is
who one thinks it is ended up being based on the use of certificate
authorities - despite the fact the the BIP did not require this. Some
people consider this extremely dangerous for Bitcoin, enough so that Peter
Todd recently proposed scrapping the BIP.
It's not clear to me how the Bitcoin community intends to establish what
nodes are good nodes. But one thing is certain, any anonymous node may be
an undetectable attacker.
nodes will necessarily have to connect with anonymous peers.
Post by Gregory Maxwell via bitcoin-devThey're not required to _only_ connect with anonymous peers. And
partition resistance requires that you have any one good link.
As a minimum requirement, it implies that only need only to connect to one
or more "good" peers. Anonymous peers are gravy for partition resistance,
yet they are potential attackers for tx tainting. In other words the
logical topology is to only connect to good peers. That is a problem.
very effective.
See above commentary on the irrelevance of this distinction.
concern I have raised.
I don't get your point here. It seems like you are just trying to antagonize.
Post by Gregory Maxwell via bitcoin-devWe seem to be looping now. Feel free to not implement this proposal,
At this point I think it's fair for me to say that nobody needs your permission.
Have you ever debated an optional feature proposal?
e
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev