Published on: 2013-07-22T13:08:58+00:00
Recently, example code has been sent to Wendell and co to use CPPJVM for bitcoinj from native code. The example code is a C++ like Hello World app that can be found on Github. Further discussions regarding this topic should take place on the bitcoinj mailing list.Bitcoinj, a Java-based implementation of the Bitcoin protocol, does not download all headers but only from the last checkpoint and discards the old ones. It differs considerably from Bitcoind and will likely continue to do so in the future. The team plans to store only relevant outputs in the wallet to save memory, as some users have wallets that don't fit in RAM. They aim to use simplified payment verification (SPV) mode, which is headers-first sync without the full block sync step, replacing it with bloom/birthday-based fetching of blocks interesting to associated wallets. In SPV, the mempool needs to be disabled and there will be other small changes. Pieter Wuille is currently working on headers-first sync, which he believes is generally very useful and fixes many edge-cases block synchronization that the blockchain currently experiences. This is also a first step towards SPV mode.In a message thread from 2013, Bitcoin developer Mike Hearn expressed his approval of the idea of headers-first sync. This approach involves synchronizing only the headers of a blockchain before requesting blocks along the best chain. It is seen as a useful step towards simplified payment verification (SPV) mode, where full block syncing is replaced with a bloom-based fetching of interesting blocks for associated wallets. Although there will be more changes required for SPV mode, disabling the mempool and making small modifications, the separate headers-sync phase will be the bulk of the work.In 2010, Satoshi suggested that client-only nodes should receive full blocks so they can scan for their own transactions instead of indexing them. The initial download would only require downloading headers as there cannot be any payments before the program's first run. The code for this mode is mostly implemented and available on Github, but it's not fully finished for end-users. Client-only re-implementations would not need to implement EvalScript at all or at most just implement the five ops used by the standard transaction templates. During a discussion in San Jose, Wendell expressed interest in hiring someone to complete a patch. Pieter Wuille introduced him to Eric Lombrozo who also showed interest but has since become busy and no detailed estimate has been produced. Wendell is interested in an open discussion around adding SPV support to bitcoind and is willing to fund or co-fund the project. He encourages options whenever possible including micro-stripped-VMs and transpilation. Mike Hearn offered to send Satoshi's old SPV patch to assist with the implementation of SPV mode in bitcoind.The discussion is about extending the BitcoinKit.framework to handle the Basic SPV concept, which was originally planned by Satoshi. However, it was not completed due to several reasons such as lack of confidence in understanding the code and the risk involved in making invasive changes to core validation code. Therefore, a separate implementation was created for better risk management and to provide an object-oriented API that people could use to build a variety of apps. Additionally, the bitcoind codebase would require serious changes for mobiles beyond that required for ordinary SPV support, making it unclear if the decision to create a separate implementation was the right call. The situation is different now, with more unit tests and more people with a good understanding of the code. If someone wanted to implement SPV mode in bitcoind, they could be sent Satoshi's old patch, which indicates the basic cut lines.There are different options for implementing a native client for Bitcoin, including embedding the Java Virtual Machine (JVM) or transpiling bitcoinj to C++. While it is possible to reduce the size of the JVM to a few megabytes, it may not be necessary for desktop apps since bandwidth has improved. Portability to Android is already possible because it is Java-based, but iOS is a challenge due to Apple's restrictions on wallet apps in its App Store.One option is to rewrite bitcoinj in C++, but this is unnecessary given the existence of j2c, which does an excellent job of transpiling Java to C++. Another option is to embed the JVM and link it with the native app using a thin interface that calls into the Java code when user-visible events occur. This approach is less ambitious than transpilation but requires writing some Java code. The auto-translator javacpp can help with this.Rewriting bitcoinj in C++ or transpiling it to C++ requires a significant amount of work but could result in a stable, portable, and extendable piece of code. Embedding the JVM requires less work and can achieve good results quickly.
Updated on: 2023-08-01T05:18:25.019063+00:00