a day of mostly bugfixing. some days it feels the progress is slow, but getting things working completely is part of the process. usually the most time consuming.
we are also setting up some jenkins test points where a test point is a full coin sync from scratch. With about a dozen coins supported it is easy to make a change that slows down parallel sync without knowing about it. With the jenkins I will at least know if the latest versions are as good as the prior ones for sync stability and speed.
basilisk mode had an issue in some paths, which took a while to track down, but now I have the LP tradebot properly being able to receive the swap request, compare against its list of active pairs and conditionally send back a quote.
Really quite a lot of that process is working now, but it gets stuck on the return path to the original requestor. Strange thing is that it is doing the protocol properly as near as I can tell, but just stops.
So, I had to dig into why it was stuck and after many hours it looks like the OUT/MSG protocol I wrote about yesterday gets stuck after receiving some sequence. Instead of the problem being the DEX protocol, it turned out to be the lower level transport. I didnt see anything immediately wrong, but I think I will switch over to a single serialized request queue instead of using mutex on each thread's access to the OUT/MSG data store.
Sometimes with things that are mostly working, but not quite, "changing its shape" will evolve it so the issue goes away. And in practice even though there shouldnt be a difference between a parallel set of operations protected by mutex vs parallel request serialized by queue, a lot of times there is. Since the latter is a much more controlled system, it can be viewed as an improvement and if it also happens to make things more robust, all the better.
Topic: [ANN][KMD][dPoW] Komodo - An Open, Composable Smart Chain Platform, Secured by B - page 839. (Read 1192381 times)
September 22, 2016, 01:38:05 AM
September 21, 2016, 11:51:59 PM
I wouldn't help advertise ICOscam777's latest cash grab for any amount of money.
[...]
[...]
Yet, that's exactly what your doing right now
September 21, 2016, 07:14:19 PM
Interesting coin, alot of people with high rank ( Hero / Legendary ) join KOMODO signature campaign, i think they intrested with KOMODO concept and future. i believe KOMODO will success after launch.
Good luck KOMODO community, we are in the right place!
Good luck KOMODO community, we are in the right place!
Interesting, the count of heroes/legendaries participating a signature campaign is an indication for a successful project
I think there must be other reasons...
Nevertheless, the project sounds promising.
Maybe it's more of a case of payment to participate
Cheers Jon
I wouldn't help advertise ICOscam777's latest cash grab for any amount of money.
Why are resources better allocated for research and whitepapers being used to pump a coin that doesn't exist yet?
Because scumbags gonna scumbag, that's why.
September 21, 2016, 05:27:41 PM
Interesting coin, alot of people with high rank ( Hero / Legendary ) join KOMODO signature campaign, i think they intrested with KOMODO concept and future. i believe KOMODO will success after launch.
Good luck KOMODO community, we are in the right place!
Good luck KOMODO community, we are in the right place!
Interesting, the count of heroes/legendaries participating a signature campaign is an indication for a successful project
I think there must be other reasons...
Nevertheless, the project sounds promising.
Maybe it's more of a case of payment to participate
Cheers Jon
September 21, 2016, 03:37:16 PM
Interesting coin, alot of people with high rank ( Hero / Legendary ) join KOMODO signature campaign, i think they intrested with KOMODO concept and future. i believe KOMODO will success after launch.
Good luck KOMODO community, we are in the right place!
Good luck KOMODO community, we are in the right place!
Interesting, the count of heroes/legendaries participating a signature campaign is an indication for a successful project
I think there must be other reasons...
Nevertheless, the project sounds promising.
September 21, 2016, 01:50:49 PM
Interesting coin, alot of people with high rank ( Hero / Legendary ) join KOMODO signature campaign, i think they intrested with KOMODO concept and future. i believe KOMODO will success after launch.
Good luck KOMODO community, we are in the right place!
Thanks Bro and welcome!! Good luck KOMODO community, we are in the right place!
September 21, 2016, 10:50:51 AM
Interesting coin, alot of people with high rank ( Hero / Legendary ) join KOMODO signature campaign, i think they intrested with KOMODO concept and future. i believe KOMODO will success after launch.
Good luck KOMODO community, we are in the right place!
Good luck KOMODO community, we are in the right place!
September 21, 2016, 08:37:24 AM
In order to put the notarization protection at the validate block level, instead of the actual blockchain processing level, it will require the precise tagging of each notarization with a komodo timestamp.
Since there is a fair amount of tolerance for each node's timestamps, even after I reduced it to compensate for faster blocktimes.
All komodo notary nodes must ntp to get their clocks synchronized, but it is possible for non-notary nodes to make blocks too. But 2hours just seems like way too much tolerance. I really want to reduce the tolerance of future timestamps to less than a blocktime. If anybody sees a problem with this, let me know.
In CheckBlockHeader, the timestamp is checked last, but since that is a very fast check I think it should be the first thing that is checked for.
So, now we get a stream of blocks that are no more than 60 seconds from the future, which allows us to use any notarization timestamp that is more than 60 (or 120?) seconds old to reject any incoming block. Now, regardless of when the notarized blockhashes are used, we can see that all chains will converge as they will have the same set of raw blocks input into the system.
Not sure there is a need for a formal math proof as the consensus logic of rejecting a block is based on the set of (notarized hashes+timestamps) and the timestamps of the incoming blocks. The local clock is not part of this other than rejecting blocks from the future, so if to look at only blocks from the past, given the same set of (notarized hashes + timestamps) we end up with the same set of blocks input into the consensus logic. And with the same set of blocks input into the consensus logic, we end up with the same consensus.
Now the problem reduces to generating and propagating the (notarized hashes + timestamps) in a timely fashion so we reduce the amount of small reorgs needed in all nodes to reach the same consensus. I will put the threshold at 120 seconds, so there is time enough to propagate the notarized hashes. Due to propagation delay, it is possible for some nodes to end up temporarily on a fork if they get a block that would have been blocked by the notarized just before they receive the updated notarization info. In that case, that node would reorg using the otherwise invalidated block, but globally the mainchain has rejected that block, so even if an attacker extends the invalid block, no other node would accept it. As soon as the invalid chain is shorter than the mainchain, even this node will converge back to the mainchain. Since it is a pretty unlikely case, I think this treatment is adequate. Not sure how an attacker would be able to force any node off onto its own chain at will if a nodes system clock is ntp'ed
In order to be safe you need to make sure to wait for the bitcoin confirm and your chaintip matches the overall mainchain's. using a basilisk INF request, it is possible to quickly get the getinfo results from N random peers, so the GUI could have a display of this chaintip status
I dont think most people understand how volatile the blockchain state across all nodes actually is. To me it is like the surface of the ocean. From far away it all looks the same, but up close, it can be quite volatile.
Since there is a fair amount of tolerance for each node's timestamps, even after I reduced it to compensate for faster blocktimes.
All komodo notary nodes must ntp to get their clocks synchronized, but it is possible for non-notary nodes to make blocks too. But 2hours just seems like way too much tolerance. I really want to reduce the tolerance of future timestamps to less than a blocktime. If anybody sees a problem with this, let me know.
In CheckBlockHeader, the timestamp is checked last, but since that is a very fast check I think it should be the first thing that is checked for.
So, now we get a stream of blocks that are no more than 60 seconds from the future, which allows us to use any notarization timestamp that is more than 60 (or 120?) seconds old to reject any incoming block. Now, regardless of when the notarized blockhashes are used, we can see that all chains will converge as they will have the same set of raw blocks input into the system.
Not sure there is a need for a formal math proof as the consensus logic of rejecting a block is based on the set of (notarized hashes+timestamps) and the timestamps of the incoming blocks. The local clock is not part of this other than rejecting blocks from the future, so if to look at only blocks from the past, given the same set of (notarized hashes + timestamps) we end up with the same set of blocks input into the consensus logic. And with the same set of blocks input into the consensus logic, we end up with the same consensus.
Now the problem reduces to generating and propagating the (notarized hashes + timestamps) in a timely fashion so we reduce the amount of small reorgs needed in all nodes to reach the same consensus. I will put the threshold at 120 seconds, so there is time enough to propagate the notarized hashes. Due to propagation delay, it is possible for some nodes to end up temporarily on a fork if they get a block that would have been blocked by the notarized just before they receive the updated notarization info. In that case, that node would reorg using the otherwise invalidated block, but globally the mainchain has rejected that block, so even if an attacker extends the invalid block, no other node would accept it. As soon as the invalid chain is shorter than the mainchain, even this node will converge back to the mainchain. Since it is a pretty unlikely case, I think this treatment is adequate. Not sure how an attacker would be able to force any node off onto its own chain at will if a nodes system clock is ntp'ed
In order to be safe you need to make sure to wait for the bitcoin confirm and your chaintip matches the overall mainchain's. using a basilisk INF request, it is possible to quickly get the getinfo results from N random peers, so the GUI could have a display of this chaintip status
I dont think most people understand how volatile the blockchain state across all nodes actually is. To me it is like the surface of the ocean. From far away it all looks the same, but up close, it can be quite volatile.
September 21, 2016, 07:35:45 AM
Is Komodo just a copy of Zcash?
no.It starts with zcash, then adds dPoW and also gets iguana tech and notary nodes. here is a handy set of links into this thread so you dont have to search for the deep content:
https://bitcointalksearch.org/topic/m.16245305
https://bitcointalksearch.org/topic/m.16245472
https://bitcointalksearch.org/topic/m.16250499
https://bitcointalksearch.org/topic/m.16250635
https://bitcointalksearch.org/topic/m.16298855
https://bitcointalksearch.org/topic/m.16318305
September 21, 2016, 07:01:49 AM
Is Komodo just a copy of Zcash?
September 21, 2016, 05:45:23 AM
I pushed a new version with various bugfixes and support for a special NOTARY network. As described earlier, I used the iguana addcoin API to create a coin called NOTARY, but I added some special case code for it to handle several special basilisk commands.
Since with a single API call, iguana can spawn a thread that becomes a coin peer for a bitcoin compatible coin, using the same code to spawn the NOTARY network was the easiest way as all the peer management and basilisk support comes with it.
For those not familiar with basilisk, it is a lizard that can literally run on water. It is very lightweight and can zoom across the top of ponds. So, it made sense that the lite node support in the iguana/komodo universe is provided by basilisk.
By just changing a few fields in the addcoin request, it changes whether a full node or a basilisk node is created. Basilisk nodes query the randomly selected iguana full nodes for the publicly available blockchain info. Since all iguana full nodes have not only txindex=1 level dataset, they have a full block explorer dataset, the exact listunspent for any address as of any block is available to all the basilisk nodes. Using that data, the basilisk node can not only know its wallet balance, but can also create rawtransactions.
both are peers in the p2p coin network:
curl --url "http://127.0.0.1:7776" --data "{\"active\":1,\"agent\":\"iguana\",\"method\":\"addcoin\",\"newcoin\":\"NOTARY\",\"services\":128,\"maxpeers\":2048,\"RELAY\":1,\"VALIDATE\":1,\"portp2p\":7775,\"rpc\":0}"
vs.
curl --url "http://127.0.0.1:7778" --data "{\"active\":1,\"agent\":\"iguana\",\"method\":\"addcoin\",\"newcoin\":\"NOTARY\",\"services\":128,\"maxpeers\":2048,\"RELAY\":0,\"VALIDATE\":0,\"portp2p\":7775,\"rpc\":0}"
If NOTARY was a normal bitcoin compatible coin, the genesis block and some other fields need to be specified, ie for LTC:
curl --url "http://127.0.0.1:7778" --data "{\"RELAY\":1,\"VALIDATE\":1,\"prefetchlag\":-1,\"poll\":10,\"active\":1,\"agent\":\"iguana\",\"method\":\"addcoin\",\"startpend\":68,\"endpend\":68,\"services\":129,\"maxpeers\":256,\"newcoin\":\"LTC\",\"name\":\"Litecoin\",\"hasheaders\":1,\"useaddmultisig\":0,\"netmagic\":\"fbc0b6db\",\"p2p\":9333,\"rpc\":9332,\"pubval\":48,\"p2shval\":5,\"wifval\":176,\"txfee_satoshis\":\"100000\",\"isPoS\":0,\"minoutput\":10000,\"minconfirms\":2,\"genesishash\":\"12a765e31ffd4059bada1e25190f6e98c99d9714d334efa41a195a7e7e04bfe2\",\"genesis\":{\"version\":1,\"timestamp\":1317972665,\"nBits\":\"1e0ffff0\",\"nonce\":2084524493,\"merkle_root\":\"97ddfbbae6be97fd6cdf3e7ca13232a3afff2353e29badfab7f73011edd4ced9\"},\"alertpubkey\":\"040184710fa689ad5023690c80f3a49c8f13f8d45b8c857fbcbc8bc4a8e4d3eb4b10f4d4604fa08 dce601aaf0f470216fe1b51850b4acf21b179c45070ac7b03a9\",\"protover\":70002}"
Anyway, that was a bit of a tangent to explain how easy it is to spawn a new "coin" and with a bit of extra handling, it didnt take long to get a working NOTARY network. The actual notary nodes would be the full iguana nodes and all the others basilisk nodes on the NOTARY p2p network. The standard bitcoin messages are used to create the p2p network, ie version, verack, getaddr, addr, etc. and I have a special SuperNET network message that encapsulates iguana/basilisk commands. Currently only 5 commands are handled by the NOTARY iguana nodes: PIN, OUT, MSG, VOT, but it is very easy to add more as needed.
PIN -> special ping used to rapidly disseminate info to other full notary nodes
OUT -> nodes send messages to pubkey in channels with msgid
MSG -> nodes check messages using channels, msgid and pubkey
VOT -> handler for realtime voting, still in progress
The OUT/MSG pair are the low level method that can be used by any higher level protocol to establish pubkey <-> pubkey comms. all messages have a srchash and desthash, either can be all 0. So a send to desthash 0 is a broadcast, if srchash is 0, then it is without return address. In order to manage the traffic flow a 32bit channel is specified along with msgid. This allows an efficient way for any two nodes to establish a link with each other, without ever needing any direct IP contact.
The possibilities of what can be created using the simple OUT/MSG commands is nearly unlimited. Its initial use case will be for the DEX and while the initial version is divulging the IP address of the node to the notary nodes, it will be possible to add a layer of onion routing or even DCnet to add IP level privacy to the notary nodes. For now, this is not a high priority as the zcash privacy is unmatched and shielding IP from all but the notary nodes is a very good start.
Since I am so close to getting the full DEX protocol enabled using the NOTARY network, I will work on that next. Having a realworld use case for something is always a good way to get a systems level test. And with the OUT/MSG expected to be used by most all other protocols, it is important to get it fully working. The side benefit is that we will also get a working native (wallet to wallet) DEX for all support bitcoin compatibles. I will post more details after the basics are working
I have most of the voting protocol worked out, but it needs to percolate a bit more before I am ready to code up all the client side code.
I have also been fixing various iguana sync and RPC issues that come up as the first priority, so that is why the other parts sometimes make little progress on some days.
Since with a single API call, iguana can spawn a thread that becomes a coin peer for a bitcoin compatible coin, using the same code to spawn the NOTARY network was the easiest way as all the peer management and basilisk support comes with it.
For those not familiar with basilisk, it is a lizard that can literally run on water. It is very lightweight and can zoom across the top of ponds. So, it made sense that the lite node support in the iguana/komodo universe is provided by basilisk.
By just changing a few fields in the addcoin request, it changes whether a full node or a basilisk node is created. Basilisk nodes query the randomly selected iguana full nodes for the publicly available blockchain info. Since all iguana full nodes have not only txindex=1 level dataset, they have a full block explorer dataset, the exact listunspent for any address as of any block is available to all the basilisk nodes. Using that data, the basilisk node can not only know its wallet balance, but can also create rawtransactions.
both are peers in the p2p coin network:
curl --url "http://127.0.0.1:7776" --data "{\"active\":1,\"agent\":\"iguana\",\"method\":\"addcoin\",\"newcoin\":\"NOTARY\",\"services\":128,\"maxpeers\":2048,\"RELAY\":1,\"VALIDATE\":1,\"portp2p\":7775,\"rpc\":0}"
vs.
curl --url "http://127.0.0.1:7778" --data "{\"active\":1,\"agent\":\"iguana\",\"method\":\"addcoin\",\"newcoin\":\"NOTARY\",\"services\":128,\"maxpeers\":2048,\"RELAY\":0,\"VALIDATE\":0,\"portp2p\":7775,\"rpc\":0}"
If NOTARY was a normal bitcoin compatible coin, the genesis block and some other fields need to be specified, ie for LTC:
curl --url "http://127.0.0.1:7778" --data "{\"RELAY\":1,\"VALIDATE\":1,\"prefetchlag\":-1,\"poll\":10,\"active\":1,\"agent\":\"iguana\",\"method\":\"addcoin\",\"startpend\":68,\"endpend\":68,\"services\":129,\"maxpeers\":256,\"newcoin\":\"LTC\",\"name\":\"Litecoin\",\"hasheaders\":1,\"useaddmultisig\":0,\"netmagic\":\"fbc0b6db\",\"p2p\":9333,\"rpc\":9332,\"pubval\":48,\"p2shval\":5,\"wifval\":176,\"txfee_satoshis\":\"100000\",\"isPoS\":0,\"minoutput\":10000,\"minconfirms\":2,\"genesishash\":\"12a765e31ffd4059bada1e25190f6e98c99d9714d334efa41a195a7e7e04bfe2\",\"genesis\":{\"version\":1,\"timestamp\":1317972665,\"nBits\":\"1e0ffff0\",\"nonce\":2084524493,\"merkle_root\":\"97ddfbbae6be97fd6cdf3e7ca13232a3afff2353e29badfab7f73011edd4ced9\"},\"alertpubkey\":\"040184710fa689ad5023690c80f3a49c8f13f8d45b8c857fbcbc8bc4a8e4d3eb4b10f4d4604fa08 dce601aaf0f470216fe1b51850b4acf21b179c45070ac7b03a9\",\"protover\":70002}"
Anyway, that was a bit of a tangent to explain how easy it is to spawn a new "coin" and with a bit of extra handling, it didnt take long to get a working NOTARY network. The actual notary nodes would be the full iguana nodes and all the others basilisk nodes on the NOTARY p2p network. The standard bitcoin messages are used to create the p2p network, ie version, verack, getaddr, addr, etc. and I have a special SuperNET network message that encapsulates iguana/basilisk commands. Currently only 5 commands are handled by the NOTARY iguana nodes: PIN, OUT, MSG, VOT, but it is very easy to add more as needed.
PIN -> special ping used to rapidly disseminate info to other full notary nodes
OUT -> nodes send messages to pubkey in channels with msgid
MSG -> nodes check messages using channels, msgid and pubkey
VOT -> handler for realtime voting, still in progress
The OUT/MSG pair are the low level method that can be used by any higher level protocol to establish pubkey <-> pubkey comms. all messages have a srchash and desthash, either can be all 0. So a send to desthash 0 is a broadcast, if srchash is 0, then it is without return address. In order to manage the traffic flow a 32bit channel is specified along with msgid. This allows an efficient way for any two nodes to establish a link with each other, without ever needing any direct IP contact.
The possibilities of what can be created using the simple OUT/MSG commands is nearly unlimited. Its initial use case will be for the DEX and while the initial version is divulging the IP address of the node to the notary nodes, it will be possible to add a layer of onion routing or even DCnet to add IP level privacy to the notary nodes. For now, this is not a high priority as the zcash privacy is unmatched and shielding IP from all but the notary nodes is a very good start.
Since I am so close to getting the full DEX protocol enabled using the NOTARY network, I will work on that next. Having a realworld use case for something is always a good way to get a systems level test. And with the OUT/MSG expected to be used by most all other protocols, it is important to get it fully working. The side benefit is that we will also get a working native (wallet to wallet) DEX for all support bitcoin compatibles. I will post more details after the basics are working
I have most of the voting protocol worked out, but it needs to percolate a bit more before I am ready to code up all the client side code.
I have also been fixing various iguana sync and RPC issues that come up as the first priority, so that is why the other parts sometimes make little progress on some days.
September 20, 2016, 08:51:30 PM
What will the block time, tps, and transaction time be?
blocktime 1 mintps would be ~2000 transparent tx per 1 min block, much less for zcash tx
not sure what you mean by transaction time, the time for a tx to get confirmed in a block would be the next block in most cases.
bitcoin protection would need to wait for a bitcoin confirm
Using the iguana loosely coupled bitcoin compatible blockchains, effective tx/sec can be scaled up to very large levels just by creating many special purpose blockchains and connecting them together in a hierarchy. This type of capacity increase is for after the basic single chain, but the power of the atomic cross chain swap is more than for just doing DEX
Sounds good. Time per block isn't always time per tx. Things with offchain scaling or something like Vcash with subsecond tx but 30-90 second blocks was what I was thinking. 1 min block is nice, I feel like you compete with XMR pretty well. Will be investing. Thanks.
September 20, 2016, 05:09:59 PM
What will the block time, tps, and transaction time be?
blocktime 1 mintps would be ~2000 transparent tx per 1 min block, much less for zcash tx
not sure what you mean by transaction time, the time for a tx to get confirmed in a block would be the next block in most cases.
bitcoin protection would need to wait for a bitcoin confirm
Using the iguana loosely coupled bitcoin compatible blockchains, effective tx/sec can be scaled up to very large levels just by creating many special purpose blockchains and connecting them together in a hierarchy. This type of capacity increase is for after the basic single chain, but the power of the atomic cross chain swap is more than for just doing DEX
September 20, 2016, 01:55:55 PM
What will the block time, tps, and transaction time be?
Who cares? it's got a real cool logo
Cheers Jon
September 20, 2016, 01:31:16 PM
What will the block time, tps, and transaction time be?
September 20, 2016, 10:43:27 AM
How much Komodo do we received for 1000BTCD?
Depend how much ICO have collected!! 
maybe look this : https://steemit.com/komodo/@komodoplatform/komodo-ico-questions-and-answers
September 20, 2016, 10:15:27 AM
How much Komodo do we received for 1000BTCD?
September 20, 2016, 10:10:33 AM
I'll be here on October 15th 
September 20, 2016, 09:38:54 AM
I have subscribed to Newsletter.
Any bounties for twitter and facebook activities?
No bounties for Twitter and facebook!! Any bounties for twitter and facebook activities?
September 20, 2016, 09:23:56 AM
I have subscribed to Newsletter.
Any bounties for twitter and facebook activities?
Any bounties for twitter and facebook activities?
Jump to: