• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

v0.11.1 - InstantX Development Update


Core Developer
Now that the network has updated to version 11 and is stable, I thought it might be a good idea to lay out what the next we have in store for the next release and future plans. We’ll be leveraging our larger development team and working on a few projects at once to enable to a few new exciting features at once.


Network fragmentation has been corrected on the network and we’ve enabled enforcement. Those not paying the correct node after today will simply be rejected by the network.


A couple months ago I open sourced the design so that I could work with researchers on perfecting it. However, it’s not presently done and the code is a simple prototype of what I intended. I would recommend other crypto-currencies from not using it until we’ve had a chance to thoroughly test and refine the logic, otherwise grave damage could be done to your network.

We’ll begin finishing development on instantX immediately and work on the stability of the system. This will be done over the next few weeks on testnet and will be a completely open public testing phase.

Masternode Changes / Improvements

As an upgrade to the masternode system, we’re going to be moving to a token-based system, where you’ll only be required to gain access to your cold wallet every few months. When starting a masternode, one will simply execute the “masternode generate-token” command, which will sign the key and generate a tokenized string to put into the masternode.conf. Using this signature masternodes can be restarted multiple times, even with protocol version updates.

The pinging system (dseep) is going to be replaced with a “challege request” system, which will be done in a completely decentralized way. Other masternodes on the network will be elected each block to check on their peers by initiating a “challenge request”, if a masternode fails multiple of these in a row by failing to respond it will be removed from the list.

As be move forward into the future, static IPv4 IPs will continue to get more scarce. In the next release we will begin to allow non-static IPs to be used as long as the client is reachable and can answer challenge requests.

Beyond version 11.1 (will not be in the InstantX release)

Masternode Blinding

Recently a paper by 3 researches at Saarland University came out describing a new technique, while there are some serious problems with the approach they take, the concept of blinding the users they use is novel. In CoinShuffle, each output is sent to the next peer in a circle, one at a time. The new peer adds an output, shuffles and then sends the list again. We can do this and actually improve upon it.

To implement blinding, each user would connect to one completely random masternode and say "Send masternode X this output/value for mix N" and pass a single output. That output would be passed to the leading masternode. It would take access to all masternodes used to know who did what, which is as solid as M rounds mathematically (M = number of outputs). This is great because all users can submit all inputs at once. So it's super fast compared to CoinShuffle and even more secure.

Decentralization of the masternode payment system

Currently, there is a node that signs a message for each block and says which masternode should be paid for that specific block. As many of our users know, the centralized reference node was a temporary solution to the problem of enforcing masternode payments. Miners use this when creating the block to ensure they comply, if a miner tries to cheat the system, the block will be rejected by the network. This is a great solution temporarily, but isn’t decentralized enough.

To explain the new completely decentralized strategy, first we have to explain exactly how masternodes work. When a masternode starts, it relays a message called the “masternode election entry”. This puts the masternode into a list on all clients on the network and allows them to be used by all of the clients on the network. Every few minutes, these masternodes ping the network saying they’re still alive and allowing them to earn interest payments.

To decentralize this system, we propose a new system we’ll call “Masternode mining”. This simply means that when miners receive a new “masternode election entry” and solve a block, they will append the masternode to the block. Each block can contain up to 10 masternode list changes. So by following the normal progression of the blockchain, you will be able to compile a list of all known masternodes. This system is also highly resistant to attack and the same list can be compiled by any client on the network.

For example:

Block 1: Add mn1, mn2, mn3
Block 2: Add mn4, mn5
Block 3: Remove mn2 //mn2 fell off the network

-- currently the masternode list contains mn1, mn3, mn4, mn5

Block 4: Add mn6, mn7
Block 5: Add mn2 //mn2 came back

-- example attack: --

Block 6: Remove mn1, mn2, mn3, mn4, mn5, mn6 //miner owns masternode 7, wants control of the network
Block 7: Add mn1, mn2, mn3, mn4, mn5, mn6

In this case a majority of mining power is required to control the masternode list. If a miner has enough computing power to alter the masternode list, they will also have enough power to double spend with a 51% attack. Therefore this is the safest solution to decentralizing the payment.
Does that mean .13 is the final release for now and we will not have any more updates until InstantX release?
So the masternode's IDs become embedded into the blockchain and hacking now must involve attacking the blockchain via the miners. And we're talking 240 masternodes identified per hour, the whole system could update in 8 hours then.
Hats off to Evan, this is a superb workaround to probably the last piece of (vulnerable) centralization of the masternode system.
I find this easier to understand than how it was last implemented, LOL. So we will have the 50% attack, just like Bitcoin. Something tells me that the team will one day come up with a solution to that as well! Seriously, though, I love this new masternode blinding system, it seems simple and elegant again. I can't wait for it to start!

With this new darksend system, it sounds like mixing through several nodes will go very quickly, and if that's so, and it's blind, and everyone mixes 8-16 rounds, could we call this 100% fungible?
Great update
tx for this

I am still voting for 150% Anonymity 1st (in DS and MN's)
before we move onto anything else !!
(and i am happy to see you guys are on it)

Edit: + Ladies

Edit II:
"sexiest update" we had so far:
Last edited by a moderator:
Why not to pay multiple masternodes in one block to smooth rewards? (block size?)
I know we are testing new technology but there are someone always disappointed with all that enforcement off, reference node restarts, forks and stucks. Generally speaking I don't remember any month among last six when payouts were stable and weren't interrupted.