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