Author: Gregory Maxwell 2015-05-12 20:47:41
Published on: 2015-05-12T20:47:41+00:00
Jeff Garzik, a prominent Bitcoin developer, pointed out that the issue of block sync horizon/cliff is a significant concern. He noted that there is a value X which represents the average number of blocks the 90th percentile of nodes require to sync. Semi-pruned nodes can retain X blocks, but they must fall back to archive nodes for older data.Previous discussions centered around the definition of "pruned," which requires nodes to have and serve at least the last 288 blocks from their tip. There was also a flag for "I have at least the last 2016" blocks, which may need reevaluation. Sipa's old data showed that the probability of fetching a block versus depth had an exponential drop-off (with a 50% chance at approximately three days) and a low, constant probability. This information is likely what should have been expected.Years ago, there was even a more radical suggestion to refuse syncing if the data was too old (i.e., over two weeks) and force the user to download ancient data via torrent. However, this approach would make the system dependent on centralized services like trackers and sources of torrents, which is not desirable. A torrent is also not efficient in handling fractional copies and cannot efficiently grow over time. Many nodes already possess the data, and Bitcoin should be complete.
Updated on: 2023-05-19T20:21:40.286520+00:00