[ANN][KMD][dPoW] Komodo - An Open, Composable Smart Chain Platform, Secured by B

[lucky626]

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

[1715184669]

1715184669

[1715184669]

1715184669

[1715184669]

1715184669

[1715184669]

1715184669

[jl777B]

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

[KomodoPlatform]

Notary Node Elections are fast approaching. Read this post to find out.

[KomodoPlatform]

BarterDEX: Sending and Trading Dash

[grewalsatinder]

Please don't forget to vote for me when you see the keywords like "MESHBITS" in node choice options! 🙂
This year I'll be using my company handle "MESHBITS" for Notary Nodes Election 2018.

[Big Naturals]

Notary Node Elections are fast approaching. Read this post to find out.

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?

[jl777B]

Notary Node Elections are fast approaching. Read this post to find out.

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?

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

[KomodoPlatform]

Celebrating Women In Blockchain: Meet 2 Brilliant Women On The Komodo Team

[Big Naturals]

Notary Node Elections are fast approaching. Read this post to find out.

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?

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

That makes sense, good decision! If an imbalance in the regions does occur you could always give a slight advantage to candidates running in that region next election to compensate, get more high quality candidates running in that region.

[jl777B]

Notary Node Elections are fast approaching. Read this post to find out.

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?

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

That makes sense, good decision! If an imbalance in the regions does occur you could always give a slight advantage to candidates running in that region next election to compensate, get more high quality candidates running in that region.

Yes, and if anything this way the geographic distribution will likely more correlate to the userbase locations.

Of course if we end up without any nodes in a region where there should be, we will fix that in the following election.

By only electing for the bottom half, we preserve the top half each year and it provides the stability to the notarizations, while still allowing anybody with skills to get a notary node spot. There is no need to have a large stake, or lots of mining hardware or even lots of money. We need notary operators that can manage the servers, using unix command line, making docker images, bash scripts, or are even full stack devs and all the technical work that goes into running a network.

I want to discourage votes for candidates without a solid technical background as they wont be able to help at all if there are technical issues and that is the role of a notary operator.

So assuming that a candidate has sufficient technical skills, ie. would you ask them to help you out with a shell script that isnt quite working right, the the secondary factors would serve as a tie break for your VOTE2018

Keep in mind some candidates already have one (or more) in the top half and already are notary operators. Many are also KMD team members. These can be viewed as either an advantage or a disadvantage, there is no agreement internally on which it is. So we are taking the position of disclosing all such pre-existing relationships and letting the voters decide what is and isnt important

geopreference: it turns out that there is a simple way to balance the geo-regions. basically just go down the richlist until you find a candidate in that region. So by picking an unpopular region, it might give an advantage

[MoneyJ]

So a 1:1 ratio for airdrop of token vote2018 . I will be choosing only one candidate in my region and with my stake at hand it would be advantage for him/her. Good luck to all candidates and may the chosen be deserving and really would work hard on Komodo community and its welfare.

[ptytrader]

Please read my Notary Proposal and Vote Addresses:
https://www.dropbox.com/s/7yfh4wlcpi56hj5/PTYX%20Notary%20Proposal.pdf?dl=0

[Decker]

Decker's 2018 Notary Proposal: https://deckersu.github.io/decker_nn_candidate_en.pdf

Who am i?

I am an IT expert and systems engineer. I’ve formed part of the Komodo team since 2017. During which time I contributed to Komodo in the form of development towards the KomodoQT (KomodoOcean) wallet - the world's first GUI wallet for a zero knowledge fork that supports KMD and all its parallel chains. Additionally I assist the team in testing and development of new dapps.

Why Vote for Decker?

In addition to the wallet development I took part in the creation of the first CHIPS wallet, building BarterDEX core for Windows. Active member of the community with plans to support the platform in the long term. Notary node funds will increase my resources to improve Komodo dapps.

Proven Skills

• I can handle a wide spectrum of the Komodo infrastructure.
• Deployment and support fail-safe work of KMD and parallel chain explorers, hosted on my own VDS servers.
• Software testing, software programming.
• Making blockchain snapshots, writing and translate documentations for users.

I’ve decided to become a candidate for the European / Asia and Russia regions and I count on your support!

How to Vote?

VOTE address:

Code:

RARcozaVAMZaXJaL6KWMSw297xTYzbDwa3

zVOTE address:

Code:

zc9re8upRd4zZQ7Zs1qm1BnsXtEQ8yhQm3UeWkAugto5FwfgH6NoKTGqKM47K2QNus3CV5h3Kd3wUfzzjctZvj5S3EDFZqH

p.s. Unboxing event (80 Mb of images). Photo gallery: unpacking and assemble server.

[Decker]

Don't forget, that we have Agama Mobile, that supports not only KMD and assets, but many other coins:



It's very easy and convenient to use.

[Pumuckel21]

I was not following kmd for long time so is there any news which coins are goint to be listed next at the agama wallet ? And is this wallet also avaible for ios ?

[btcltcdigger]

Don't forget, that we have Agama Mobile, that supports not only KMD and assets, but many other coins:



It's very easy and convenient to use.

This is big indeed

[Decker]

I was not following kmd for long time so is there any news which coins are goint to be listed next at the agama wallet ? And is this wallet also avaible for ios ?

Current desktop version of Agama 0.2.0.29c-beta supports only KMD and assetchains. For future plans and coins to be listed, i think - you should ask @pbca26. If you are about mobile version, as i know - there is no IOS version, and developement current Android version are postponed, because community showed no interest in this application. That is sadly.

[Vermalen]

Time To Update To The Latest Version Of Agama 0.2.0.29c
https://www.komodoplatform.com/en/wallets#_desktop-wallets …

[KomodoPlatform]

Time To Update To The Latest Version Of Agama 0.2.0.29c

[FrozenChaos]

Time To Update To The Latest Version Of Agama 0.2.0.29c

Does this mean the claim interest issue that was brought up a few days ago (telling everyone not to use the Agama wallet) is now resolved with this update?