Based on the level of funding that we have gotten so far, we wont be able to fund 64 nodes, so it is likely that we will end up with 32 notary nodes.
While it is possible the last days will bring in more funds, if to estimate the likely level, it is safer to assume 32 notary nodes
But I guess it will be updated to 64 nodes once Komodo will more than double its value soon.  I am hoping big for this project. This should be part of my Christmas gift. There is intense discussion in #elections channel about this topic. everybody is welcome to join. with KMD market price not knowable until trading starts, I dont want to rely on appreciation in KMD price to fund the notary nodes. There should be enough to fund the subsidized nodes for a predetermined time, regardless of marketprice. of course if the market price sustains at above 25 cents, then there is no problem for indefinite subsidy |
|
|
|
|
Based on the level of funding that we have gotten so far, we wont be able to fund 64 nodes, so it is likely that we will end up with 32 notary nodes.
While it is possible the last days will bring in more funds, if to estimate the likely level, it is safer to assume 32 notary nodes
|
|
|
|
What about zclassic ?
what about it? making a zcash clone is as easy as: ./komodod -ac_name=zclassic -ac_supply=21000000 the above will create 21 million zclassic coins, and just add more nodes and you get a network since there is no practical limit to the number of such zcash clones that can be made via command line, i dont see much value creation by ZCL |
|
|
|
guys is it easy to allow KMD for alternative anon tech? just for marketing purposes. If it's not very hard to do - allowing different tech of anon - just because people have some beliefs - could be good marketing strategy. Obviously here I'm talking about monero tech  Or monero can be simply used by iguana wallet as alternative currency? so in the end those users will be attracted as well? Perfect would be to have some kind of ?API? to easily plug in alternative anon tech if any new/better/more wanted by people appears. This idea is good but not feasible I think. Monero is based on Cryptonote tech originally used in Bytecoin. Shadowcash and NAV are other anon-coins not based on Cryptonote but I don't know if they can be added to Iguana It would be possible, but I personally wont be able to do it any time soon. especially the basilisk mode is suited for non-bitcoin protocol coins. If other protocols want to help extend iguana, I am certainly open to working with them. |
|
|
|
|
Now assetchains are nearing completion, it would be good if there was someone working on a GUI to manage the creation of new chains. I havent yet added all the possible variants as getting the basics working with dPoW was the priority. And nothing better to make clear what all the options that are needed than having a GUI made for it. Plz post in #komodo if you are available to work on such a GUI, it would likely end up being a page in satinder's iguana GUI.
The main function I see in the GUI is "create chain" and it needs at a minimum a name, pubkeys of notarizers, supply. Once a chain is started, then other nodes can use the generated iguana code to connect to it or run another mining node.
under the hood, what is needed is:
./komodod -ac_name=NAME -ac_supply=1000000
the above starts the chain and other nodes would connect to it via:
./komodod -ac_name=NAME -ac_supply=1000000 -addnode=<ipaddress>
at this point there is a fully working zcash clone called NAME, it deterministically generates a genesis block, port, netmagic and sends the supply coins to the wallet of the creator. Normal transactions can be done along with protected zcash transactions and even the DEX and LP nodes can be used with the NAME coin.
I just updated it so when you spawn a new assetchain, the matched genCOIN file to add it to iguana is automatically created. it even synced the first blocks
If you are able to do GUI and some systems work (ie. automate creation of explorers) contact me. This is a paid task, just not sure how much work it will be so the first step is to get a qualified person to assess the amount of work it is
|
|
|
|
http://148.251.57.148/tx/15f3f684a48977dbbecf2c29aecf68e9a5e447325241d4bfe767c3cf6b8c27daabove is the first fiat chain redeem. it was triggered by the EUR tx http://148.251.56.54/tx/5d5c9a49489b558de9e84f991f996dedaae6b9d0f157f82b2fec64662476d5cfwhich redeemed 0.10 EUR via the paxwithdraw function. it got a bit complicated, but there is essentially a decentralized gateway (generalized MGW) to achieve the bi-directional deposit/redeem across the different blockchains. It has a lot of similarity to sidechains, but there is no need for waiting 1 day (or 2 days?) for the transactions to confirm. For now I am not waiting for the notarizations so the testing can go faster. Once we verify it is all happy, then I will require notarizations in both directions before the funds are released. The above EUR redeem was indeed notarized the next block: http://148.251.56.54/tx/2cc20d19f0651714a222ace2c9fe2f2b548502e6289c208fb7dcbb3448dc728bAnd that was echoed in the KMD chain, which on the next notarization to BTC also notarized the EUR redeem transaction. Basically the dPoW is working as intended, but still we need to continue to verify things. The todo list is down to a few final items: 1. error check fiat redeem amounts 2. net balance limiter, activate dPoW for all fiats3. verify: interest payment, ratification, reorgs non-komodod tasks 4. REVS and non-fiat chains done 5. automate notarization fee payouts 6. automated distribution of test REVS snapshot
|
|
|
|
I'm sure BTCD was on cryptsy. Did big Vern steal them, and if he did do you know which addresses they were in? What if big Vern swaps his stolen BTCD for KMD and gets a huge stake? You would make him a whale.
yes it was on cryptsy we can only assume whether big vern kept all the altcoin wallets or not no idea what addresses they were in BTCD wasnt a very high volume coin, so I doubt there was any large percentage on cryptsy as it was the third behind poloniex and bittrex. I dont see that this would lead to any huge stake. no whale possibility |
|
|
|
EUR http://148.251.56.54/ and USD http://148.251.56.52/ are explorers for the fiat assetchains latest komodod appears to work properly with paxdeposit, ie. you can convert KMD into fiat equivalent automatically based on the current pricefeed. a hardfork that enables 5% APR issuing early next week is released and after several iterations the ratification process is looking much better. The interest awards are one of the last items remaining that could require a hardfork to the KMD test chain. Assuming we can get it enabled and debugged, what is left is the reverse withdraw of the pax fiat assetchains and consensus on maximum exposure. I will try to finish the remaining komodod changes required by mid-Nov, along with third party chain dPoW functionality so there wont be distractions when I switch to porting the native DEX to the notary nodes. At that point, we would be ready to declare the existing KMD test chain as the mainnet and we would have 33 dPoW secured assetchains (32 fiat equivalents and REVS) |
|
|
|
I think there will be a little less money in ico . ( 2385.44 BTC ) They could not reach 10% more.
I think 2388 btc is not bad. It is actually very high and is leading compared to all other current ICOs out there. It's just that developers are engraving a super high market cap. It is the market that determines the market cap. It seems you are confusing having a finite cap as somehow translating to market cap, as opposed to not having a cap on funds raised. Using that logic, if there is no cap to funds raised, does it mean an infinite market cap? The max amount is instead of having no limit via uncapped, that's all. The actual amount will be less than the max amount, that is because the max amount is a maximum that is there instead of having no limit. The KMD will not be distributed based on the max amount so it should be clear that the max amount has no effect on anything, other than limiting the total amount that could be raised. What this means is that if the ICO were to be ending now, the KMD will be distributed based on 2385 BTC (with various bonuses applied) and certainly not based on 30k BTC raised. This is because 30K BTC was not raised, that is the max limit. |
|
|
|
this issue has to do with spending coinbase outputs and requiring exact amounts to be used in this special case. with komodo we mine to transparent addresses so this issue is avoided as usual, every little issue with zcash is turned into the end of the world. Since vast majority of people will never mine zcash block and the pools will be getting the vast majority of blocks, it seems just a minor inconvenience for zcash. KMD is not affected by spending of protected mining outputs (coinbase) since KMD coinbase are not in protected mode |
|
|
|
Now that the assetchains appears to be working somewhat stably, we decided to do a ratify test. We have had a dozen new testnet nodes that want to be notaries, but until there is a ratify in the blockchain, there is no change in the official list of notaries. ./komodo-cli notaries <height> -> prints the notaries as of any height, but they only change at multiple of 1000 boundary. It required 14 signatures to approve the 41 candidates: 010000000ebafa7ccd71645c16911fa2f8fbef0b06d86056a706a94d5425513acf945bb1502900000049483045022100d748d913fbb14b440f33f6fd092c54b03a05cb432dee12146bc44a602a4baece022001c21c9ce2522b4253fb30009dde52cc1973efad8a8355e8bfd2e87d35e720d601ffffffffe7d1741bbf78877bf9fcb9fef640f6b3fe694c45f46ca4b38ed9ea166bb39a2f0700000049483045022100e02d3c4cc381d2fdcc219112a65cddd836f952e39f8fc5e5e80cc88eda728ee90220058974b9b991102ff99a80cae60fbc9798d5096b57a1c297dcd4270bd8cfe03001ffffffff2a1be95086ecb5f87439d83e2621db13966ab6a92fd339095a8ab04e227b8aa3100000004847304402206e47bdf5b7e092ecba5ea6023a4669f9b0b918e9a68bd99c0c9a2aa05ba27c2d022025f2fb70470d88718608f61ee82c9825c66a0dc9edb55c1a4a3ee0f0ca812d1801ffffffff25a67ebd1b949a5b5290885b548b4d20ee0bd659894df6093da500cedc73fdd41400000048473044022002af1b0528082b7c4bb8a824cf119cdc68ca38268e780eabb28b58c37045f9b202205997020504a48cfd0d2504a59597405f6af6f56caa6a143c7b38fac8253120de01ffffffff968098fa9a1698ed444c1ce4ffa8138e3dca357121d4746538a079a4d98ef3df0b00000048473044022059152cd0da36e00e581719cfc4284a42905173c76ff8e49846c831ef689d495502206fb0910add9aae73676c65b57c7fed1940764edebb9059ecf1c567d99856189f01ffffffff7b7c3c5ce0a65edf90952d8a0d92e2598847e0095062968d9d11d927d2bc609b0f0000004847304402205a3f96069fa58defd2d4fa02ddb05445de4ef80f70d0cc5cdf08f0ef42ca9dc10220237f57a66e8aa8aaf7a42441242459892e5d22b286cd2ad3ec55d6dce7ed188301ffffffff069abb44b1610600723404d676941a5f9830638044b91ee4fd2d3f1c32679a1b2f00000048473044022043c17a0616e69b7c632355df03ad0189ef74285a4a1ffe4d09241a108471176f0220696104a44d52d246d7140090fb8cad77914120ac746a48479ca280a290c2128201ffffffff093140fbda2ee097df32a12060eafef38de302402b377c4fc3ee1fd2ee90747e050000004948304502210083b9221c5f348867d80ec9fa32f7c9e0c756ce1d69b52f4dc8eec4e1559fce6202200aeb491620add182753e3295860ac625b08e10963a2012c9435162feaa5899a501ffffffffcf7943fb2576ee47ba8bf9c837a60203714932e21698de1ce02292cf5bc43fc72e000000484730440220176e19fbb2424cc0631d413b42a9a106e505b37f90fecc359de639f900a3e3f40220781a6abf92b61621ace8c1374b3c4f29fbb25ecf28fa7508ffdb8cd36c4cf01501ffffffff5714c5c0a7b1b4ed6cd30123b8d74fc91db837b34b7e376fb59b9cb215ef055d0700000049483045022100865cddf0efc9a7ca6a47e39c8657a3d795ab2d567ab50b4c3956757cb725e55d02202b750376e073aa1e25118508fb9c35498eb1dc4b29144628af2145a958ba500201ffffffff39e2c81d31542a469853b1afd94bb3a498ef0456864e44c43075e326ef83bbd51800000048473044022043ade8abda4ec2e8e71edd72b75625b982274c89376e464146a0c2a6d54af1ef0220153fbe1547d9f09634f47bd07ba77614915fd6f5f2f6a36552d3cb90691e37db01ffffffff9586d03ca0adfae3bbadaa0e40ccc3ec4383236bd41e78020b194cd48b267db81e00000049483045022100c19b5c0ee61dd9319f12f861d0e4fcf40f928386dc03f4730e3ea77ffd22624102205f47cd81cb17b1f4aa01a4dcdb102f2299265311a0b3b01079e41f7ca2d054c501ffffffffe82a80ab39e0da57d7f0a103e72d27a75f4600d216711aeecd8ab1dcf947d0350b00000049483045022100e9da3355db3ee48a51a697cbffacff2f5234ddf5057f90dfc46e5db47288720d022008af175d2491ceed91e8478f09afaf91b847262ef9e61ab7c2cff1f370e0a54c01ffffffff8384ae7879de8214c95975fe5ac42d36459146ac93df02b4e035eb19f3db7b9e28000000484730440220335d465defd2b6a6ebbb6f91ecea03811cf31e0be88a7c45bbac518acceba060022014e71486e214cfa582caab0f90a7687bf69c0b063d7b2d7b310377c112be74f501ffffffff2a10270000000000002321020e46e79a2a8d12b9b5d12c7a91adb4e454edfae43c0a0cb805427d2ac7613fd9ac7017000000000000232103b7621b44118017a16043f19b30cc8a4cfe068ac4e42417bae16ba460c80f3828ac7017000000000000232102ebfc784a4ba768aad88d44d1045d240d47b26e248cafaf1c5169a42d7a61d344ac70170000000000002321029d93ef78197dc93892d2a30e5a54865f41e0ca3ab7eb8e3dcbc59c8756b6e355ac7017000000000000232103cda6ca5c2d02db201488a54a548dbfc10533bdc275d5ea11928e8d6ab33c2185ac701700000000000023210209d48554768dd8dada988b98aca23405057ac4b5b46838a9378b95c3e79b9b9eac701700000000000023210340c66cf2c41c41efb420af57867baa765e8468c12aa996bfd816e1e07e410728ac7017000000000000232102bcbd287670bdca2c31e5d50130adb5dea1b53198f18abeec7211825f47485d57ac70170000000000002321023cb3e593fb85c5659688528e9a4f1c4c7f19206edc7e517d20f794ba686fd6d6ac7017000000000000232103f5c08dadffa0ffcafb8dd7ffc38c22887bd02702a6c9ac3440deddcf2837692bac70170000000000002321025c6d26649b9d397e63323d96db42a9d3caad82e1d6076970efe5056c00c0779bac70170000000000002321021ab53bc6cf2c46b8a5456759f9d608966eff87384c2b52c0ac4cc8dd51e9cc42ac70170000000000002321032fb104e5eaa704a38a52c126af8f67e870d70f82977e5b2f093d5c1c21ae5899ac701700000000000023210225aa6f6f19e543180b31153d9e6d55d41bc7ec2ba191fd29f19a2f973544e29dac701700000000000023210287aa4b73988ba26cf6565d815786caf0d2c4af704d7883d163ee89cd9977edecac7017000000000000232102061c6278b91fd4ac5cab4401100ffa3b2d5a277e8f71db23401cc071b3665546ac7017000000000000232103517fcac101fed480ae4f2caf775560065957930d8c1facc83e30077e45bdd199ac70170000000000002321033fb7231bb66484081952890d9a03f91164fb27d392d9152ec41336b71b15fbd0ac701700000000000023210224e31f93eff0cc30eaf0b2389fbc591085c0e122c4d11862c1729d090106c842ac7017000000000000232102afa1a9f948e1634a29dc718d218e9d150c531cfa852843a1643a02184a63c1a7ac70170000000000002321029e1c01131974f4cd3f564cc0c00eb87a0f9721043fbc1ca60f9bd0a1f73f64a1ac7017000000000000232102708dcda7c45fb54b78469673c2587bfdd126e381654819c4c23df0e00b679622ac70170000000000002321031bcfdbb62268e2ff8dfffeb9ddff7fe95fca46778c77eebff9c3829dfa1bb411ac70170000000000002321033c073366152b6b01535e15dd966a3a8039169584d06e27d92a69889b720d44e1ac701700000000000023210387046d9745414fb58a0fa3599078af5073e10347e4657ef7259a99cb4f10ad47ac70170000000000002321026b49dd3923b78a592c1b475f208e23698d3f085c4c3b4906a59faf659fd9530bac7017000000000000232102313d72f9a16055737e14cfc528dcd5d0ef094cfce23d0348fe974b6b1a32e5f0ac7017000000000000232103212a73f5d38a675ee3cdc6e82542a96c38c3d1c79d25a1ed2e42fcf6a8be4e68ac7017000000000000232102209073bc0943451498de57f802650311b1f12aa6deffcd893da198a544c04f36ac70170000000000002321035f49d7a308dd9a209e894321f010d21b7793461b0c89d6d9231a3fe5f68d9960ac70170000000000002321029acf1dcd9f5ff9c455f8bb717d4ae0c703e089d16cf8424619c491dff5994c90ac701700000000000023210204a908350b8142698fdb6fabefc97fe0e04f537adc7522ba7a1e8f3bec003d4aac7017000000000000232102ffda5a0147e781308fe66a1774793eacd9b35829073746b217845cfe7577b7dcac70170000000000002321032e1c213787312099158f2d74a89e8240a991d162d4ce8017d8504d1d7004f735ac7017000000000000232103f54b2c24f82632e3cdebe4568ba0acf487a80f8a89779173cdb78f74514847ceac701700000000000023210300ecf9121cccf14cf9423e2adb5d98ce0c4e251721fa345dec2e03abeffbab3fac7017000000000000232102a348b03b9c1a8eac1b56f85c402b041c9bce918833f2ea16d13452309052a982ac7017000000000000232102bdd8840a34486f38305f311c0e2ae73e84046f6e9c3dd3571e32e58339d20937ac70170000000000002321034e804867936874d2dcef56ab5696f5fba059db069eb4f5c2887c61e6c60638b1ac701700000000000023210281b1ad28d238a2b217e0af123ce020b79e91b9b10ad65a7917216eda6fe64bf7ac7017000000000000232102f236c98c025fccf8b24e96d489ca03a4345d0ec18660c03c67a522bc827b614eac7017000000000000232103681ffdf17c8f4f0008cefb7fa0779c5e888339cdf932f0974483787a4d6747c1ac00000000
and after we got the required ratify done by the 14+ notaries, the above tx was created. Unfortunately due to going from 14 to 41 there wasnt enough to pay for txfee as the same fixed size utxo was used. So I need to tweak the process to include a bigger utxo and then we will get the ratified list into the blockchain. Since as of last week, I use the data from the blockchain for the official notary list, so once it gets to the blockchain, it should automatically switch to the new list. While I was waiting for the ratification, I also got iguana to sync the KMD chain, at least with transparent tx. |
|
|
|
Komodo is separate from zcash right?
Yes they are two different coins. Komodo adds features that are not found in Zcash. What are the features that it adds? I read that it uses the Bitcoin blockchain. There's no way for it to be traceable there right? the notarization tx are created by notary nodes and this is public, we want to know that the notaries notarized it, so those are fully traceable. komodo provides bitcoin security for itself and other blockchains. I am currently debugging 32 such blockchains, one for each of 32 different fiat equivalents. Each of these USD chain, EUR chain, etc. will be secured by dPoW. Due to the way blockhashes are calculated, every transaction in the KMD chain is notarized when the KMD blockhash is notarized. This means every transaction in the KMD chain is notarized, including the transaction that notarized the USD assetchain. There is no practical limit to the number of other blockchains that KMD can notarize. Please note that the notarization process is independent of zcash technology. However, by having the zcash tech, it means you can protect your funds, be it KMD, USD assetchain, etc. |
|
|
|
|
assetchains testing found some strange BDB incompatibility I fixed assetchains, but not in the way you would expect
instead of battling against strange DB errors invoked by code that isnt mine, I wanted a clear path to a solution. so I decided to merge assetchains into komodod
i also made komodo-cli understand -ac_name=USD
just build komodod and you get assetchains
./komodod -ac_name=NAMEOFCHAIN
that will make a new chain with a bit more than 10 coins
-ac_supply=1000000 will issue 1 million
I am still debugging the paxdeposit -> issuing via decentralized gateway, but it appears to work well enough (I hope) for multiple nodes to sync
The other benefit is that we can now get zcash protection on fiat as each fiat is now also a zcash fork. And anybody can create a zcash fork from the command line.
|
|
|
|
It will be under 1 BTC per ZEC within days.
I would guess within hours, there's only 4 ZEC for sale on Polo. But nonetheless I see this as very positive for Komodo. Komodo has a great potential like ZEC.Happy to be a part of it To put things in perspective, if KMD can achieve 1/100000th the current price of ZEC, it would be about triple the implied price of current ICO funds raised So to achieve 1/10000th the price would be 10x that, or 30x Using LTC to BTC ratio of 200:1 would assume that KMD is a pure fork with no value added. So while we cant really predict any such pricing, nor can we expect ZEC to maintain its current price level, even at max raise there would be room for price increases. and with the current pace there will be that much more room. |
|
|
|
https://z.cash/blog/the-design-of-the-ceremony.htmlDo you really think all participants are colluding together? There is no financial incentive for the zcash insiders to do this as they already get the 20% and compromising it would cost them far more than they will make
|
|
|
|
rebased komodod to the zcash mainnet version rebuilding now and testing One of the risk factors was what happens if zcash delayed their mainnet release. That is not an issue anymore as it is already on block 300. Good thing about the "slow start" with tens of thousands of CPU/GPU mining, the first 20,000 blocks could well be mined in a few days. Another risk factor was whether komodod would be ready within 2 weeks after the end of the ICO. It appears to be almost ready now. We still need to validate 5% APR interest issuance and election ratification, but considering that there is still 3 weeks+ of ICO left, it seems that we can even get some bonus features like PAX and maybe even DEX working before the mainnet. Current implied pricing of KMD vs ZEC is at about a 10,000:1 ratio, which is quite a lot higher than the poll results: https://bitcointalk.org/index.php?topic=1659890.0 |
|
|
|
|
I would like to welcome ca333 to the komodo technical team. He will be in charge of security and will be doing regular audits on the codebase and APIs. He has also come up with a novel solution, but I will let him introduce himself more.
|
|
|
|
|
Released a new version of assetchains. (github.com/jl777/assetchains)
Make sure to install parallel to komodo so you end up with:
<dir>/komodo/src
<dir>/assetchains/src
It was a bit tricky to get the bitcoin codebase to run multiple coins at once, but I managed to get it to autospawn a new coin based on just the name. Various things are configurable from the commandline, but only the ac_name parameter is actually needed:
./assetchaind -ac_name=USD
From that, it autogenerates a genesis deterministically so all nodes end up with the identical genesis, it also generates different network magics and ports. By convention the rpc port I made one more than the p2p port.
SuperNET/iguana/tests/assetchains spawns 32 fiat assetchains.
after args: +USD port.10078 magic.b6117643 timestamp.1475772963 supply.10
after args: +EUR port.14589 magic.08b9c7e4 timestamp.1475772963 supply.10
after args: +GBP port.10973 magic.e0b0f630 timestamp.1475772963 supply.10
after args: +CAD port.13695 magic.d64ed952 timestamp.1475772963 supply.10
after args: +AUD port.13873 magic.fb64da69 timestamp.1475772963 supply.10
after args: +CZK port.14981 magic.efc70f59 timestamp.1475772963 supply.10
after args: +JPY port.13756 magic.e940ad14 timestamp.1475772963 supply.10
after args: +NZD port.13030 magic.77a0819b timestamp.1475772963 supply.10
after args: +RBL port.9084 magic.ee5ccbe4 timestamp.1475772963 supply.10
after args: +HUF port.12005 magic.1abb80ca timestamp.1475772963 supply.10
after args: +CNY port.13326 magic.32d0a944 timestamp.1475772963 supply.10
after args: +ZAR port.12883 magic.316df4fc timestamp.1475772963 supply.10
after args: +NOK port.9206 magic.d0aa7a1e timestamp.1475772963 supply.10
after args: +IDR port.12170 magic.527a1d90 timestamp.1475772963 supply.10
after args: +THB port.13565 magic.f78672db timestamp.1475772963 supply.10
after args: +KRW port.8690 magic.3d0c88a6 timestamp.1475772963 supply.10
after args: +MXN port.14948 magic.a705b45e timestamp.1475772963 supply.10
after args: +RUB port.13039 magic.0c676275 timestamp.1475772963 supply.10
after args: +SEK port.15315 magic.3ebba2b7 timestamp.1475772963 supply.10
after args: +HRK port.14554 magic.2b4b6ab0 timestamp.1475772963 supply.10
after args: +PLN port.15636 magic.9d555328 timestamp.1475772963 supply.10
after args: +USD port.10078 magic.b6117643 timestamp.1475772963 supply.10
after args: +DKK port.11814 magic.b9513acc timestamp.1475772963 supply.10
after args: +BGN port.11251 magic.6103fdfd timestamp.1475772963 supply.10
after args: +INR port.14099 magic.a895f51a timestamp.1475772963 supply.10
after args: +HKD port.12993 magic.20f4de39 timestamp.1475772963 supply.10
after args: +PHP port.12283 magic.0336ab4f timestamp.1475772963 supply.10
after args: +MYR port.8529 magic.aa1fd950 timestamp.1475772963 supply.10
after args: +TRY port.14335 magic.cdce41ec timestamp.1475772963 supply.10
after args: +ILS port.10934 magic.eda4a70e timestamp.1475772963 supply.10
after args: +SGD port.10431 magic.9c32dda4 timestamp.1475772963 supply.10
after args: +CHF port.10520 magic.e9820337 timestamp.1475772963 supply.10
after args: +RON port.11150 magic.b5fcd485 timestamp.1475772963 supply.10
With 32 blockchains, it would be a lot of empty blocks, so I have it setup to only mine new blocks when there are transactions. You might notice that the supply for each chain is set to just 10, which is $10 USD for the USD assetchain. This is just to have some coins to test, but the idea is that KMD paxdeposit command is used to deposit coins into the fiat chain.
And so that is what I have working now. A KMD paxdeposit command is monitored by the fiat chain and when seen, it will create the corresponding amount of USD coins. But wait! you say, what is the corresponding amount of USD coins? The answer is in the paxprice command, which will show the KMD cost for each USD.
So a paxdeposit calculates the KMD required to match USD, this then is seen by the USD chain, which issues the USD. USD can then be transacted like bitcoin and even the DEX will work with it once I add the fiat chains into iguana.
Then the withdraw from the fiat chain will work with a paxwithdraw command that is already implemented in the assetchaind. There is still a bit more work needed to do on the komodod side (ie. monitor assetchains and process the withdraw, but it will keep on the blockchain) but for now I am finalizing assetchain changes
Also of note is that assetchaind already integrates dPoW with a relatively easy 5 step process as described in main.cpp:
// dPoW integration steps:
// 0. make sure komodo is installed parallel to this project so ../../komodo/src/komodo.h is right
// 1. include komodo.h with KOMODO_SOURCE being the string of coin symbol
// 2. add extra test to ContextualCheckBlockHeader()
// else if ( komodo_checkpoint(¬arized_height,nHeight,hash) < 0 )
// return state.DoS(100, error("%s: forked chain %d older than last notarized (height %d) vs %d", __func__,nHeight, notarized_height));
// 3. call komodo_connectblock(pindex,*(CBlock *)&block) at the end of ConnectBlock()
// 4. call komodo_disconnect(pindex,*(CBlock *)&block) at the start of DisconnectBlock()
// 5. Make sure notarized tx are being made by notaries running iguana notary dapp. replace the notaries.h and komodo_notary.h list if using your own notary nodes.
A lot of code is shared between komodo and assetchains as a lot of the dPoW process is very similar, just with different source/dest, and the processing of komodostate is also very similar.
Next I need to update the iguana notary dapp to do the dPoW for the assetchains to complete the third party chain support of dPoW. I figured it would be cool to have 32 meaningful fiat chains to have as the first dPoW chains. Also REVS can be spawned using the identical code. Currently I dont wait for N confirmations, just so we can test things faster, but of course it will be changed to wait for the transactions to be notarized. That way, we can transact fiat chains at BTC security level.
Before we can scale PAX usage up beyond testing amounts, I will need to add some portfolio balancing code, but all this can and will be done after iguana DEX is supporting the KMD and fiat chains, as that gets us quite a lot of nice functionality.
To do:
1. add third party chain support to iguana notary dapp
2. rebase to zcash mainchain release
3. verify election ratification
4. activate 5% APR
5. iguana DEX support of KMD (ZEC) and fiat chains
6. komodod paxwithdraw and portfolio balancing
Only 2, 3, and 4 are strictly required for komodo mainchain release, but I would like to get all 6 done to avoid any hardforks soon after mainchain release
|
|
|
|
|
Show Posts
