Author: Aymeric Vitte 2017-03-27 17:09:20
Published on: 2017-03-27T17:09:20+00:00
The email thread posted on the bitcoin-dev mailing list discussed various topics related to bandwidth limits, Lightning Network and identification of network splits. The idea of specifying global and per node up/down bandwidth limits, communicating these limits to peers, monitoring actual bandwidth with peers, and adjusting connections accordingly to attain bandwidth goals/limits was suggested. Additionally, it was proposed to prepay for bandwidth/data with Lightning Network and continue paying nodes who send new useful data. Refunds could be requested when a node sends useless/duplicate/invalid/spam data, and connection with nodes that don't refund could be discontinued. This incentivizes relay of unconfirmed transactions and new blocks, improving spam/DDoS resilience. Relay advertisements of available bandwidth and prices were also suggested. To identify network splits, nodes could find the hash of "nonce + pub key + tip blockhash" beating a difficulty threshold, sign, broadcast, and prove their existence and connectedness. History can be maintained and monitored for disruption, which could be made part of the messages that advertise available network bandwidth. However, one person expressed confusion regarding the importance of history in this context and why nodes trying to split would inherently not behave correctly and therefore be banned by other nodes. They also cautioned against the system becoming centralized and mentioned the Tor network's method of selecting nodes based on advertised bandwidth. Finally, links were provided for Zcash wallets, Bitcoin wallets, the torrent dynamic blocklist, checking a 10 million password list, anti-spies and private torrents, dynamic blocklist, Peersm, torrent-live, node-Tor, and GitHub.
Updated on: 2023-06-11T22:36:55.704217+00:00