-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feasibility for replacing Bitcoinj with Bitcoin Core SPV #1062
Comments
Neutrino might be an interesting option as well: |
Yes, I'd suggest we look into Neutrino (BIP157/BIP158)-based setups instead of bloom filters (BIP37). BIP37 is generally seen among core devs as fundamentally incompatible with privacy, and also imposes disproportional cost on full nodes (DoS vector). The main drawback of the GCS-based light node protocol is that CPU cost can be higher for the client, which could make things slow for a mobile device, but as Bisq is a desktop that should not be an issue for us. I'd be happy to contriute here, once I understand more how the bisq -> bitcoinJ integration is built. |
@chirhonul Are you familiar with the Jonas Schnelli's approach? We had a past tech session where i gave an overview about the Wallet/BitcoinJ part: |
Yes @ManfredKarrer, I have been following the bitcoin/bitcoin#9483 PR. I will take a look at the tech session recording, thanks! |
I've watched the video. It had some interesting details that I now understand better, thank you for linking it! Here is one project that may be interesting, since you mentioned in the video that integrating Bitcoin Core with Java would be hard / impossible, at least for Android. The ABCore project achieves this, using the Android NDK (https://developer.android.com/ndk/) to have a thin Java layer wrapping the Bitcoin Core C++ codebase inside an Android .apk. It's possible to install it and download a (pruned) blockchain on an Android device. I have tried it, it takes a very long time to sync the chain but does work: Since Android Studio is based on IntelliJ and uses Gradle, it might not be so hard to use the same setup to compile and package up C++ code like Bitcoin Core and bundle it inside the Bisq binary, if the RPC latency would be significant. I understand the desire to continue working with the BitcoinJ fork if possible and gradually improve the code in our fork or upstream (or a new project forming a permanent fork, if necessary). I am not familiar with BitcoinJ at all basically so that would take some warm-up period for me personally, but I do have a fairly good understanding of BIP44, BIP37, BIP157/BIP158 etc. I would be up for either working on improving our BitcoinJ fork, or planning for a migration towards client-side filtering, as well as thinking about what JVM-based lightweight client may be useful to the wider ecosystem beyond Bisq. We can maybe discuss details on short-term tasks I can start with as well as broader strategy in other channels. |
Ah thanks for the info regarding the ABCore project . Have not heard about that. We might be able to integrate Bitcoin Core the same way like we integrate the Tor binary (Bisq starts the shipped Tor binary as new process and talks via a TPC interface to it, for Bitcoin Core we could use RPC and/or ZeroMQ). I think that would give the good performance of a native app and we are always in sync with latest reference client. If that approach does not work (if the SPV model of Bitcoin Core is not feasible regarding resource behaviour) we should maybe get in touch with Samurai Wallet and Mycelium developers. They share a lot our mindset regarding privacy and at least Samurai Wallet has already implemented SegWit. I am in touch with a BitcoinJ developer who has signaled to be interested to work on Bisq after he has completed a current project (ends around August). |
I have investigated this subject in detail. Super short summary: I found no good replacement for bitcoinj that we could use today. bip157/bip158 is where the industry is going, so it is worth keeping an eye on it. In general light wallet design faces a dilemma: Privacy (prevent others knowing what addresses are mine) and Trust (don’t trust third parties) vs. Low resource consumption (storage, cpu, bandwith). An ideal bitcoinj replacement for bisq should have these features:
Resources to understand bitcoin privacy conscious wallet start-of-the-art
Some ideas to make a light wallet:
Now, the projects I evaluated... Bitcoinj
Jonas schinelli’s “hybrid full block / SPV mode” on bitcoin core
Neutrino / bip157 / bip158
Bitcoin scala implementations
Samurai wallet
Wasabi Wallet
Wallets using centralized servers
|
Btw, I had a quick look and discarded alternatives listed in https://bitcoin.org/en/choose-your-wallet :
|
Thanks @oscarguindzberg for the summary! |
@oscarguindzberg Great list. Me and my company maintain bitcoin-s and are planning on building a lite client with https://github.com/bitcoin-s/bitcoin-s-core. Currently we have rpc and core protocol functionality along with signing logic. Things that still need to be built is a stand alone wallet and p2p networking services. The goal is to allow this library to be used for a lite client for lightning network nodes, but I think it should satisfy bisqs requirements too. |
Just for the record: NBitcoin supports all these features and more. Client side compact filters and its p2p protocol (bip158 and bip157), all existing standard scripts, bech32 addresses, partially signed transactions (reviewing now), rpc client, rest client, schnorr signature (early impl), etc. Sent from my Moto G(4) using FastHub |
@lontivero Ah thanks. A pity it's not in Java.... |
FYI: Bitcoin Core plans to switch off server-side filtering by default. The change has already been merged and they plan to release it with the next major version. Node operators can still enable filtering manually. The relevant thread is on the bitcoin-dev mailing list. Topic: "Bitcoin Core to disable Bloom-based Filtering by default" |
@schildbach Thanks for the info! I expected that will happen some day and I can understand the reasoning behind it. Luckily we use our provided nodes so we an handle it, but shows that BIP 37 SPV mode reaches its final days.... |
I agree to that statement: I think as public network will become infeasible and provided BTC nodes the only working option (beside local node or private node) moving to a federated electrum server model might be better in the mid term. Will also solve many performance issues and the difficulty to find experienced BitcoinJ devs. |
Bitcoin Core SPV (Jonas Schnelli's branch) should have similar resource requirements like BitcoinJ. Investigate if that is true (downloaded data at first start up) and if it is feasible investigate best integration option. We could ship it as binary like we do with Tor and communicate via RPC. Investigate if RPC is best option and if it is fast enough (it is not very fast).
The text was updated successfully, but these errors were encountered: