Published on: 2014-11-30T16:38:42+00:00
In an email conversation between Btc Drak and Oliver Egginger, Egginger asks for a C library for blockchain analysis and provides a link to picocoin's library. In response, Drak suggests MatthewLM's cbitcoin as an alternative option. Egginger highlights picocoin's ability to parse raw blocks and transactions and mentions their Github repository. Drak notes that cbitcoin is a good alternative to picocoin, mentioning its features such as being valgrind-clean, supporting all core and P2P data structures, and being able to parse and index the blockchain.On November 28, 2014, Egginger sent an email asking for a C library for block chain analysis and provided a link to the picocoin repository on Github. In response, there was a suggestion of another library called cbitcoin along with a Github link.In a discussion on the Bitcoin development mailing list, Mem Wallet asked if the internal libraries of Bitcoin could be made suitable for third-party development of Bitcoin-related services and tools. Wladimir responded that the plan is to provide the consensus functionality as a library in future versions of Bitcoin, with a basic transaction/script verifier already available in version 0.10. The plan for the next version is to extend this to further utxo set management, with plans also in place to add a library for transaction signing. However, there is no goal to expose everything as a library, particularly wallet- or user interface-related functionality. Specialized utility libraries would serve this purpose better. An off-topic question was also raised regarding the use of picocoin for blockchain analysis, with Oliver seeking opinions on its limitations.A recent comment on Github suggests breaking out distinct repositories may be a good approach, but it is unclear what would be in separate repositories. Wladimir explained in response to Mem Wallet's inquiry that the plan is to provide the consensus functionality as a library, where essential parts that make Bitcoin, Bitcoin will be made available. However, not everything will be exposed as a library, and specialized utility libraries would fill this purpose better. Wladimir referenced libbase58 for base58 processing as an example. Another project broke out stealth and coinjoin as distinct repositories and made them installable using npm. The message concludes with links to Abis.io, a protocol concept for decentralization and expansion of a giving economy, and a new social good.In response to a question from Mem Wallet, Wladimir explains that the plan is to provide consensus functionality as a library, starting with a basic transaction/script verifier in version 0.10. This functionality is expected to be extended to further utxo set management in future versions, but no API has been worked out yet. There are also plans to add a library for transaction signing. However, not everything will be exposed as a library, particularly wallet- or user interface-related functionality. Specialized utility libraries, like libbase58 for base58 processing on GitHub, would serve this purpose better.In the context provided, there are two minor observations regarding the libbitcoin_common.a library. Firstly, DecodeBase58Check is listed as inline in the header but is not actually inlined, making it both non-present in libbitcoin_common.a and unavailable to other code that would use it as a library. This is identified as a potential bug. Secondly, the hierarchy of tools within the library is poor/weak, with base58.h being an example of an independent low level math/string library that includes caddress, requiring chainparams and making the whole dependency tree quite involved. It is unclear whether there is an intention to strengthen and hierarchicalize the various internal libraries such that they would be suitable for third-party development of Bitcoin-related services and tools. It is also unclear if some other project would have to fill such a role.
Updated on: 2023-08-01T10:54:36.255358+00:00