Author: Mike Hearn 2011-09-06 14:52:20
Published on: 2011-09-06T14:52:20+00:00
The conversation started with Steve questioning the use case of increasing the default max connections for bitcoind without fundamentally altering the concurrency model. The issue arose in the context of scalability, as lightweight clients would be used more frequently if Bitcoin's popularity continued to grow. These clients cannot verify transactions and should not relay them, thus making them socket intensive. This could result in running out of sockets, especially since lightweight clients rely on "heard from lots of nodes" as a proxy for validity in order to show transactions immediately. One solution to this problem is to use frontend proxies, which has been used by companies like Jabber and Google in the past. If someone is already running a full node, they could increase their client capacity by bringing up a frontend proxy that can handle outbound tx broadcasts, inbound broadcasts, connection setup, relaying recently found blocks, etc. A well-written proxy could support tens of thousands of simultaneous clients, freeing up bitcoinds time for verification and wallet manipulation. This approach would be effective because maintaining connections to thousands of clients doesn't involve much brainwork, just shifting bytes around, which is especially true of Bitcoin. Hoping that lots of people run full nodes is not a viable solution as running a full node already uses lots of CPU and disk seeks, and transaction traffic increases will leave less CPU time available to service thousands of connected clients.
Updated on: 2023-06-04T18:57:53.379105+00:00