Published on: 2013-08-10T20:30:46+00:00
The conversation revolves around implementing an HTTP REST wrapper around bitcoind's RPC interface in Python. The goal is to create a simple HTTP server that can translate HTTP GET requests into relevant RPC request and respond with the required data. There is a discussion about adding usual HTTP authentication/SSL stuff to the REST API so that SPV users could decide to run their own instance of the API. It was suggested that a trusted party could set up the server for users of Bitcoin Wallet. However, it was argued that anyone who wants HTTP authentication or TLS can wrap it with nginx or something similar and put appropriate restrictions in place on incoming requests to keep it secure.In an email exchange between Andreas Schildbach and Mark, they propose adding HTTP authentication/SSL to the REST API so that SPV users can run their own instance of the API or a trusted party can set up a server. Andreas suggests he would be willing to set it up for users of Bitcoin Wallet. Pieter Wuille expresses concern about the security risks and potential DoS risks associated with exposing an HTTP-based interface publicly. On the other hand, Michael argues that there are benefits to having a REST interface that is exposed publicly. While there is support for the HTTP interface, it is suggested that it be used only for trusted local applications and debugging.Andy Parkins suggests reducing the blockchain storage requirement for SPV clients to allow more nodes to participate in the network and reduce the load on full nodes. Peter Todd proposes a "Partial UTXO" mode where miners don't need to keep the entire chain as long as they don't mine transactions spending unverified UTXOs. They discuss the security risks of relying on unauthenticated UTXO data and the need for UTXO commitments. They also discuss the difference between SPV and full security and the benefits of fetching blocks by transactions.In another conversation between Andreas Schildbach and Pieter Wuille, they discuss the possibility of adding HTTP authentication/SSL to the REST API for SPV users to run their own instance or for trusted parties to set up servers. Wuille expresses concern about the security risks and potential DoS risks of exposing the HTTP-based interface publicly. He suggests that the HTTP interface should only be used for trusted local applications and debugging.Peter Todd proposes exposing the UTXO set of a given address to enable SPV wallets to sweep previously unknown private keys. However, this is deemed undesirable due to increased resource usage and vulnerability to DoS attacks. Todd suggests adding HTTP authentication/SSL to the REST API instead. They also discuss the use of address-indexed UXTOs and the issues with relying on unauthenticated data. They consider paper wallets as a potential solution but note some inherent problems.The conversation discusses the use of REST API for SPV clients, the benefits of reducing the blockchain storage requirement, and the security risks associated with exposing an HTTP-based interface publicly. The discussion also covers the need for authenticated UTXO data and the challenges of maintaining a headers-only blockchain. There is debate about the involvement of the blockchain in verifying transactions and the importance of the UTXO set. Finally, there is a suggestion to add a new URL to trace the providence of any transaction without needing to maintain the entire chain.In a discussion on the Bitcoin development mailing list, the addition of a URL for tracing the providence of any transaction without maintaining the entire blockchain was suggested. This feature would be beneficial for Simplified Payment Verification (SPV) clients. However, it was clarified that no such index is maintained by default and enabling "-txindex" is necessary to access it.Another proposal was made to expose the Unspent Transaction Output (UTXO) set of a given address. While this would be useful for SPV wallets to sweep previously unknown private keys, it was noted that there is currently no way to authenticate this data, which could potentially lead to fraudulent transactions.Jeff Garzik proposed the addition of an HTTP REST API for bitcoind, which would provide external access to transaction, address, and block indices. This would enable decentralized block explorer capabilities. The first two implemented API calls allow for simple queries based on block or transaction hash. The aim of this interface is to provide unauthenticated, public blockchain information, with no plans to add wallet interfacing or manipulation via this API.A recent pull request on Github further supports the implementation of the HTTP REST API for bitcoind. It suggests adding features like Accept and Accept-Encoding headers, as well as an API version number in the URL. Additionally, having APIs corresponding to Bitcoin addr and version messages would be helpful for certain use cases.Overall, the goal of the proposed HTTP REST API is to provide easy access to unauthenticated, public blockchain information. It does not include wallet interfacing or manipulation capabilities and has received positive feedback from developers interested in utilizing the API for their projects.
Updated on: 2023-08-01T05:22:02.236718+00:00