Merge this functionality into bitcoinj by splitting off another jar
msgilligan opened this issue · comments
Ideally this approach can get merged into bitcoinj as originally proposed in bitcoinj/bitcoinj#1486 and discussed in the thread called Create a separate library that contains those parts which are useful for other Blockchains on the bitcoinj mailing list.
There is clearly a need for this functionality by many other Java platform crypto projects, but it would be a shame to duplicate the past, present, and future work that bitcoinj will be doing.
I'm opening this issue as a place for us to track any progress towards getting this change made in bitcoinj.
Ultimately if we can get support for the idea from Andreas Schildbach we could create a Pull Request for bitcoinj.
We've been dealing with this problem in the ConsensusJ project as well and there is some relevant discussion in Issue ConsensusJ/consensusj#25.
Hay @msgilligan,
at first, thank you very much for updating all posts in all those different places and taking care of this idea =)
Before creating this "crypto-core" repo I also thought about a pull-request, but those adjustments require a lot of changes in bitcoinj and I do not feel like I am deep enough into it, to handle all those cases properly. Beside that I wasn't sure if this idea is really welcome by the bitcoinj community due to the lack of feedback.
Sadly I haven't found ConsensusJ/consensusj#25. during my search, because it looks like you had the exact same idea way earlier :)
Yesterday I was thinking about creating a new Github organization for the project and name it jCrypto or something similar that covers multiple currencies/chains. The goal would be to create reusable components that could be used by as many projects as possible and -- of perhaps greater importance -- attract as many contributions and contributors as possible. Maybe we could even merge in libdohj. I'd love to hear your thoughts on this.
Basically this point is the final question for me: Should we all (bitcoinj, ethereumj, consensusj, steemj, ...) try to create a separate project which we and as much future chains as possible can rely on? Or do we want to submit pullrequests to somehow extract some core functionallity from bitcoinj?
If we get more people into the boat and want to go for the first approach then an organization should be created I guess :)
Thank you once again and best regards!
Hi @marvin-we -- I'm pretty busy these days, but definitely want to see a solution to this issue. Hoping we can get some feedback from @JeremyRand soon. He's done a bit of work with Namecoin in this area -- using libdohj
No problem at all @msgilligan - I think this stuff is a hobby for all of us so there is no need to stress yourself =) .
I had a look at libdohj and yeah, this is already something 👍 But with that approach you would also add a lot of unused code to your project and a new chain would still need to have their own code (e.g. a NetworkParameter Class).
My idea would be to get rid of a NetworkParameter class as far as possible. The architecture could look like this:
- Core project that is as generic as possible (e.g. crypto-core)
- Chain Core project (e.g. Bitcoin-Core) that is based on the first package and adds the dogecoin specific configurations
- ChainJ project (e.g. BitcoinJ) that uses the leightweight "bitcoin-core" to implement the final api wrapper.
Hi, sorry I'm so late to the party here. :)
I honestly don't have any particularly strong opinions on how exactly the abstractions should be done. This is partly because my level of experience with Java is fairly low (most of my development these days is in other languages; I only work on 2 projects that are Java). And it's also partly because my level of experience with BitcoinJ's API is also fairly low (I've done just enough with BitcoinJ to get Namecoin lookups working, so things like key operations are something I haven't touched in BitcoinJ). So, I suspect that my opinions are unlikely to be very informed.
I definitely agree on a high-level that it's useful to minimize dependencies that get pulled in, and that it's also useful to minimize copying of code. But beyond those vague ideals, it's probably best that I not be the one to propose a detailed design, since I simply wouldn't do a great job at that. :)
All that said, if you have any questions about Namecoin's desired use cases, I'm happy to answer those questions, so that you guys can make sure that whatever design you come up with works well for Namecoin. Would probably be a good idea to involve the libdohj maintainers in this discussion, so tagging @rnicoll . (Ross, feel free to bring in any other libdohj people into the discussion.)
On a superficial note:
Chain Core project (e.g. Bitcoin-Core)
I know this was just an example, but probably best not to use a name that will result in people (or search engines) confusing such a project with the Bitcoin C++ full node implementation called Bitcoin Core. :)
Cheers!