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

I wont talk with trolls. The more you feed it... you know... Pm me if you need this dev. That ignore button works wonders

I'm reading the cryptonote white paper.  How does Komodo differ in security than say Monero?  Please help my understanding.

You know what else would be unfair, If the bounty funds were wasted on translations that are not needed just because you feel entitled to it.

LOL, You made my day man. So you actually demanding to get you a translation bounty? HAHAHA. Please no bounties for anything. If you want some KMD, go ahead and buy on the first ICO day.

This is unfair for the rest of the translators and the community in general and some people that dont understand english very well. I would urge you to reconsider because you may be loosing possible investors...

I forgot to mention that I think I have the bitcoin backstop protection hooked in!

Just a stub and wont actually do anything until I get the messaging activated, but given a dataset of notarized blockhashes, any block that tries to replace any notarized block (or earlier), will simply get rejected as being an invalid block.

To my thinking, if it is rejected, then it wont ever be able to trigger a reorg of any depth and when the first non-notarized block along that reorging chain appears, then it would reorg to that point.

For dPoW the bulk of the work is in the voting process to elect the notary nodes and getting this election result properly ratified and onto the blockchain. Without a deterministic list of notaries at every blockheight, well, let's just say that we need to have a list of notary addresses that can be precisely calculated as of any blockheight. Not just in realtime (that's the easy part), but at any time.

Given such a list, then the data needed to verify that the notary seal is valid will be available.

I am fixing iguana bugs as the top priority to make sure we can get a stable release out sooner rather than later and only working on the dPoW coding after I am caught up. Sometimes the two overlap, ie iguana support for TAZ and KMD, as now I can integrate iguana into the notary nodes at the localhost layer. This means they dont need to be compiled or linked together and allows for a lot more flexibility. It also minimizes the chance of any bugs in the iguana codebase from directly affecting komodo. We have been testing iguana for a while, but it is a rather large codebase and it is better to design things to handle the iguana side dropping out.

With komodo relying on the equihash PoW to make blocks the old fashioned way, as long as the presence of notarized blocks can be made seamless, then we get the best of both worlds. Enhanced security when the notary nodes are up to date and current, normal security when they are not.

On the other side of iguana, I added support for syncing to TAZ (zcash testnet) and KMD (komodo testnet)

Due to the protected funds, basilisk mode wont be able to work with them. Also, iguana just cant handle all the zkp code, so while theoretically it would be possible for basilisk support on the transparent output side, it is not a priority for now. That will have to wait for new staff that can work on extending basilisk to the non-bitcoin protocols.

I dont yet interpret the protected transaction data, so the account balances will likely not match for now.

 

you would need to git pull the GUI repo to get an updated html

maybe in the future we will fully automate the process, but for now safer to manually add and test new coins as they are validated.

Of course, if you just go into the GUI html, it is easy enough to add a new coin if you have all the magic parameters for the addcoin API

Will the option to add coins for basilisk just appear? Ie: once enough full nodes of a new coin are running, will the basilisk user wake up one day and see a new button or option to add  this new coin that the user was unaware of before?


Thanks. Sounds exciting.

On the iguana side, I have basilisk mode into testing now. Basilisk nodes rely on iguana full nodes to provide public information data about the blockchain. Currently the following remote calls are supported:

getinfo - returns standard getinfo
balances - returns the balance and listunspent data and spend data for array of addresses
value - returns the value, spend script and unspent status of a specific txid/vout

It might not seem like enough, but from the above, a basilisk node is able to construct a functioning listunspent and from that it constructs the higher level RPC calls, such as sendtoaddress. All the signing is done locally and each vin is verified with multiple peers to have the correct value. Since a spoofed vin will either just not get a valid signatures, the only damage a hostile node can do is provide an unspent with an incorrect value and making a baslisk node overspend. That is why each vin's value is verified as a final step before signing.

I have 10 servers running BTCD (most of the time) as a long term test to make sure they all stay in sync. I also am running a pair of servers with BTC, LTC, DOGE, SYS and GMC. So those coin's should work in basilisk mode.

Current GUI mostly supports basilisk mode as the API is the same for either mode as is the RPC layer, however some things like sync status tend to jump around with the getinfo data coming from different remote iguana nodes.

As soon as a new coin has a few iguana full nodes running and connected to the supernet, then all basilisk nodes will be able to add that coin and have a local wallet without needing the blockchain locally.

I started work on the komodo testnet yesterday evening.

Testnet is live.

https://github.com/jl777/komodo

the end of readme has the instructions to get a komodo TESTNET node running.

The coin supply is changed, and the ICO allocation is done with the first mined block. This minimizes the code changes needed to support ICO purchases stakes as they will be distributed via normal payment transactions.

Currently it just has the hooks in for dPoW, however the mining reward is set to 3 KMD per block and due to lack of nodes, the blocks take a bit longer than 1 minute, but with more nodes it should end up averaging 1 minute.

It is running in the no-notary nodes fallback, which uses the same PoW as zcash. This ensures that no matter what happens to the notary nodes, the blockchain will keep advancing. When the notary nodes are present, the blocks will be more regular and it will provided the bitcoin enhanced security.

This testnet is subject to being reset at anytime (already did that 4 times), so if you are running a node, please check here to see if a new testnet is live. Also of note is that even though it is a testnet, just use the mainnet settings for the builds. There will be a new genesis, port changes, etc. prior to the real mainnet.

Since komodo will run with a dual method for block creation, when the notary node method is ready, it will be compatible with the prior blocks that just used the PoW method. I probably will have to make some breaking hardfork changes along the way, but it is possible that soon after the official zcash is ready I can make the actual komodo chain live.

For now, I want to get the process of going from the zcash pure fork to komodo solved, so there are no surprises when the time for the real mainnet is here.

I want to make as few changes to the zcash baseline as possible and so far the changes have been just to constants, strings, "komodo" message, and an if statement calling a komodo_blockcheck just before the equihash block validator is called. Of course there will also need to be a change to the reorg consensus code to check for notarized blockhash, but with the message handler and the block check handler in a komodo.h include file, I can code in C all that logic without getting slowed down by C++.

You can already start testing the zero knowledge protected transactions by following the instructions from "Getting Testcoins" section in the middle of https://github.com/zcash/zcash/wiki/Beta-Guide

The komodo addresses use the same prefix as BTCD, so it will start with 'R', but the protected coins use the same prefix as the zcash so it will start with 'tn'

If you need some test coins, just post your address here

trustworthiness? The most funny thing i heard about him. Many say he is a scammer actually.

I don't disagree with any of them statements, I think they are both trustworthy people and I think they have enough trust behind them and on this forum. Best of luck with the project. Looks like it could be a serious competitor to monero or dash.

I just wanted to clarify the escrow part. Thanks for your explanation.

You are right, the tittle is not very accurate.

It's more like a fund safekeeping rather than a traditional escrow for an ICO.

jl777 has demonstrated his trustworthiness over the years as the head the SuperNET projects.
Noashh is a long term member who have worked hard for SuperNET as a treasurer among other things.
TwinWinnerD is a very known and trusted person, also the CEO of bitpanda.com

Just send your BTC directly to jl777, or 1bitcoineater.  Same difference.

It doesn't fill me with confidence that 2 of the 3 keyholders in a 2 out of 3 multisig are actually part of the komodo team. You may aswell have no escrow.

http://archive.is/6hg11

Timeframe was too short  (I´m here almost every day, but not 24/7).

Anyway.... That's the way it is.

Sorry, there were many people wanting to do the German translation and we had to pick the one we though was the most capable. To be included you had to send a private message after the announcement.

That was probably people rushing to get BTC into Decent ico for the 50% bonus

They probably figured 50% bonus would make up for the lost % on the BTCD dump

Maybe they regret their move now that the decent launch was rekt