great!

join #notarynode and get a testnet notary going

Notary mining wars - and how to avoid them

Using PoW as the initial consensus mechanism creates the possibility that the notary nodes will start a mining war against each other. Now they are supposed to be a cooperative group so we hope this is just a theoretical issue, however I must have been more affected by the cold I had earlier in the week as I had calculated the end of BTC subsidy at $1.25 KMD price. Which, even in the most optimistic scenario was 5x increase, so I figured this was not an urgent issue to solve.

Now that ZEC futures are trading around $100, if KMD trades at 1% of ZEC, we are looking at $1 price. What is "worse" is that I was off by a factor of 5 and the end of BTC subsidy will happen at 25 cents KMD price. That is just a bit above the max raise value, so it appears that we need a solution to this.

The reason is that during the subsidy period, there is a financial balancing that can be done by withholding subsidy to a notary that overmined over the average. However if the KMD that is mined is well above the $500/mo, then this withholding wont have much effect.

    "blocks" : 13020,
    "connections" : 46,
    "difficulty" : 2.41007651,

With diff well above 1.0 for testnet, it does seem that a solution is needed.

with 1 minute blocks being sustained (actually more like 45 seconds recently), that is 1440 blocks per day or 43,200 per month. 1/64th is 675 blocks per month per notary or ~2000 KMD per month, so 25 cents price matches the $500/mo

What this means is that above 25 cents market price, there wont be need for much BTC subsidy. The bitcoin txfees would be the only BTC that is needed by the notary nodes.

Here is my proposed solution:

KMD can be in one of two modes: Notaries Active or No Notary

We are currently in the No Notary mode and it is the usual free for all PoW race. We have verified 1 min blocks are sustainable and so even in the even all notary nodes are disappeared, there is a fallback so that the KMD chain will continue on. Of course without notary nodes, there is no bitcoin protection, so we dont expect we will see such conditions other than right after genesis and before the first slate of notaries are selected, or some unexpected black swan event. I am also leaning toward just starting off with the testnet notaries as the official notaries, until there is the official election. We now have quite a few testnet notaries, but it isnt too late to get your node participating, especially for North America(!) or Asia (eastern europe). European nodes are getting very close to the 16, if not already there. We dont have any African or South American nodes yet.

For the Notaries Active mode, I propose the following to avoid notary mining wars:

At each height, a single notary node gets to mine at the current difficulty, this will rotate in a round-robin so each notary node gets 1/64th of the current difficulty blocks.

At all heights, the rest of the notary nodes get to mine at 10x the current difficulty.

Everyone else gets to mine at 100x the current difficulty.

####

I believe the above will make any mining war between notary nodes uneconomic. It does have the issue of transitioning from Notaries Active mode, as if all notaries are gone we need to get a special tx confirmed to switch to No Notaries mode, but that would require 100x the hashrate. However, using a GPU it appears that 50x or more the hashrate of the default miner can be achieved and assuming it is from a baseline of around 1.0 to 2.0 diff, we will be able to get the special tx confirmed within 10 minutes.

Notice a good side effect of this is we can easily detect a specific notary node that is not generating blocks on their turn, just by looking for blocks that take ~10 minutes. That is a painful duration, but not any thing so drastic, so I think any unreliable notary node that subjects the rest of the network to multiple 10 minute blocks will soon be voted out by the majority of the other notary nodes.

Since the notaries will be operating as a cooperating peer group, and they are most directly able to tell the lagging notary, I think the usage of notary majority to replace a misbehaving notary will keep the set of  official notaries reasonable. It could well be that after the initial election, there wont need to be a general election at all.

Of course, there still needs to be a provision for a global notary election after the initial slate and a one third notary node + special signature will be able to effect just a new slate of notary nodes.

Not sure about limiting the power of the majority notary nodes to replace 1 node at a time is a good idea or not. By limiting the number of such replacements per time period, it can limit the rate of change of notary composition. Then if it looks suspicious, a general election of all notary nodes can be invoked to put a stop to the one-by-one installation of crony notaries.

One thing to keep in mind is that this will not be a machine driven thing, but a human driven one. So there will be chat logs available to see why a certain notary was replaced with another.
 

post ICO trading is hard to predict. All I can do is continue to complete the dPoW and release the mainnet. Then get the easyDEX deployed. Then continue with the tech roadmap of assetchains, pangea, pax, smartchains. The market will do what it does.

dPoW release is just the start. The current codebase is designed to solve a lot of the practical problems crypto has. With dPoW providing the bitcoin security, it enables all the other solutions which otherwise would either be too slow or not secure enough

If you have BTCD, it is simple.

Hold it until after the snapshot and then you have up to one year to convert to KMD.
Whoever says the BTCD price will drop a lot after conversion is active seems to miss the fact that the conversion is possible.

Anyway, we have made the recommendation on the best path for BTCD holders many times. Not sure why people are still confused

with  a signature you can prove you control the privkey that generates a specific pubkey, without divulging the privkey. this is the entire basis for current day crypto

We now have a couple of blockexplorers:

http://www.zpool.ca/explorer/1720 is by crackers

and http://148.251.57.148:3001/ was ported by oxarbitrage. hashes are endian reversed, but it has richlist and address balances and is quite useful for testing

As long as you are credible and have a smoothly running testnet notary. However if the choice is between someone without the real server ready vs. one that has it  ready and all else is equal...

At this point I dont think we will have more than 64 candidates though, so it should be ok.

Important thing is to be active and interact with the other testnet notaries. There will be a non-binding peer ranking among the testnet notaries for all the other notaries. This way the electorate can see how each testnet notary is viewed by the others on several scales, ie technical competence, helpfulness, reliability, promptness, etc.

In addition to objective metrics I think having subjective metrics from the peer group will be useful. While in some sense the notaries are competing with each other, they are much more cooperating with each other as the majority of the testnet notaries will become the official ones. At least at first.

Now it is possible some large investors or investor groups will want to vote in their own notary operator, maybe simply to increase their ROI or more strategically to ensure that any 51% attack is one notary node more difficult to achieve. Controlling a notary node wont really provide any other advantage that I can see to any stakeholder as there is a separation of powers and after a few blocks it is notarized by bitcoin

you need to join #notarynode in the supernet slack. autoinvite via slackinvite.supernet.org

The way to get added to the list is to get a testnet notary node running and get me your pubkey that you are mining with.

Max of 64 official notary node operators

{
    "version" : 1000000,
    "protocolversion" : 170002,
    "walletversion" : 60000,
    "balance" : 5310.00000000,
    "blocks" : 10219,
    "timeoffset" : -46,
    "connections" : 44,
    "proxy" : "",
    "difficulty" : 1.18325498,
    "testnet" : false,
    "keypoololdest" : 1475379350,
    "keypoolsize" : 101,
    "paytxfee" : 0.00000000,
    "relayfee" : 0.00005000,
    "errors" : "This is a pre-release test build - use at your own risk - do not use for mining or merchant applications"
}

Komodo testnet has sustained 1 minute blocks for over a day now! With the 2MB block limit, that means KMD can handle 20x the number of transparent tx that bitcoin can. The zcash tx are quite a bit bigger so the number would be about 5x smaller if measured in zcash tx.

Thanks to all that are running testnet nodes. If you have any decent type of server, it will be enough for testnet purposes and you can get a head start on being elected as an official notary node for the $500/mo payment

Being up to speed on the technical side is the most important part of running a notary node. There appear to be plenty of vendors that offer cost effective hardware and bandwidth with the needed requirements of 64GB RAM and 500GB SSD, 100mbit/sec+ bandwidth

to everybody that is sending me PM about translations, bounties, etc.

please dont.

I am not managing the ICO process, that is delegated out to the Komodo Platform team.

I am concentrating on the tech side

I will just ignore messages about such things.

Thanks for understanding.

I want to calibrate the number of notary nodes based on 10 year coverage from ICO funds. As KMD price grows, the need for subsidy is reduced, at $1.25 per KMD price, all 64 notary nodes are fully paid for just from the mined KMD.

So anything over 5000 BTC raised (assuming BTC price stable) would provide this coverage, though it needs to be adjusted by the BTC transaction fees upward and by the value of KMD downward.

So I will just set the number of official notary nodes assuming 10 years of 100% subsidy. That will almost certainly be on the conservative side.

Now in about 14years or so, the block rewards will stop due to reaching maximum coin supply from the 5% APR interest. So the daily txfees will be needed to pay for the notary nodes + btc fees at that point.

Since KMD has 20x the tx capacity as BTC, assuming dPoW is adopted by other blockchains, then there should be plenty of txfees

a) you would need to be able to run komodo, iguana and bitcoind, but most VPS hardware can handle that. however if low end CPU blocks will be hard to mine and you will need more threads. 1 fast core will likely outperform 4 slow ones

b) i dont think we will have 64 total candidates at first, but some will be running multiple nodes. Since being an incumbent will have the inertial advantage, I encourage everyone who wants to be a notary to just run a testnet notary node. Odds are good you will get elected to be an official one.

As the price of KMD goes above the breakeven point of $500/mo, then we could start seeing a lot more people wanting to become a notary as really it is a license to mint KMD and has value in and of itself. The fact that it is being subsidized at first just makes it have a very low barrier to entry. Again this is to broaden the base of potential notaries as wide as possible.

After the initial official voting, I expect the notary nodes to be rather stable as it is a potentially lucrative position without much risk, other than the time needed to stay current. Other than a "notary gone bad" situation necessitating a replacement,  I think we might also have the lower percentile ranked notaries able to be challenged by new candidate. This will ensure that the notary nodes performance will be able to evolve with the market and not be tied to current specs forever.

While for now 64GB RAM + 500GB SSD might seem like a high end server, in 3 years it will probably be in tablets and phones. So if the notary operators arent keeping up, the a challenger could start an election against the lowest performing notary(s).

These are things that are not set in stone yet and I am definitely open to feedback. On the one hand we dont want to be changing notary nodes like socks, on the other hand we dont want to be stuck with the same set of notary nodes forever unless they have been doing a fantastic job.

While the fundamental requirement of majority of existing notary nodes or (one third + special signature) being required to approve a notary node is pretty much set, the details of how elections are done is not final. I want to get the basic system in place and working first before solving all the future elections details.

If anybody knows of an appropriate election system to use, please let me know. Most elections have low participation and that can easily lead to being manipulated.

One idea I have is for the voter to vote not for a specific candidate, but to be able to specify a ranking algorithm based on objective metrics. Then the election process can have a 100% participation without being random.

The most important is to run a testnet notary node

join #notarynode in the SuperNET slack, auto invite at slackinvite.supernet.org

there will be a simple website to provide information about candidate's qualification and ip location and hardware specs.

For now, announce candidacy here. Be active in #notarynode and mine testnet blocks with your notary pubkey. This prove's technical competency and when voting time arrives, a lot of voters will choose to pick a random candidate, so just by being technically qualified gives a good chance of being elected

What the electorate wants to avoid is a large number of notary nodes all controlled by a single entity. So by having a set of qualified nodes to randomly select from is one way to achieve this.

If you have no contacts with "insiders", that is an advantage. You dont have to know anybody, just have to know how to run command line unix. By design, the control of Komodo is being spread as far and wide as possible. It is to everybody's advantage to have no large concentration of control

Also I want to make clear that there are no "insiders" as everything is open. The source is open while I am debugging, bugs and all. The process is open in realtime via SuperNET slack and this thread. So anybody and everybody is welcome to participate. There is no large company that has any large position, even SuperNET which probably has the largest BTCD position is likely to end up with less than 5% and it is a decentralized project that is also open to anybody and can usually be purchased at about the NAV of its holdings.

make sure to join #notarynode channel in the SuperNET slack
slackinvite.supernet.org

I would assume KMD will trade at most of the major exchanges. If you do not want to deal with their KYC, then dont use those exchanges, just use the DEX directly.

I wrote about the iguana DEX previously and submitted a draft whitepaper on it the other day

using iguana's native DEX that uses atomic cross chain swaps, there is no KYC, and you can trade against BTC and compatibles. Granted the blockchains do keep a record of all transactions, the zcash tech makes it a rather meaningless thing as the anon set is the entire number of transactions in the 2^28th tree

and there is no KYC

blockhashes of KMD is securely written to the bitcoin blockchain and further that data is used by the consensus logic. Basically the KMD blockchain data is extended to include small amount of the bitcoin blockchain

once the bitcoin blockchain confirms the tx with the KMD blockhash, then it becomes as secure as a bitcoin block as the bitcoin blockchain would need to be reorged for the KMD chain to be reorged.

from debug console you can do dumpprivkey
or backupwallet
or dumpwallet

geolocation on ip address
realtime turing tests for each notary node operator

Normally bitcoin miner generates a new address for each block reward. This is good for privacy, but it makes determining if a block is generated by a notary node problematic.

I pushed a new komodo version that lets you specify a single destination address for mined blocks. it is not required to update as it is not a hardfork, but if you are running testnet, then it would be good to update.

./komodod   -gen -genproclimit=6 -notary -pubkey="0286d7c2dc7b3cfc07e2ae3d3311b2be578e5d894da4a204345c713c7db7e76a20"

the pubkey is the pubkey from the iguana wallet, which can be obtained after doing a walletpassphrase login and an activehandle call. Maybe we can update the GUI to display the pubkey to make it easier.

If you dont have an iguana wallet: curl --url "http://127.0.0.1:7778" --data "{\"agent\":\"bitcoinrpc\",\"method\":\"encryptwallet\",\"passphrase\":\"a very strong passphrase here\"}"

if you already have an iguana wallet:
curl --url "http://127.0.0.1:7778" --data "{\"agent\":\"bitcoinrpc\",\"method\":\"walletpassphrase\",\"password\":\"a very strong passphrase here\",\"timeout\":86444}"

which outputs:

{"pubkey":"e9b52567e9e5ff99270e07b63a2a6f1ff41c4db58da62416f8b0b2c3f6c53b6c","RS":"NXT-LKC2-XCXF-U3LR-F9WSS","NXT":"15880686153265399104","btcpubkey":"0286d7c2dc7b3cfc07e2ae3d3311b2be578e5d894da4a204345c713c7db7e76a20","rmd160":"54a752f0d71b89d7c014ed0be29ca231c9546f9f","BTCD":"RGzoHWCedwL81g7hqtQ7fEvW3UexrzBZe8","BTC":"18icCzKN37XYwfkWNiQzZibJHDCNGo2Y6x","result":"success","handle":"","notary":-1,"persistent":"e9b52567e9e5ff99270e07b63a2a6f1ff41c4db58da62416f8b0b2c3f6c53b6c","status":"unlocked","duration":47475,"tag":"18292839364308746995"}

"btcpubkey" field is the one to use for the -pubkey parameter

Once all the blocks mined by notary nodes are to the same address for each notary node, then it allows calculation of how much each notary node mined per month and therefore any subsidy required. More importantly, it provides a way to determine if a block was generated by a notary node

strange...
https://blockexplorer.com/tx/1eb31641d61d30e5fbf5fc02d4488053b10c2de1df442e4b92f6cd43e8250ac5

splitfunds with 50 outputs ended up working, even though there were complaints about it. I guess this falls into not very normal and it is confusing the block explorers

I wont worry about the dust errors for now, I added a maxmode so it will have a large change output which hopefully will help it confirm.