Hay @Andreas and a happy new year! Yeah, something like that would be great.
> [...] some work and potentially be disruptive on the API I totally agree with your point - It was the main reason why I have started something on my own instead of submitting a pull request. How to continue now? I could imagine that it would make more sence to start a separate project and to get more people into the boat (etheriumj, .. ?). That would allow you, as the bitcoinj team, to stay with your code as long as this new lib is not 100% tested and ready. You could then migrate to it later on. Best regards, Marvin Am Freitag, 5. Januar 2018 16:37:12 UTC+1 schrieb Andreas Schildbach: > > I'm not against this idea, but it can be quite some work and potentially > be disruptive on the API. > > We could probably start by a submodule in bitcoinj and once that > stabilizes it could be extracted to a separate project. > > > On 12/12/2017 01:30 AM, Sean Gilligan wrote: > > Hi Marvin, > > > > Sorry for not responding sooner. We have a need for something like this > > in the ConsensusJ [0] project (formerly called bitcoinj-addons) and were > > thinking about making a proposal similar to yours. You can see some of > > the discussion on Issue #14 [1] and Issue #25 [2]. We've dabbled with > > Litecoin, Namecoin, and a couple of other chains - -and there's some > > significant Namecoin work that JeremyRand wants to merge. JeremyRand has > > been using and brought to my attention the libdohj [3] (pronounced "lib > > doge" -- like the coin) which addresses some of these issues. > > > > The ideal solution IMO would be for bitcoinj to split of some of these > > foundational classes into a separate jar (smaller and with fewer > > dependencies than bitcoinj-core) that can be used by bitcoinj and other > > chains. I haven't had much time lately to look at the latest > > alternatives, but would love to see a great, standard, open source > > solution for some common code. > > > > -- Sean > > > > [0] https://github.com/ConsensusJ/consensusj > > [1] https://github.com/ConsensusJ/consensusj/issues/14 > > [2] https://github.com/ConsensusJ/consensusj/issues/25 > > [3] https://github.com/dogecoin/libdohj > > > > > > On 12/11/17 12:00 PM, Marvin wrote: > >> I've started to setup a repo for this > >> idea: https://github.com/marvin-we/crypto-core > >> > >> Am Sonntag, 3. Dezember 2017 10:44:41 UTC+1 schrieb Marvin: > >> > >> Hello together, > >> > >> I initially created the following ticket: > >> https://github.com/bitcoinj/bitcoinj/issues/1486 > >> <https://github.com/bitcoinj/bitcoinj/issues/1486> And was asked > >> to publish this idea on the mailing list - So I hope this group is > >> the right place :) > >> > >> _____________________ > >> > >> Original Ticket: > >> > >> Hello together and a big thanks for providing this library. > >> > >> I have the follownig "feature" request: > >> > >> I develop a Java-Library for the > >> [Steem-Blockchain](https://github.com/steemit/steem/ > >> <https://github.com/steemit/steem/>) called > >> [SteemJ](https://github.com/marvin-we/steem-java-api-wrapper > >> <https://github.com/marvin-we/steem-java-api-wrapper>) and I try > >> to reuse as much parts of bitcoinJ as possible - Why? Because this > >> project is well documented, the code quality is really great and > >> the lib itself is bulletproof. > >> > >> A lot of your implementations (e.g. the ECKey object or the Utils > >> class) provide functionallities required in nearly all Blockchain > >> libs out there. Due to that a lib developer has three options: > >> > >> 1. Implement something on his/her own (e.g. IOTA) > >> 2. Use the whole bitcoinJ project (e.g. SteemJ) > >> 3. Copy your code (e.g. EtheriumJ) > >> > >> I guess number one can be pretty time consuming as it will require > >> a lot of time until the developer gained the knowledge that you > >> already have and will also not reach the code quality you offer. > >> > >> Number two is what I am currently doing. This solution has one > >> disadvantage: I need to add the whole BitcoinJ library while only > >> using some specific classes. > >> > >> Number three solves this problem, but you manually need to take > >> care of updates and merge those changes. > >> > >> So I was wondering if it would be possible to put classes that are > >> not bitcoin specific into a separate package? > >> > >> _____________________ > >> > >> -- > >> You received this message because you are subscribed to the Google > >> Groups "bitcoinj" group. > >> To unsubscribe from this group and stop receiving emails from it, send > >> an email to [email protected] <javascript:> > >> <mailto:[email protected] <javascript:>>. > >> For more options, visit https://groups.google.com/d/optout. > > > > > > -- > > You received this message because you are subscribed to the Google > > Groups "bitcoinj" group. > > To unsubscribe from this group and stop receiving emails from it, send > > an email to [email protected] <javascript:> > > <mailto:[email protected] <javascript:>>. > > For more options, visit https://groups.google.com/d/optout. > > > -- You received this message because you are subscribed to the Google Groups "bitcoinj" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
