Author: gb 2015-05-12 21:30:03
Published on: 2015-05-12T21:30:03+00:00
The author proposes the idea of partially-connected nodes that can throttle bandwidth demands. The requirement to be connected is binary for partial-blockchain nodes with a spectrum of storage options, but a throttling option would reduce bandwidth demands for weaker nodes. There are five steps in this process: (1) an option for the user -throttle=XXX that would allow the user to specify a desirable total bandwidth XXX in Gbytes/day the bitcoin client can use, (2) the client reduces the number of continuous connections, transaction or block relaying to achieve the desired throttling rate, (3) it could do this by being partially connected throughout the duty cycle or cycling the node on/off for a percentage of a 24(?) hr period, (4) have an auto setting where some smart traffic management 'just takes care of it' and manual settings that can be user configured, and (5) reduces minimum requirement for any 24(?) hr period it has received a full copy of all blocks to remain fully-validating.In the email chain, Jeff Garzik brings up a general problem where security is weakened when an attacker can DoS a small part of the chain by DoS'ing a small number of nodes. Gregory Maxwell lists seven desirable characteristics from prior discussions about block coverage, including locality, uniformity, and compact communication. He proposes two schemes that come close to meeting all criteria but fail one, such as reservoir sampling that gives uniform selection of contiguous ranges, communicating only 64 bits of data to know what blocks a node claims to have, remaining totally uniform as the chain grows, without any need to refetch but needs O(height) work to figure out what blocks a peer has from the data it communicated. Another scheme based on consistent hashes has log(height) computation, but sometimes may result in a node needing to go refetch an old block range it previously didn't store-- creating re-balancing traffic.
Updated on: 2023-06-09T20:55:44.551511+00:00