Hard fork proposal from last week's meeting



Summary:

The discussion on node costs versus transaction fee cost is not a critical one, as default configurations can be changed and if nodes are negatively affected by a default configuration, there will be an abundance of information about how to correct that effect by turning on pruning. The debate over blocksize limit changes drastically when we limit ourselves to not changing the syncing process for most users. Sync bandwidth usage is a critical problem for future growth and is solvable. The advantage of adopting a solution like a bundled utxo checkpoint that removes the need to sync would be tremendous, with node costs dropping by a full order of magnitude for full nodes even today, more when archival nodes are more restricted, history is bigger, and segwit blocksizes are in effect, and then blocksizes could be safely increased by nearly the same order of magnitude, increasing the utility of bitcoin and the number of people that can effectively use it.Another option is for the node sync process to function like a tor network. A very small number of seed nodes could send data on to only other nodes with the highest bandwidth available who then spread it out further and so on. However, this is complicated because the syncing process today has no ability to exchange a selfish syncing node for a high performing syncing node. Syncing bandwidth usage is a critical problem for future growth and is solvable. The upsides of fixing it are huge though. Pruned nodes are not the default configuration, which is why more users aren't running them.


Updated on: 2023-06-11T22:52:46.703637+00:00