Topic: [ANN][KMD][dPoW] Komodo - An Open, Composable Smart Chain Platform, Secured by B - page 132. (Read 1192053 times)

We wont be enforcing it directly, but the limit of one node per region will prevent getting too imbalanced. Also, unlike last year where there were no pre-existing notaries and it wouldnt have been good to have them all clustered, this year half the notaries are in place already and pretty spread out, so we will let the elections decide where exactly the nodes end up

Is the voting based on regions this time, are there still going to be 16 NN in each region?

I can see a scenario where a candidate gets enough VOTES to be in the top 30 in the election, but they are in a sort after region with many candidates, and they don't win one of the available places to make up the 16 from their region. What would happen in that situation? Would they get option to move to another region?

It has been a while since we had one of these, and this only applies to assetchains/parallelchains

Incident Report: SUPERNET chain fork

Yesterday we had what was essentially a 99% hashrate "attack" on the SUPERNET chain. It wasnt malicious, just an inadvertent fork that was caused by loss of connectivity between the two GPU mining nodes that are mining actively and a significant part of the network.

From what I can tell, what happened was the chain forked and before it could be reorged into a single chain a notarization happened for one of the forks but the two GPU miners that have the vast majority of hashrate was on the runaway fork. Since the mining nodes were disconnected from the other nodes during a critical time, they never saw the notarization prior to all the other nodes blacklisting them.

Now all the nodes that were on the right chain were actively ignoring the runaway miners. All this is "normal" and usually would just reach eventual consensus, but this unusual situation exposed a bug in the notarization enforcement logic. As the runaway chain got hundreds of blocks away, a few nodes spontaneously jumped to the runway chain!

All this time, the notaries and marketmaker nodes are all in lockstep on the notarized chain as they were actively ignoring the runaways.

So, the usual resync the nodes on the fork process was being done on the various runaway nodes and for the most part that got them onto the notarized chain, ignoring the runaway chain. However a percentage of them where lured onto the runway chain. This wasnt supposed to happen, so I investigated deeper and found a logic error where it was assumed that a block once validated, would remain a valid block. it seems reasonable and it was part of the original logic. I missed the early return in the block validation if it was already on disk.

You might wonder, how could that matter as a valid block is a valid block. Well, not always as a node is syncing blocks ahead, they come in some random order, maybe the previous block is known, maybe it isnt, maybe not all the validations are done right away, maybe they are. But as the notarizations come in, all of a sudden we can have a situation where what used to be a valid block is now invalid as it violates the notarized chain rule.

From what I saw, nodes that were syncing up just the recent blocks or were online the whole time kept onto the notarized chain and that makes sense as there wouldnt be many blocks coming in way ahead of time. However, for a freshly syncing node, it could get thousands of blocks ahead (from the runaway chain) which would all get a valid state, then the notarization block comes in and invalidates it, a final block comes into connect to the runaway blocks that reorgs the notarized block away and we get a new node on the runaway chain.

It was something like that, so we needed a runway chain that is far far ahead of the notarized chain, a long sync where many runway blocks are saved to disk before it is knowable that they are invalid due to a notarization of a different fork and some additional random timing issues of when the last block comes in that completes a longer chain than the notarized chain. In this case, instead of following the notarized chain, the normal longest chain rule is followed.

The fix I put in was to check blocks even if they are on disk. That proved to not jump to the longer chain on a node that was always switching to the wrong chain.

As far as I can tell there were no losses created by this event other than the miners who mined a runaway chain. The notary nodes and all the marketmaker nodes all stayed on the notarized chain. All nodes using the original code eventually returned to the notarized chain as it became the longest.

The new improved version will make resyncing during a fork much more reliable. I also found and fixed a bug where a well behaved node could be marked as bad behaving, so that should also make things smoother in general.

To survive what is a 99% hashrate attack is really not something that should be required and without the patched versions, in a sense the assetchain did not do too well. However with the latest fix it seems that even under such extremes things will behave as it should. The reason why i say that this cant happen on the KMD chain is that there is no way to get any such hashrate dominance due to the blocks being generated by both notaries and GPU miners.

I am not ready to proclaim notarized assetchains are immune from 99% hashrate attacks (yet), but so far it is a very good validation of the notarization process

Agama Wallet and BarterDEX to support Chinese? Waited for several months.

tl;dr: If you're developing on the Komodo ecosystem, you program your transactions to be considered "complete" according to the level of security you desire. More time, more security. It's about 20 minutes until the Bitcoin hash rate backs you up.

Wall of text warning: If you're only mildly curious and in a rush, just read the first section. The rest is just written examples of how Komodo's Security Services work in practice, to help you visualize what the Komodo ecosystem is, and what it is capable of.

Disclaimer: None of this is investing advice. Do your own research.

I've had a lot of people ask me this question over the last month. In fact, I find that most of my time over the last month is simply relaying information from one person to another. Since I keep having to explain myself, and since it seems like useful information, I suppose it's time to put some of this stuff into documented form.

Komodo's Security Services Explained

During the ten minutes before notarization, an asset chain using delayed Proof of Work is only backed up by the security that the asset chain developer has. This will likely be a quite small level of security (though, if the developer knows what they are doing, it can be roughly comparable and/or better than the security of a DPoS blockchain). However, so long as the developer understands the nature of this vulnerability, this does not actually prevent a danger to their asset chain or to their subset of the Komodo ecosystem.

Assuming they are using a vanilla version of the Komodo asset-chain setup, the developer simply needs to program their smart contracts and other ecosystem transactions to never consider a transaction to be complete until the transaction's data has penetrated the desired level of Komodo's security.

Within ten minutes, any transaction made on an asset chain will be notarized into the Komodo main chain. This provides a baseline level of security, though it is not as strong a defense as what occurs within another ten minutes: their data is then notarized into the Bitcoin blockchain. (See the whitepaper for full details.)

Developers simply need to make sure that the speed of transactions in their ecosystem matches the value of the transaction to the necessary level of security.

Link to documentation

A generic example

For example, consider this line of defense against a double-spend attack.

Let us first suppose an honest user makes a transaction on an asset chain requesting an item of value. The mindful developer will write a smart contract that sends back a signal to the user indicating to them that their funds have been received and the blockchain product is on its way. The developer can even program software that allows the user to see that the item now belongs to them–but with one caveat: the blockchain product is locked in a smart contract for a few minutes while the asset chain waits to make sure that everything was done properly. Once the user's transaction hits the desired level of security (as determined by either the developer, the user, or both), the smart contract releases the blockchain product to the user, and they are free to use it as they wish.

Now let us suppose a malicious user intending to perform a double spend attack. They send their transaction requesting an item of value. The mindful developer sends back the item of value on the blockchain, using the protective smart contract. This smart contract is watching to make sure that the item of value is not fully released to the malicious user until the transaction reaches the desired level of security.

If, during that time period, the malicious user performs a double spend attack, what they are doing in effect is simply erasing the transaction where they sent their money. It is now as though they never sent it. The developer's smart contract sees that the transaction disappeared from the asset chain's record, and the smart contract realizes there's been an attack. It returns the item of value to its original owner. The malicious user may get to keep their original money, but they do not receive the item of value. The seller keeps it.

(In actual practice, the double spend attack may even wipe out the existence of the smart contract in the first place, thus returning all money to where it was before the transaction even began. It's as though nothing even happened.)

All of this is performed through automation, removing the need for a developer to manually manage these situations.

There are many other methods that developers can also take to facilitate smooth and hazard-free transactions on their system. For instance, they can also create their own network of trustless and verifiable notary nodes, similar to the notary nodes of the main Komodo chain. This can give them the option of lowering the required number of notarizations they desire on the Komodo main chain, and on the Bitcoin network, thus speeding up transaction time.

Two specific ideas on how that might come into play

The following is just my own imagination of how this might play out. The developers on the team could probably present an even better scenario that would solve even more problems.

Let us suppose someone designing a decentralized MMORPG (like World of Warcraft), using the Komodo network. (Decentraland, are you listening? We might be able to solve a lot of your current problems. )

Everyone in the MMORPG community has heard of people spending $10,000 worth of the game's currency for a particularly desirable sword.

A developer wanting to use Komodo's blockchain to securely decentralize their in-game currency, in-game stats, the data that supports their network, or whatever.

They design their software to behave like normal. (Yes, that's right. Assuming the regular talent, they can design their decentralized/blockchain-based game to perform with as high a speed as the gaming standard is currently.)

They simply design their software to sync and keep an eye on their asset chain's history.

The game can now perform with the same high-speed stats that gamers today are used to. They cruise around and do whatever, never having to wait for the ridiculous load times that decentralized data management etc. requires in some of these other decentralized gaming systems people are creating.

When a player comes to a moment when it is time to perform an event worth recording on the asset chain's history, they commit to this event by making a "transaction" on the game's asset chain.

This could be the purchase of a sword (or a house, or access to new territory, or an agreement to a battle, etc.).

Once the transactionID has hit the mempool of the miners of the asset chain, the game would then initiate the other side of the smart contract, sending the blockchain representation of that sword into a temporary holding address.

The software running locally on that user's machine, and which has been designed by the game developer, now shows the user a visual representation of that sword in their inventory.

However, it displays some kind of "warming up" animation, or some other story element, as created by the designer of the game. If you're a good designer, you could even come up with ways to make this process part of the experience.

The player could already be carrying it around, playing in non-scored practice rings and duels, etc.

The big trick is, the sword is not able to be used in any important event (as decided by the designer) until the ownership is backed up by the Bitcoin blockchain.

Once the notarization hits Bitcoin, from there on, the user can use it throughout the entire game. That sword is proven to belong to the wallet address of the user wielding it, and any attack they make with it is backed up by the Bitcoin hash rate.

The software running on every other user's machine will only recognize the stats of this player, including the ownership of this new powerful sword, if the proper notarizations are in place. Otherwise, the software just ignores it.

If some die-hard malicious gamer were to try to buy the sword and then do a double spend, the game would have to be designed such that it can't be used until the ownership of that sword is backed up by the required level of security.

The double spend attack on the asset chain would be nothing more than a waste of the malicious user's time.

The software itself can be written to simply be verifying information before any battles/events between any players who are participating. Unverified data cannot be used in any important event. The software running on each game player's machine would be syncing to the asset chain's history, ensuring that no events/outcomes that are not verified can adversely affect game play.

The data history of the game can also be hashed and included in the asset chain, in whatever manner the developer imagines.

This is obviously a lot of work for the developers.

But ask yourself, what World of Warcraft be like today if not just its "gold" currency was decentralized and secured by Bitcoin's hash rate, but even the game data itself?

(Blizzard, are you listening?)

Is there enough of a financial incentive there to get some talented developers to come do the work?

(Ready Player One? Oasis?)

The second example

Consider someone selling houses.

They just tell the purchaser of the house that it will be ready in twenty minutes.

Voila.

A final point, since wall of text status is already well achieved

Here's something else that I've had to explain at least ten times in the last four weeks. While I'm writing things out, let's just get it out there.

Most people do not yet realize the value of tiered-levels of notarization in the Komodo ecosystem.

Komodo's default notary nodes do not have to be the only ones in existence in the Komodo ecosystem. Furthermore, what happens if we get to a point where the value of KMD rises?

Every ten minutes of Komodo's security costs 0.005 KMD, regardless of KMD/USD market value. That's simply the cost that the notary nodes have to make, to get notarization to work.

(Notary nodes do not make money off of this. They make their money from having a handicap when mining the KMD chain. Notarization is just one of the tasks they do. The KMD you pay them is used solely for the notarization cycle.)

We're not sure what the lump sum payment to the notary nodes is yet, but somewhere in the neighborhood of 333 $KMD for a little over one year's worth of security.

What happens if KMD attains the value of NEO GAS? Last I checked it was around $75 USD.

Komodo's security services suddenly get quite expensive--too expensive for garage band startups.

Well, either someone who currently owns ~7770 KMD, or someone who does a dICO at this point, can start a new network of notary nodes. Off the top of my head, that amount would last for about twenty-five years.

(We sometimes refer to this point in our future economic plans, as it is the projected time period of Singularity--the point where AI intelligence surpasses human intelligence, and all economic assumptions can experience radical change.)

Back on topic: this second set of notary nodes is now a tier-two notarization.

This set of notary nodes notarizes all of the asset chains in their sub-ecosystem into their main chain.

Everyone in their sub-ecosystem is paying in TIER-TWO security coin to notarize into the tier-two asset chain.

The tier two chain notarizes itself into the KMD chain.

KMD is then notarized into the KMD chain, which is then notarized into Bitcoin.

Everyone is now backed up by the Bitcoin hash rate. Voila.

The only difference is an extra ten minutes for people on Tier 2 (and, presumably, a reduced price, for that ten minutes).

Then imagine tier three, tier four, and as far as this thing will go.

Furthermore, consider that for yourself (speaking to the entrepreneurs in the community), you only have to notarize into KMD once.

You could easily set yourself up so that you have one main chain notarizing into KMD, and then a bunch of your own other PoW blockchains that notarize into your main chain. You set up your own miners, and even notary nodes if you wish, to manage your network. Each blockchain has different purposes and use cases, but you only pay one fee to get them all backed up.

And yet furthermore, let's say that one day you find that your business has grown so wealthy, you think you can afford to notarize to the Bitcoin blockchain itself, and skip the whole KMD notarization.

We've probably mentioned a few times by now that Komodo is focused around Freedom.

Because your main chain is independent, you just detach from the Komodo main chain and link up directly with the Bitcoin chain.

Assuming you have the requisite talent on your development team to plan it out, the only thing users in your ecosystem would notice is that all of a sudden, security would show up ten minutes faster.

So, if you, dear reader, belong to a large organization (like Blizzard/World of Warcraft) and you're not sure about all of this blockchain stuff and how you want to approach it, you can start with us as a launching platform. Then, when you have generated the XXXX required amount of BTC to head off, on you go. You have complete freedom to make that call.

Finally, consider this: the Bitcoin hash rate (which is what prevents Bitcoin's history from being altered while maintaining an accurate and un-manipulated decentralized history) currently consumes more electricity than the country of Denmark.

And that hash rate continues to grow.

It continues to grow at a rate that is faster than even the Bitcoin Cash hash rate is growing (the only one that is even in the ball park).

(The Ethereum hash rate doesn't even register on the scale.)

It is said that within the decade, the Bitcoin network will likely consume more electricity than the entire world combined.

All things being equal, and assuming the Network Effect that even today continues to increase the hash rate/security/price cycle of the Bitcoin network, the USD equivalent value of the transaction fees for Bitcoin will continue to increase.

Last I checked, the cost for us to do one year's worth of notarization is about $2.5M USD worth of Bitcoin.

The Komodo main chain continues to rely on our reserves of Bitcoin to notarize to Bitcoin (we have enough BTC for over twenty years, regardless of BTC's USD market price. And that's before any business models we may implement to replenish it our reserves).

In that sense, in the crypto world, Bitcoin becomes the heart of hash-rate security, and Komodo is the pulmonary artery that connects the heart to many other veins.

I'm frequently asked by people who our main competitors are, within crypto.

In truth, the only ones of which I am aware are the historical whales of Bitcoin, and thus have the same amount of access to the Bitcoin hash rate that we do.

All other projects that are trying to do something similar to what we're doing (Ethereum, NEO, Ark, Waves, and other Proof of Stake-based coins, etc.), do not have anything of which I am aware that can provide this level of security while allowing independent blockchain developers to do whatever they want with their own independent chains.

What else am I explaining constantly?

I think this is enough wall-of-text for now, but readers who are interested should know that the Komodo Smart Contract API has intriguing angles, and unrealized potential. Stay tuned for more, I suppose! We'll get the explanation out there soon enough.

You may also be asking, "But what about high-speed transaction situations"?

The implementation that we have for this situation is currently already in place with our Speed Mode feature on BarterDEX. The developer of an asset chain can also implement their own notary nodes, which provide a level of security on their asset chain that is equal to (and arguably better than) the DPoS security that other blockchain platforms are using. I'll have to explain more another time. Also, the CHIPS asset chain we're building helps to handle high-speed transaction situations. It ties in with BET and PANGEA. They are all well into development, but won't be marketed for a long, long time. But just fyi, for those of you who managed to make it all the way to the end.

And that's about all. Peace out.

send the VOTE2018 coins to the candidate(s) of your choice
the blockexplorer tally becomes the voting results
a special version of agama will be released that supports VOTE2018

How to make a vote? Step by step for noob please

Yes, you are right.

https://twitter.com/KomodoPlatform/status/970725789359583235

https://pbs.twimg.com/media/DXi11O4X0AAmatF.jpg

As I understand it and please correct me if I am wrong, Vote asset chain would be airdropped and be used as a voting tokens for Komodo notary election . Is this accurate?

Notary Node 2018 Proposal

About Me

I am with Komodo community since the BTCD days. Mined BTCD, participated in SuperNET ICO. A very advanced user, problem solver with attention to detail. Without being a coder, I made and hosted explorebtcd.info block explorer by myself.

I love all things technology and kind of crazy that way. At least, that's how people describes me. Currently, I'm a team meamber, testing BarterDEX and other Komodo Platfrom related products everyday and help other users. I also docomented BarterDEX APIs and created some nice wiki docs, install guides for users and devs alike.

Notary Nodes provides security for Komodo and the whole ecosystem is benefited from this. I would like to present myself as a candidate for Notary Node Election 2018 to operate one node in the EU region.

Why Vote Me?

• Did I say I love technology?
• I'm online over 75 hour every week
• One of the first to test most of the latest Komodo Platform technology
• High level of understanding about the platform and its tech
• A very advanced user in terms of computer, server, mobile, gadgets
• I have my test node running for over a month
• A Notary Node will be helpful for my BarterDEX and other Komodo tech testing and providing Liquity in BarterDEX
• I will provide a high spec node which is scalable and will add more server if needed

Minimum Server Spec

• Processor: 2 x Intel Xeon Gold 5120 Salable 14 core = 28 cores / 56 threads total
• RAM: 4 x 32GB = 128GB Crucial 2400 MHz ECC DDR4
• Storage: 2 x 2TB Intel Solid-State Drive DC P4600 - PCIe 3.1 x4, Read speed 3290 MB/s, Write speed 1650 MB/s
• Power Supply: Redundant Power Supply
• Colo/Data Center: Tier 3

Vote Details:

Region: EU

Vote Address (t): Vote Address (z):
Please vote for me. 

Monaize team is preparing for a normal ICO. Nothing else has changed.

You can get more info directly from them as well as from their recent blog post:

https://medium.com/@monaizeuk/making-the-best-use-of-blockchain-to-disrupt-banking-a-marathon-not-a-sprint-faa610c387f8

BOOM! 

http://votefor.chainstrike.io/

https://chainstrike.github.io/

Why search for the biggest instead of the best?

Im searching for the biggest mining-pool. Any suggestion ?

mobile version is good but imo for a widespread use a web app is vital. We can see bitshares exemple and other desktop exchanges. I love barterdex and it's bringing a lot of innovations but i cant see a diffusion without a webapp. The security issues are related to the decentralized nature of the exchange? A browser plugin to handle the keys like metamask could help?

edit: i saw in the roadmap that actually a web version is planned in Q4, i'm right?

Nice offer, but it wouldn't be a community pool if one entity controlled the majority of the pool, would it. Small investors are being offered nice profit shares by some high profile candidates with good chance to get elected (20%-30%), so there's no need for a community pool now.