Published on: 2013-05-01T14:34:27+00:00
On May 1, 2013, Jeff Garzik proposed the idea of a generalized HTTP REST query protocol in an email. He acknowledged that it was off-topic for the current thread but suggested discussing it separately. In the same email, he provided a link to a pull request he wrote for an HTTP REST interface that downloads an encrypted wallet backup. Dr. Andy Parkins responded to Garzik's email, expressing his belief that Garzik was behind the state-of-the-art and should trust the development team's plans. They then discussed the storage format for Bitcoin protocol blocks. Garzik argued for storing blocks in their native P2P wire protocol format, while Parkins suggested parsing and separating blocks into database fields instead of duplicating bitcoind. Garzik noted that Parkins' proposal would require expanding blocks from their native form into a larger form, which would be extra work for clients downloading blocks. Garzik also mentioned that they had previously discussed an HTTP query interface as a separate topic.In another email thread, Garzik defended the storage format of Bitcoin protocol blocks, stating that it was the most efficient and supported format for multiple applications. A member of the group proposed adding support for more Bitcoin-protocol-oriented HTTP requests to allow any client to supply the same interface. Garzik disagreed, saying that this would require a whole new client interface and was outside the scope of an efficient HTTP protocol for downloading blocks. The member then suggested adding another thread listening for HTTP requests, but Garzik disagreed again.Garzik and Parkins had a conversation about the storage format for Bitcoin protocol blocks. Garzik suggested using the format currently used by bitcoind, arguing that it was a generic format supported in multiple applications. Parkins felt this was too specific to bitcoind and proposed supporting more bitcoin-protocol-oriented HTTP requests. He suggested using URLs for block, transaction, orphaned transaction, peers, and peer requests. Garzik responded that Parkins' proposal was closer to a full P2P rewrite over HTTP or a proxy thereof. They also discussed finding the ideal domain name for caching content and enhancing bitcoind to respond to HTTP.On April 30, 2013, Garzik suggested using the format currently used by bitcoind for raw data storage. He recommended adding a small metadata download and serving raw block files. Parkins disagreed, stating that this approach was not generic and too closely tied to bitcoind's current storage format. Instead, he proposed adding support for more bitcoin-protocol-oriented HTTP requests. This would create a block explorer's raw mode in every bitcoind, making it easier for light clients to find the block containing a particular transaction. Parkins also requested support for HTTP POST/PUT of signed transactions and block announcements.In response to a suggestion for an HTTP/HTTPS protocol for block downloading, Garzik expressed support for finding new ways to store and transmit blocks. However, he mentioned issues with large files when using HTTP and emphasized the need for well-defined HTTP-retrievable layout with proper headers for web caches to function properly. Garzik suggested using bitcoind's format for raw data, limiting the size to below 1GB, and adding a small metadata download to serve the raw block files.
Updated on: 2023-08-01T04:47:47.414158+00:00