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?