Thanks. I'm not a fan of using abstract classes for this, templates are
better (specialisation). But the factory idea is interesting. In the
end, there seems to be no perfect design and integrating alts will
involve some form of compromise.
ATM my targets are simply Litecoin and Dogecoin.

On 15/05/14 10:29, Jorge Timón wrote:
> I think one good approach is to have interfaces (abstract classes)
> that are later extended with a concrete implementation for each chain,
> much like the CChainParams class for the mainnet, testnet and regtest
> modes in bitcoin-qt. You should be also able to discard some altchains
> at compile time (maybe to avoid special dependencies).
> That way the system can be compiled for all the alts and then run for
> one of them specifying a parameter like has been discussed already.
> Polymorphism will do the rest.
>
> The parts to move to interfaces depend a lot on the nature of the
> currency itself.
> For dumb changes like different inter-block times you're probably fine
> with a chainparams class with static parameters.
>
> For different proof of work you probably need a pow abstract class too.
>
> There's currencies that may need to change the money type as well, for
> example, Freicoin uses the GMP library's arbitrary-precision rational
> number type for increased divisibility and interest calculations. See
> this pull request on bitcoin-qt to replace uint64_t with a CMoney
> type:
>
> https://github.com/bitcoin/bitcoin/pull/4067
>
> You could use templates for the concrete implementations of the
> abstract class and then maybe use a factory pattern for instanciation.
> Maybe you can get some inspiration on this old project of mine.
> Here's an abstract class:
>
> https://github.com/jtimon/preann/blob/master/src/neural/buffer.h
>
> A concrete implementation for CUDA (with templates for the data type):
>
> https://github.com/jtimon/preann/blob/master/src/factory/cuda/cudaBuffer.h
>
> And the factory:
>
> https://github.com/jtimon/preann/blob/master/src/factory/factory.cpp
>
> With this you can discard implementations at compile time:
>
> https://github.com/jtimon/preann/blob/master/src/factory/configFactory.h
>
> I hope at least some of this is useful.
>
>
> On 5/14/14, Amir Taaki <genjix@???> wrote:
>> Here's some experimentation by me to see how it could look in libbitcoin:
>>
>> http://ideone.com/01YG2K
>>
>> Notes:
>>
>> * Every free function would become templated.
>> * I am looking for a way to avoid having different semantics for classes
>> to refer to values (currency_->some_value()) vs for functions
>> (Constants::some).
>> An option is to make classes templated too, and then libbitcoin would
>> become a nearly totally header only library (like the standard library).
>>
>> On 14/05/14 17:13, mlmikael wrote:
>>> So now proper subject on this thread.
>>>
>>> On 2014-05-14 16:28, Thomas Hartman wrote:
>>>> I suppose
>>>>
>>>> sx --currency=litecoin
>>>>
>>>> with bitcoin default might work. This would be backwards compatible.
>>>
>>> Yeah, sx -c LTC / --currency=LTC would be nice , with BTC as default.
>>>
>>>> That being said, to me, this is only a really attractive option if all
>>>> the currency-specific code can be specified in an config file that is
>>>> read at compile time.
>>>>
>>>> I suppose this would be things like the genesis block, and scrypt vs
>>>> sha.
>>>>
>>>> Perhaps a similar mechanism could also be used to control whether
>>>> testnet or mainnet is specified.
>>>>
>>>> Maybe there is a way to distinguish testnet/mainnet with sx already
>>>> but I couldn't figure it out.
>>>
>>> At the end of the day I guess there will be some custom programming
>>> needed for an altcoin beyond a config file, because there will be some
>>> coin-specific logics and config files don't do logics.
>>>
>>> Perhaps an alternative to hardcoding those logics as a coin-specific
>>> class in LibBitcoin, then perhaps altcoin support could be located to a
>>> per-altcoin module implemented as
>>> * a dynamically loaded shared library, or as
>>> * a Javascript module delivered by V8, if that would work well with
>>> concurrency.
>>>
>>>
>>> For understanding the viability of modularization, there would be value
>>> in someone going through these various currencies and doing a systematic
>>> comparative documentation over algorithmic/technological similarity and
>>> difference.
>>>
>>> Since they tend to be BitcoinD forks, that ought to be quite
>>> straightforward, however I guess it would easily become a very big
>>> project, quite probably beyond what anyone wants to look into now -
>>>
>>>
>>>
>>>
>>> For overview presently, coinmarketcap.com tells us that BTC and LTC are
>>> the serious players, only. Therefore,
>>>
>>> * implementing LTC would be solid value, and
>>>
>>> * also perhaps, that it could be worth checking out in detail if/how
>>> altcoin support through modules would be workable
>>>
>>>
>>>
>>> Thoughts?
>>>
>>>
>>>
>>
>>
>
>