You mean other than the 5% APR you get just for having KMD?

And other than having the ability to create a protected transaction to safekeep your crypto?

When DEX goes fully active, you will be able to JUMBLR BTC through KMD. You will be able to do a native atomic DEX with all the supported coins.

We are also planning on some sharedrops, but I didnt officially say this yet, so dont hold me to it.

The ability to notarize assetchain of your own.

Later this year, ability to use KMD in the pangea fully decentralized poker.

Probably more things I forget for now. Basically we will make KMD have the most usecases, all while having dPoW securing things via the bitcoin hashrate and maximum privacy using zcash zero knowledge tech.

you mean something like basilisk?
when using basilisk you dont have to sync locally

socket hang up is an error I havent seen. could be some network issue.
It seems the resync is indeed 2x as fast. If it will rescan/resync again, I suggest that you sync without mining, exit, make a complete backup.

This way you can always resume from a very recent block no matter what happens.

Now, try mining with just one thread and see if it is stable. It could be multithreaded mining has a recent issue? I will investigat this socket hang up to see what it could be

The latest beta branch is looking pretty good. Much faster syncing, much improved and cleaned up code for the recent issues.

Now, KMD ecosystem is not the ordinary bitcoin clone where there is just the bitcoind equivalent and QT wallet. So it necessarily takes longer to update. Once there is a stable komodod:

1. All notaries must update and with the 24 timezones most having a notary node in them, this is not an instant process.

2. After the komodod is updated to all the notaries and GPU pools, the notaries need to make sure the basilisk data is up to date. Otherwise the basilisk mode will be missing some data. You wont lose any coins, but you might not be able to see them via basilisk.

3. The updated komodod needs to be built for osx and windows

4. The updated komodod needs to go into an Agama release

5. installers need to be updated with the updated Agama with the updated komodod.

6. At this point, is about where exchanges would reenable deposits and withdraws.

Additionally, for this weekend there is a scheduled activation of a few minor consensus rule changes. I dont expect any issues but better to be safe and cross the 250000 height with a relatively smaller set of nodes.

So please be patient. Most coins have never been attacked even once. Let alone four times. Let alone in just over a week. And yet, komodo is updated, and stronger due to these attacks. We were blindsided by the first one, but since then we have developed attack response procedures and will also utilize zero-day mitigation processes in the future.

It really sucks that having found a vulnerability, fixed it, partially deployed it, yet it was still attacked since KMD is open source and given a fix, working backwards to an attack is not so hard.

Will there be more attacks? I am assuming that there will be and continue to improve the security whereever vulnerabilities are found. This has necessarily delayed some of the core features I was hoping to have this month, but nothing is more important than the security of funds. In any case, komodo and iguana are still a bit ahead of agama (notice there was no confusion as to what I mean!), so maybe overall we did not lose much time.

What doesnt kill you makes you stronger and komodo is certainly alive!

When did you last update?
I recently fixed a miner crash issue, also a full resync is now 2x faster, maybe more

you must use the beta branch!

Sorry for the 12 hour delay in payouts.
Three pairs of allnighters in a week and sleep deprivation to combat the hacker attacks is my only excuse.

Batch 14 is processed. Based on the dwindling number of payouts, after the next payout in 2 weeks, we will go to a monthly cycle. I think there are only about 100 payouts left to be done.
5eb5cc5ed22a50835b1ecc8431cb36837f7ee6631193fb8870e27fe3d004e388
283716.36806687 <- expected amount RN1t6SGGsWGrgcfE8fJPJWwHmKH4zE93Vj
32f228baaaef243b4f554eb0344c0e828452b50cd6140fb0b62b7d4e066ecf54
232.80643392 <- expected amount RDdUQ5t6SYYGZUdAxBk5i7QdTWvzAshxNZ
df2a836b44a6a9ccd717d1de028cf0f4a4d48a01ef4bce4a45e56118a4cd6c14
2247.65412987 <- expected amount RKuwq4oi4mqQ2V4r54mPEthn3TBrEwu2Ni
9ad1f57d4919d59cbfad07e79d38ffb4e6f9c09a4afc1184582e5e17a4efd8c7
202518.10752377 <- expected amount RPqAFgwnB1hjae6Ar4Kms973uS93HbDkoB
288b195b8c097d23a1377aa0cebb902dbee91f434e86cfb1d9d84cc2484d5ebb
9837.11461840 <- expected amount RBQyRBW6RFhcAmoK6UhoqrTgjH3Gz1xdCc
51fb820d9c4f1e399b9db372c1d7d73d5587399e61a78dcf76a8e19d0f697314
6.87037888 <- expected amount RDeUhHeM6kaaMg9bNJQDjXrqimqZSeVTqb
00be5062b7be5ba3177dde338a950ee4d5a221af1fd773c2e4d8e95b6e1567d7
601.90475901 <- expected amount RY43geE3zoc88VbhnExje4J1wCNvX8fvfi
5884830ab6e2541e2a2289edaab5879798a6fbac00ba6af5ca28350e4496955b
40171.99122689 <- expected amount RJ5qNTw5sm9AiHX2129dqBQSFETkP9sYFF
cd055945a31889caaad14fc9316e893aad0bd03c3929b937fb62521fd75dd64a
1465.10673247 <- expected amount RKbr67Hs4exDXg92LQhVYY4MSuqwbJJN7z
267e297faa4bc6e9d15e21af7212987737d483c0d924191b5e01a559d6718d6f
20449.88848416 <- expected amount RBjZCbMHCtsqpcQfaQquiNi4s8GTr6uLRZ
817f0ce6f059672bc41a5753a8c720720054babfc0262302f0daaf3afc619477
497.55272329 <- expected amount RJRJ2xejRZuiMPQnafPEUU2VUfTfchpHZH
6991e37b2fa14d838c8812887f3c2d1974fd19de77bddce382ba4becff6e3a96
26.76069242 <- expected amount RE1NYFqFG2vmhhHVY7QFC7sTp7zBxvSSP3
2eb61e5f0505b34e82fd83ad757a766e50ccaabc1483d45b0505160b6792a983
2105.68422851 <- expected amount RKoxsZuFuAHFYCRxpScXjBoTNa2zBALASc
152e989bf70ea1846dc83392f490ba2af68c7b08e8a7b6c4df995a49886bd7e8
37.03715216 <- expected amount RC3h8Y3o5Ak7gdiCJ9GPY7EkB3DKd5hqtG
e5981bfe123044879385ceb49d1b48e280ad1af0620e296dd4ceea9747533ab0
9295.82639400 <- expected amount RPpsBduDnnpgEZnEYKRKv5j1Ubx32c37jW
8ba9ea554d28c6f81652ed03182fe73bfa05f40a628f99cc5dc193b1deb82bf9
56299.80756714 <- expected amount RKWNm893ZmBoTDHZ287LhHfigdMbg1i5pe
f23fc38d2d9ba66292c26bdc55de8a3993c30c8e4356605a7d9f76820be8c530
46479.13197000 <- expected amount RVCsfNnKexhZfyWzYnVnyYqQ181xNaK83r
ea31bd59672b44be2a9243c5c670014cfbabc08cec7622dd9764e27c9c22fc2c
21522.57690952 <- expected amount RGry1cqvb2DpJ8KVJ8UUx2fe3TxLmmPohY
7eb9286b6cc68e1a4b3335c799761ad2cc9986828de824365b1e1a63e24aa7a5
5510.79545709 <- expected amount RJaBNff51EwkwTq6BpmLikW3Wx3XFJ4CZR
200dd3faff950006699d0443131978591a910c2f7de836315956882355ed2fe6
38732.60997500 <- expected amount RSGZVs6APV5K96tEtuRoMwtc3P7h1SfzQY
eac72ad5cb5189df0481679c12634f30ec1c20d028d9ee7842f17d19a816077d
1524.15725197 <- expected amount RGQm8kgDPFCnhB6y6smATMBG8Bq7NPkeKk
d50f98099a13b7ed0bc776288fcf51cb6087ec7c99d0072c6f7d404ab2f2c329
21460.18988274 <- expected amount RH6ZPNWW8XS9cm5xsEyngQuARXNtUzGFKw
e02ddd7f70635cb8a21a92273ef9ab5039495f8a79867d6816873cfd2d26059f
4938.88955074 <- expected amount RAGGPNoZgxAj6ABBTwehQfVYEa1PEN4qZW
93b0e3c5ab3bdcde87367ed5c54d9d0b1bdcd37d41c6fca1ec93cff9ef92292a
37183.30557600 <- expected amount RXoWchjAaJatpRYGoD7A2tEuYN1jhdrRv3
b760e518c41414efd89fa29ab4f99d213dd0989556045f83889ddbcf141a815a
693.08132289 <- expected amount RHJ55iWUQNbKcSn8shbv1RbGuip3RSRHFv
bf9fad3ef08ec0529e31e5a0fc2790d9790dd3dd6fbb00d787b600bc412323a6
29783.79369585 <- expected amount R9Kpd7dQ5udE7bUBWvQ5sEiTL3hSr5R2Ck
0d2746ed33a97d960a3a6aff6ec6d95faa3d334af4fcb39146375aa5e08b7a54
9683.15249375 <- expected amount RHh3vqCrFmZsLUKPxnx4yCcAqZ8RSZ2NW3
ffa2dd1fd7c1fc08bc5d22526318a06b9a2b398f265832b6f4f1e2d2b080d6b9
4040.77614254 <- expected amount RM3onNDjZbjypoN8wqo7Rzz3QEv6EiCfwK
43f75197b70a33ddb924ae1fff234274f7026437aabdc45d95c95354f2e3fa38
47536.89479581 <- expected amount RU3EDov1PTPAY8WhG5eGUANp2rvtki1yc9

that too.

Unless you are the hacker, the interests would be the same. Only a small number of nodes went past the designated paused blocks and the interest calculation is due to elapsed time and not blocks.

Likely the basilisk data isnt fully up to date yet as notaries are in the process of updating to the latest version. Assuming it passes tests, it will be propagated more widely.

Also, the Agama release does not have the latest komodod in it yet, so until all the parts are updated to the matching version, results could be different than what they should be.

The iguana core is what does the actual atomic swaps. Adding a bitcoin compatible coin will be a matter to run an LP node that makes a market for it. I will do my best to make them easy to setup. Once there are LP nodes for a coin, the Agama GUI will use the iguana core to enable native atomic DEX

Currently I am dealing with bulletproofing the network, so a bit of a delay for this, but I was working on finalizing the JUMBLR BTC <-> KMD dex tradebots, so just need a bit more time and it will be ready

kpx.io is on the mainchain and it is advancing, slower than normal until we get the GPU pools back online.

Only the beta branch is up to date for now as we are still verifying that this specific attack is fully solved. The usual "after the storm" advice of dont do large transactions, dont worry if basilisk is slow/not working, wait for updated GUI, etc.

Description of attack:

There are three (actually four) different contexts in the bitcoin code of validating a transaction. KMD verifies that the nLockTime in the tx is not too far in the past. A one hour leeway was selected as this amount of accrued interest is lost to avoid the third attack we had the other day.

When the miner creates the block, when the block is relayed and extends the chain tip, and when the node verifies the local blockchain. All of these are clearly required and need to be 100% deterministic in the value used. There is even a fourth validation, of wallet transactions.

Due to the quick work required to stop the third attack, I missed that there was not 100% agreement among all the cases. If it is even off by a second, it would be possible to fork the network. The difference was on verification of the blockchain a node does on resuming/starting sync. (Oh yes during initial sync is a fifth different context!)

The attacker started spending some of his illicit 1400 KMD he got from the third attack. Every block he was backdating it the maximum amount. At first we thought he was just trying to get some fractional extra KMD. But what he was doing was getting a tx confirmed that would be rejected by the resume scan!

As soon as he achieved this, he started a DOS attack sending malformed messages (details of which I havent had time to analyze) that crashed nodes, forcing them to restart and reject the main chain. Each node would then be on their own and if it was a mining node it would start its own fork.

The first thing I did was stop the crashing with a patch so we could assess what was going on. Then we figured out the bug with the timestamp. Then made a few (a lot!) of iterations on possible solutions, finding out more and more different contexts. Finally when the five contexts were understood, I was able to construct a solution that was consensus safe.

At least that is my current understanding, which we are verifying.

Unlike the other attacks, this attack did not seem to be financially motivation as there was no coin creation issue. As I said before more attacks are likely to happen. We will continue to combat it as best as we can to minimize service interruption. With each attack we are getting better at damage control and resumption of the chain.

The first priority is to protect your KMD. Currently we are a bit diff stranded, so until the GPU pools get online (using the beta branch) the blocks will be really slow.

We will pause the mainchain at 247204, when things are sorted it will resume from there.

I am still not happy with the hotfix, but need to get some coffee.
So there will be more updates to bulletproof this area

As I wrote before there is now a one hour timeframe for a tx, so there is a compare against (timestamp - 3600) to check for tx nLockTime validity.

This one hour of leeway does allow collecting one hour's interest, but at 250000 we will subtract 59 minutes from the effective time. So this free interest will close soon.

We saw that the attacker was taking advantage of this, which made little sense as it is only getting small fractional KMD. Until we realized it also had the effect of creating edge cases, which would make a node create a block that it would then reject on restart.

The error is totally my fault, I used the chaintip's timestamp instead of the block's timestamp, not even sure why.

Now to make things more interesting as things would be so boring with just an issue like the above, there appears to be a DOS attack with killer network messages that crashes nodes randomly. Not sure if it is an intentional thing, or maybe it is just due to the current chain's state.

Anyway, I put a patch in for the crash, so it stops crashing now, but the cause of it is not time enough yet to solve.

I also pushed a version that uses the consensus safe value for the timestamp check. Notaries are in the process of verifying this.

From what I can tell the vast majority of the network is on the same chain, so we might not even have a fork, but with nodes randomly crashing it is hard to say. When the crash resistant version is propagated we can better assess things.

The black hat made something like 1400 KMD from his attacks. He could make far more if he just reported these issues...

Anyway, it is very good that we are getting help from very capable people to help solve these issues in a timely fashion. Thanks to all!

It seems I wont ever get to sleep for more than 3 hours at a time...

KMD network is processing some killer messages and nodes are being killed. This sounds somewhat familiar. We are investigating.

Also, the recent attacker has constructed a problematic transaction, which might have caused a fork at 247204. First step is to stop the killer message, but best to assume chain is stopped at 247204

Mainchain has now advanced hundreds of blocks and the fork event is behind us.

Wasnt that fun!

For basilisk users, in the next hours it should start performing better and better, but please be patient if it is slow or you cant see your balance. check on kpx.io and if your funds are there, your coins are safe. basilisk mode is a convenience way to access your coins.

For those that require constant, continual and always accessible relations with your KMD, then I strongly suggest that you run native mode. That is simply the only way to achieve this. To expect a little basilisk to do what a komodo does... Just not realistic.

For the people who are running a native komodod, you will need to update to the post-hardfork version. GUIs are being built right now, please dont ask me when they will be released, I plan to get some rest soon. If you ended up sending transactions during the last day and the txid does not appear on kpx.io, but your wallet says it is spent, then it could be that you need to rescan your wallet to get things back in sync.

Of course the first thing to do is get back in sync, then do the wallet rescan if some tx are missing.

KMD has a new feature by the way. Part of the fix required was to make mempool transactions expire after an hour. Since KMD has 1 minute blocktimes and the blocks are far from full, I dont expect this to be an issue any time soon. If in some years it becomes an issue and for whatever reason the blocksize isnt just increased in size, please refer them to this post where I say, "just increase the blocksize to handle the transaction load!!"

With a one hour expiration time, that means if it isnt confirmed after an hour, it is invalid and you dont have to worry that it comes back and unexpectedly spends the  inputs. So even if KMD mempool does ever grow to a backlog, the longest you have to wait wondering whether it will be confirmed or no, is one hour.

you are on the right chain, it is rejecting the invalid blocks.
i think you just need some recent peers.

kpx.io is almost current
http://www.zpool.ca/explorer/1720 is current to mainchain

try removing peers.dat and launching again, that should work. if not, try:

./komodod -addnode=78.47.196.146 &

After a long "day" we finally got things sorted. KMD chain is making blocks, github has mining enabled versions for the mining peoples.

While I get some rest, the basilisk data will be regenerated, new GUI made with updated komodod, etc.

So things are not totally back to normal, but the difficult should be behind us and now it is just the normal things.

Too tired now to explain the issues, suffice it to say bitcoin code is complicated.

I would not recommend exchanges resume quite yet, kpx.io is current in the summary but still rebuilding its data and we need to have the basilisk data regenerated.

blockchain is paused
been up for a bit too long so need to get some rest while the data is gathered on the ongoing tests.

please be patient, we are going as fast as is prudent and the one million diff doesnt help matters either

it is off by one, almost have the issue solved, but not yet. quite tricky

246748 is last mainchain block. you will just need to invalidateblock on the 749 and you will be in sync, so once the mining version is done it will be quick to get going

need to come to slack for realtime data.
kpx.io is paused
we are getting the mainchain going again, but running into an issue with the high difficulty