Topic: Vulnerabilities and number of nodes (Read 1113 times)

The P2P protocol
^^^

Meaning the current one, with its weaknesses to insufficient diversity.  You can have other network topologies (which can be "peer to peer" or otherwise) and reduce/eliminate the particular weaknesses... differents set of tradeoffs, ones which would make sense in different environments.  We can freely change the networking protocol without breaking bitcoin, because even a single node that speaks both would bridge them.


Yes.   Though since you can't tell if a peer is silently dropping your messages you can't really use it as a "last option".

Addnode connects once and makes no further effort to keep the link up, beyond the fact that the address will be a recently connected address in the pool of addresses that your node knows. Keepnode attempts to keep the link up.

Possible now with the `-addnode=` option.

P2P and decentralization is essential for Bitcoin. And the network must not be totally attack proof, thats impossible. The clients must be able to recover from any attack originating from network. The multiple stage peer finding and fallback modes such as IRC, built-in long term backup nodes, .onion adresses, maybe some kind of distributet hash table or possibility to manually add known good peer as a last option.

DHT peer finding, anyone?

So which is it?


First you claim P2P is not essential to Bitcoin then you indicate that using web of trust it is possible to ensure security of bitcoin p2p connections?

Setting up p2p links with nodes you don't expect to screw you over, web of trust style, is _not_ centralized.  There are many ways to have decenteralized communication and "take TCP connections from everyone, connect out to eight others, forward everything you hear that validates... tell new neighbors about every other neighbor you've heard of"  is only one of them.

It's a good thing, because by your metric bitcoin would be "centeralized" now because people do have explicitly configured peerings.

The rest of your post is a strawman. The trust relationship between banks is not at all isomorphic to simply having a minimum fraction of peers which you trust not to black hole you and which you can safely prioritize without risk of DOS attack.

Of course it is essential.  The cornerstone of crypto-currency is a distributed network where trust in 3rd party isn't required to conduct trade.  Sure you can make centralized networks ... one already exist it is called Paypal (or eGold before they collapsed).


If I feared my ISP I would rather use a VPN to move beyond my ISP scope of control that have to rely on authenticated peers.  I mean existing banking system works because each node is authenticated and trusted by other nodes.  Of course you (as an individual) have no chance and hope of being trusted by that network and as a result must rely on a trusted member of that network.  In exchange for that reliance (limited access) you pay a significant cost to access/move your own money.

So small number of nodes simply doesn't work without high level of trust and authentication between nodes.  If the end game is for Bitcoin to replace a small network of trusted bank nodes with a new small centralized network of trusted "nonbank" nodes then it has no real utility.  You might as well just use Paypal and just hedge your exposure to dollars and/or inflation.

What do you mean by "bitcoin"?   The bitcoin distributed consensus algorithm?  The bitcoin currency formed by it?   Or the current version of the client software we happen to be using today?

In a world where there were only a few hundred full nodes we wouldn't be using the current software— we'd be using some evolved version of it.   The bitcoin distributed consensus algorithm and the bitcoin currency can function fine in that world, the current software as is— not so much.

The P2P protocol is simply not essential to bitcoin. Bitcoin can run over just about any transport, and there are already people communicating bitcoin across things which are not the P2P protocol. (e.g. compressed blockchain dumps, json messages, etc). As bitcoin grows and evolves many different transports will coexist (and no one could stop them from existing, even if we wanted to)

To make node software for the world with a few hundred nodes you'd want do to things like explicitly configure sets of 'known not-completely evil peers' with cryptographic authentication like the freenet darknet.  This kills cancer-nodes, confines DDOS and hostaging, prevent null routing and fragmentation, etc. And its pretty easy to maintain in a world with a few hundred nodes. You can even fully mesh the main nodes to each other.    

While I don't think "a few hundred nodes" is a desirable (or plausible) outcome, we're already getting some of the features needed for that hypothetical universe (see the 'keepnode' pull request) because the attacks you've described are not impossible enough for high value targets in our current diverse network but are made much more difficult with a little sprinkling of some pairwise semi-trust (because they're all mostly broken by 'have at least one honest peer'). No amount of P2P network diversity helps you if your ISP is evil and isolates your node onto a fake network... but a couple of authenticated peers elsewhere on the network kills that attack dead.

Which doesn't refute the fact that security of a p2p network is significantly degraded if only a few hundred nodes exist. Saying attacks are temporary or only affect single users is dubious and naive.  All attacks are temporary and all double spends only affect a single user (technically a pair of victims). 

"This situation again is corrected when you connect to good nodes and the blocks are compared by difficulty."
This has nothing to do with blocks.  It has to do with controlling the information a node sees, degrading the network, executing double spends, and creating disruptions in flow of transactions.

The attacks all are temporary, and will self-correct when connected to good nodes and blockchain is merged. Yes, they can be a nuisance and even you can pull a double spend, but not all users are affected by it. The 8 connection limit if unreachable from wan is not specified by protocol, the next version can change this number. This situation again is corrected when you connect to good nodes and the blocks are compared by difficulty. So the worst that attacker can do is denial of service for specified users and possible double spend. This can be achieved to any network connection, changes in protocol cannot prevend denial of service.

Where is the old thread where the blockchain splitting and network fragmentation is discussed?

If by "properly" you mean resistant to attack then no Bitcoin won't function properly with only a few hundred nodes.  Cancer nodes, DDOS, information hostaging, null routing, network fragmentation, feasible 0-confirm double spend all become realistic attack vectors if the number of nodes is small.

For example if your client is behind a firewall you are limited to 8 connections.  If the number of available nodes is small by spoofing a large number of IP diverse nodes I can ensure you only connect to me.  All 8 connections are under nodes I control.  At that point anything you do is if I let you.  Anything you see (in terms of transactions) is because I want you to see it.

There are many attacks that exploit bitcoin running with little nodes. Cancer nodes are dangerous, DOSing any node is possible, and cutting off a lot of the hash power even.

So the Bitcoin will not function properly with few hundred nodes? Sure it will function! And the time needed for transaction to get needed confirmations is more than 2 minutes, so there is no need for users to turn off the nodes, unless the Bitcoin client is bloated like Skype. I have no incentive at all to seed my Piratebay torrent files except knowing the other users benefit from it, so I leave them running for weeks. And they are way more bandwidth hungry than Bitcoin will ever be.