Fwd: Service bits for pruned nodes



Summary:

In an email conversation between Jeff Garzik and Andy Parkins, the two discussed the most efficient storage format for Bitcoin protocol blocks. Garzik suggested using the format currently used by bitcoind - blocks/blkNNNN.dat for raw data. He argued that it was a generic format supported in multiple applications already. To make it more effective, he suggested adding a small metadata download and serving the raw block files. However, Parkins felt this was too specific to bitcoind's current storage format. Instead, he proposed supporting more bitcoin-protocol-oriented HTTP requests. Parkins' proposal would allow any client to supply the same interface rather than being forced to create blkNNNN.dat on the fly. He suggested using URLs such as http://bitcoind.example.com/block/BBBBBBBBBBBBBBBBBBBBBBB, http://bitcoind.example.com/tx/TTTTTTTTTTTTTTTTTTTTTTTT, http://bitcoind.example.com/block/oftx/TTTTTTTTTTTTTTTTTTT, http://bitcoind.example.com/peers, and http://bitcoind.example.com/peer/nnn. Essentially, this would be block explorer's raw mode but in every bitcoind. Parkins pointed out that the hardest operation for light clients is finding out the block that contains a particular transaction - something that bitcoind already knows.Garzik responded that this was a whole new client interface and went beyond the scope of an efficient HTTP protocol that downloads blocks. He argued that Parkins' proposal was closer to a full P2P rewrite over HTTP or a proxy thereof.


Updated on: 2023-06-06T16:00:49.583370+00:00