Article contains some outdated information, assetchains are now automatically included within komodo.
I am recovering from a cold, so not up to the usual 16hrs per day of deep coding. But no sense to waste time, so I figured I might as well close the loop on assetchains.
The above talks about the asset passport system, which in some sense was the mother of dPoW! The necessity of being able to secure many weak chains is what got me on the path to dPoW.
I have selected the Bitcoin Unlimited implementation to base the assetchains on. A couple reasons are that the MVF (minimum viable fork) btcfork project that I helped out is basing itself on that. Also instead of being insulted, I get invited to the BU slack so I can get support in making a dPoW compatible chain.
Now before you all start thinking that this will take a long amount of time, I already finished the coding for the dPoW independent portion.
As I debug the dPoW, I will have a test third party chain to verify that dPoW is able to be used by other chains easily. And since we need to make a BTCD revshare assetchain, this solves multiple issues all at the same time. I call the reference assetchain: REVS (short for revshare)
The changes I made:
1 minute block time, 1.5 day retarget
block 1 issuing of all coins (assets)
disable block reward, txfees goes to crypto777 account
on-demand blocks (no need to generate PoW depth when dPoW provides security)
command line spawning of new coins
The dPoW integration is not yet, but I believe this is the first implementation of a bitcoind fork that allows for command line spawning of new coins. iguana was the first to do this earlier this year and it is quite a handy feature.
ASSETCHAINS_PORT = GetArg("-ac_port",ASSETCHAINS_PORT);
ASSETCHAINS_MAGIC = GetArg("-ac_magic",ASSETCHAINS_MAGIC);
ASSETCHAINS_TIMESTAMP = GetArg("-ac_timestamp",ASSETCHAINS_TIMESTAMP);
ASSETCHAINS_SUPPLY = GetArg("-ac_supply",ASSETCHAINS_SUPPLY);
name = GetArg("-ac_name","name");
When the assetchaind is launched by adding the various -ac parameters, it will deterministically generate the nonce for a valid genesis block, and the genesis block and go into an idle mode waiting for transaction to arrive in the mempool. This eliminates all the blockchain space that has empty blocks.
I will have to add a special case to ignore the dPoW notarization special tx, otherwise it will keep generating blocks for each confirming notarization tx. Clearly some dPoW specific issues left to do, but then again since dPoW is not finished yet, that kind of makes sense.
Some might say it is dangerous to release something that allows anybody to create a new coin just with new command line parameters. I say that we will end up with thousands upon thousands of blockchains, this is unstoppable, so they might as well be dPoW blockchains.
outdated information below
To run an assetchain, just clone *** (Outdated Github link, deprecated)
the above launches the default assetchain, which is for REVS. To launch a different chain:
./assetchaind -gen -ac_port=pppp -ac_magic=mmmmmmmm -ac_timestamp=<unixtime> -ac_supply=<supply> -ac_name="name"
pppp is the p2p port, the rpc port will default to one above
mmmmmmmm is netmagic, just some large random number
<unixtime> is standard unix timestamp
<supply> is the total coins/assets issued
“name” is case sensitive and ~/.name will be where the coin files will end up
I tested most functions other than the on-demand blocks. let me know if you have any issues
Bitcointalk Topic Entry: https://bitcointalk.org/index.php?topic=1605144.msg16479757#msg16479757