Altcoins through BitcoinJ

332 views
Skip to first unread message

George

unread,
Feb 10, 2014, 4:55:56 AM2/10/14
to bitc...@googlegroups.com
Hello all,

I've been reviewing the code in BitcoinJ (along with MultiBit) with the idea to use it for some altcoins. I would like to verify some information I've gleaned to see if my presumptions are correct. I appreciate any and all help. Please excuse any naivety that I have with the codebase/Java/Maven as I've not been looking at it that long.

  • It looks like a majority of the coin-specific logic happens within the NetworkParameters class and its subclasses.
  • If one were to want to add an altcoin, while still including Bitcoin, it looks like the preferred method to do that would be to create new subclasses of NetworkParameters. Is that true?
  • I see that NetworkParameters also has a bunch of statically defined items such as PROTOCOL_VERSION, ID_MAINNET, TARGET_SPACING, etc. Some of these are referenced from other classes via the super-class (e.g. NetworkParameters.MAX_MONEY). I think that those references may have to be changed / refactored to reference the appropriate subclass (most of the time it looks like this is passed along as a method parameter a la "params"). Does that sound right?
  • Does the wallet, when stored, contain a serialized version of the NetworkParameters?
  • I believe that BitcoinJ stores additional data about the blockchain for verification purposes and checkpoints. I believe that to include other altcoins, this mechanism would have to be refactored so that it has multiple stores (one per currency). Can you point out the best class where this might be have to happen?
  • I noticed that the FeeCalculation is in Wallet.java and not NetworkParameters.java. Could you provide detail as to why this is? Many altcoins have different parameters for calculating the fee. It looks like that would be a natural fit for NetworkParameters, where the subclasses could manage the FeeCalculation. Would love to hear your thoughts on this.

 I'm not sure how far I will get with this, but I would like to avoid what I've read about forks like LitecoinJ (it seems the Litecoin team feels it is a "hack" and does not contain the proper fee calculation logic). Thanks again for all your help.

- George

Andreas Schildbach

unread,
Feb 10, 2014, 6:01:18 AM2/10/14
to bitc...@googlegroups.com
Hi George,

as you noticed, bitcoinj hasn't really been written with altcoins in
mind. NetworkParameters have mainly been there to accomodate for
Testnet1/2/3, which share almost all logic with Mainnet.

> * It looks like a majority of the coin-specific logic happens within
> the NetworkParameters class and its subclasses.
> * If one were to want to add an altcoin, while still including
> Bitcoin, it looks like the preferred method to do that would be to
> create new subclasses of NetworkParameters. Is that true?

Well as the name implies the class is currently more about parameters
not logic. Probably this needs to change.

> * I see that NetworkParameters also has a bunch of statically defined
> items such as PROTOCOL_VERSION, ID_MAINNET, TARGET_SPACING, etc.
> Some of these are referenced from other classes via the super-class
> (e.g. NetworkParameters.MAX_MONEY). I think that those references
> may have to be changed / refactored to reference the appropriate
> subclass (most of the time it looks like this is passed along as a
> method parameter a la "params"). Does that sound right?

I think yes, these constants should go to their respective subclasses
(in these cases perhaps an intermediate BitcoinParameters class that
extends NetworkParameters, but is extended by the current
implementations for Mainnet/Testnet.

> * Does the wallet, when stored, contain a serialized version of the
> NetworkParameters?

No, rather the params are referenced by their ID string.

> * I believe that BitcoinJ stores additional data about the blockchain
> for verification purposes and checkpoints. I believe that to include
> other altcoins, this mechanism would have to be refactored so that
> it has multiple stores (one per currency). Can you point out the
> best class where this might be have to happen?
> * I noticed that the FeeCalculation is in Wallet.java and not
> NetworkParameters.java. Could you provide detail as to why this is?
> Many altcoins have different parameters for calculating the fee. It
> looks like that would be a natural fit for NetworkParameters, where
> the subclasses could manage the FeeCalculation. Would love to hear
> your thoughts on this.

Yes, we need to find better abstractions for these parts of the logic.

I suggest you experiment on your branch with how to abstract the above
points in a way that in your branch you can run Bitcoin and your Altcoin
(and perhaps other Altcoins) in parallel.

If you're confident that your interface changes work as intended, you
submit pull requests for just the interface changes. Do not add the
logic or parameters of your altcoins to that pull request. You will
probably need to rebase your branch on bitcoinj master for quite a
while, but at least that would be a lot easier if the infrastructure is
in place.

Mike has expressed a while ago he is open to accept pull requests that
make the lives of Altcoins devs easier.

Cheers,

Andreas

George

unread,
Feb 10, 2014, 10:28:02 PM2/10/14
to bitc...@googlegroups.com
Thanks for your time and assistance Andreas! I really appreciate the pointers. Lots of food for thought.

One final question for now.

It looks like in the example code (i.e. ToyWallet.java), if you want to work with a particular network (Mainnet/Testnet), you reference those classes directly. Thus, if a fork was created for an altcoin, say mycoin, one would want to create the subclass for the coin and then reference the subclass in their wallet app. Does that sound about right?

Thanks again!

- George

Mike Hearn

unread,
Feb 11, 2014, 12:46:02 PM2/11/14
to bitc...@googlegroups.com

Although I think small changes are fine I am not going to accept any major changes for alt coins. The correct approach is to fork the library and rebase the patches periodically.

--
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 bitcoinj+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

George

unread,
Feb 12, 2014, 3:33:45 PM2/12/14
to bitc...@googlegroups.com, mi...@plan99.net
Thanks Mike,

I completely understand. I'm still in the exploratory stage, so you don't have to worry about me making pull requests any time soon. I'll most likely just be asking questions. Lots and lots of questions. Hope they don't annoy the group too much!

Personally, I'd like to be able to make as few changes to the core codebase as possible. That way, I don't have to worry about every patch to see if it conflicts with something I changed. I think it pretty much works both ways. I've noticed how MultiBit seems to have its own fork where they have an additional set of classes to accommodate serialization needs that they had. That sounds like an interesting approach, if it were to work in the altcoin case. But I suppose that's a topic for a different group.

Thanks again.

- George

Roman Mandeleil

unread,
Mar 14, 2014, 2:08:25 PM3/14/14
to bitc...@googlegroups.com, mi...@plan99.net
Hey George, 

Have you succeed to work 
with any altcoin through 
bitcoinJ ? 

- Roman
Reply all
Reply to author
Forward
0 new messages