v0.11.1 - InstantX Development Update

eduffield

Core Developer
Mar 9, 2014
1,084
5,319
183
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.

Enforcement

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.

InstantX

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.
 

jpr

Active Member
May 11, 2014
493
393
133
Does that mean .13 is the final release for now and we will not have any more updates until InstantX release?
 

eduffield

Core Developer
Mar 9, 2014
1,084
5,319
183
How does this new system decide which masternode gets paid?
When you have a consistent list of masternodes via blockchain technology, it's pretty easy to deterministically generate the winning node per block. I have a pretty decent implementation of a deterministic round robin algorithm I wrote that will work quite well and be very fair.
 

Sub-Ether

Well-known Member
Mar 31, 2014
1,516
1,254
183
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.
 

TanteStefana

Grizzled Member
Foundation Member
Mar 9, 2014
2,861
1,854
1,283
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?
 

tungfa

Administrator
Dash Core Team
Moderator
Foundation Member
Masternode Owner/Operator
Apr 9, 2014
8,895
6,724
1,283
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:
FB
 
Last edited by a moderator:

GilAlexander

Member
Jun 26, 2014
84
23
48
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.
 

Lukas_Jackson

Member
Nov 9, 2014
160
70
88
I am still voting for 150% Anonymity 1st (in DS and MN's)
before we move onto anything else !!
Looking at Bitcoin, there are many people who doesn't care about privacy so I would pleased them first and even vote for IX being implemented first.
Thanks to darksend we have strong privacy already and I am very interested to see how IX work.
I can wait a bit longer for anonymity (IP obfuscation and more).
 

tungfa

Administrator
Dash Core Team
Moderator
Foundation Member
Masternode Owner/Operator
Apr 9, 2014
8,895
6,724
1,283
Our key selling point is Privacy / Anonymity !
it does not matter what we deliver (IX or double speed IIXX), it will always be tainted by NOT delivering our original promises !
I can smell the FUD already
 

Lukas_Jackson

Member
Nov 9, 2014
160
70
88
Our key selling point is Privacy / Anonymity !
it does not matter what we deliver (IX or double speed IIXX), it will always be tainted by NOT delivering our original promises !
I can smell the FUD already
yeah, I know. It's just my curiosity ;)
 
  • Like
Reactions: tungfa

Aswan

Member
Jun 26, 2014
68
216
73
I see a problem with the incentive for masternode mining since there is no reward for doing it. I actually see the same problem with the current implementation of Darksend and it's collateral system, but to keep this thread on topic, lets talk about incentivized masternode mining.
Also, this term is a little confusing as is suggests masternodes would be staking with their 1000 DRK =/
 
  • Like
Reactions: paperThin

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
I see a problem with the incentive for masternode mining since there is no reward for doing it. I actually see the same problem with the current implementation of Darksend and it's collateral system, but to keep this thread on topic, lets talk about incentivized masternode mining.
Also, this term is a little confusing as is suggests masternodes would be staking with their 1000 DRK =/
What would you suggest for Darksend to be implemented without being attacked? I think the collateral system is to protect DS from being attacked.
 

Aswan

Member
Jun 26, 2014
68
216
73
What would you suggest for Darksend to be implemented without being attacked? I think the collateral system is to protect DS from being attacked.
I think the collateral system is flawed.
If 3 people sign a Tx with a 0.1 DRK miners fee and, instead of publishing the Tx, it will only be cashed with a chance of 1/40, then there are a lot of unclaimed and uncashed but signed transactions in the hands of MN owners, and most of them will remain valid for quite some time (until the output used for this Tx is used in another Tx and broadcast).
So for each DS round on a MN, the Mn owner can collect signed but unpublished collateral transactions.

Now there are 2 scenarios.
1.) The MN owner is a miner himself. He waits until be finds a block and includes all of the signed collateral transactions that are still valid. He can increase the reward by a significant amount doing that.
2.) The MN owner sells the signed collateral Txs to a miner who then includes them in a block as soon as he finds one.

There is also another issue with MN Collateral: It's unmixed. That way, whatever MN you use, it always knows the (or an) origin address of yours that can potentially lead to your identity.

I have not quite finished my thoughts about a possible fix. However, one of my ideas is to not use the standard collateral anymore but instead pay the fee from the DS Tx itself.
To achieve the 1/40 of 0.1 DRK probability average, we could introduce a new denomination of 0.0025DRK (which represents 1/40 of 0.1 DRK). Unfortunately, since noone wanted to listened to by suggestion about convertibilty ( T_T ), this denomination would have to have the size of 0.0025000025 DRK (250,000.25 duffs) in order to fit the current implementation of denomination convertibility.
With my suggestion of leaving out the small amount at the end of each denomination that makes it recognizable as a denomination, a 0.0025 denomination would be convertible for this suggestion.
This "fee denomination" could be used to pay for the DS Transactions fee. Currently, there is no incentive for miners to mine DS Txs because there is no fee. With this, the "fee part" of the collateral would have been shifted right into the actual Tx, adding mining incentive and using mixed coins. Note that the fee denomination can be mixed just the same way as other denominations. That way, masternodes cannot spy on someones origin Tx by looking at the collateral Tx, which adds anonymity in regards to malicious masternode owners.
Furthermore, because of convertibility, no fee denominations have to be carried around when not needed. A DS Tx only having 1 DRK inputs can ouput 1 DRK outputs and 0.0025 DRK outputs, having already substracted the fee.

So who pays the fee?
I thought about X transactions getting created, where X is the amount of DS participants. Each of those Txs lets another participant pay the fee, but only 1 Tx will be published. Every participant has to sign the Tx with him paying the fee. However, the Tx won't be valid until everyone signed.
I am not done thinking about a way to decide which Tx will eventually be signed by the others, but something along the lines of what the provably fair betting sites do. Maybe even in combination with a proof of work element (last blocks hash?).

So what about ppl spamming the network then?
Well, good question, but one thing is sure: non-mixed collateral is a privacy issue and we will have to come up with something else eventually.
I will keep thinking about it.

It's 4:40 AM here and I am more than just tired, so forgive me if I made some mistakes. It's not a finished concept, I am just sharing my thoughts.
 
Last edited by a moderator:

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
I think the collateral system is flawed.
If 3 people sign a Tx with a 0.1 DRK miners fee and, instead of publishing the Tx, it will only be cashed with a chance of 1/40, then there are a lot of unclaimed and uncashed but signed transactions in the hands of MN owners, and most of them will remain valid for quite some time (until the output used for this Tx is used in another Tx and broadcast).
So for each DS round on a MN, the Mn owner can collect signed but unpublished collateral transactions.

Now there are 2 scenarios.
1.) The MN owner is a miner himself. He waits until be finds a block and includes all of the signed collateral transactions that are still valid. He can increase the reward by a significant amount doing that.
2.) The MN owner sells the signed collateral Txs to a miner who then includes them in a block as soon as he finds one.

There is also another issue with MN Collateral: It's unmixed. That way, whatever MN you use, it always knows the (or an) origin address of yours that can potentially lead to your identity.

I have not quite finished my thoughts about a possible fix. However, one of my ideas is to not use the standard collateral anymore but instead pay the fee from the DS Tx itself.
To achieve the 1/40 of 0.1 DRK probability average, we could introduce a new denomination of 0.0025DRK (which represents 1/40 of 0.1 DRK). Unfortunately, since noone wanted to listened to by suggestion about convertibilty ( T_T ), this denomination would have to have the size of 0.0025000025 DRK (250,000.25 duffs) in order to fit the current implementation of denomination convertibility.
With my suggestion of leaving out the small amount at the end of each denomination that makes it recognizable as a denomination, a 0.0025 denomination would be convertible for this suggestion.
This "fee denomination" could be used to pay for the DS Transactions fee. Currently, there is no incentive for miners to mine DS Txs because there is no fee. With this, the "fee part" of the collateral would have been shifted right into the actual Tx, adding mining incentive and using mixed coins. Note that the fee denomination can be mixed just the same way as other denominations. That way, masternodes cannot spy on someones origin Tx by looking at the collateral Tx, which adds anonymity in regards to malicious masternode owners.
Furthermore, because of convertibility, no fee denominations have to be carried around when not needed. A DS Tx only having 1 DRK inputs can ouput 1 DRK outputs and 0.0025 DRK outputs, having already substracted the fee.

So who pays the fee?
I thought about X transactions getting created, where X is the amount of DS participants. Each of those Txs lets another participant pay the fee, but only 1 Tx will be published. Every participant has to sign the Tx with him paying the fee. However, the Tx won't be valid until everyone signed.
I am not done thinking about a way to decide which Tx will eventually be signed by the others, but something along the lines of what the provably fair betting sites do. Maybe even in combination with a proof of work element (last blocks hash).

So what about ppl spamming the network then?
Well, good question, but one thing is sure: non-mixed collateral is a privacy issue and we will have to come up with something else eventually.
I will keep thinking about it.

It's 4:40 AM here and I am more than just tired, so forgive me if I made some mistakes. It's not a finished concept, I am just sharing my thoughts.
Thanks, Aswan, for sharing your thoughts on this issue. I don't understand all what you've said and will need to read it again, but I'm sure our devs know what you're saying and thinking.

I hope eduffield will see this post and give us his thoughts.

Thanks again! :)
 

UdjinM6

Official Dash Dev
Dash Core Team
Moderator
May 20, 2014
3,638
3,538
1,183
I think the collateral system is flawed.
If 3 people sign a Tx with a 0.1 DRK miners fee and, instead of publishing the Tx, it will only be cashed with a chance of 1/40, then there are a lot of unclaimed and uncashed but signed transactions in the hands of MN owners, and most of them will remain valid for quite some time (until the output used for this Tx is used in another Tx and broadcast).
So for each DS round on a MN, the Mn owner can collect signed but unpublished collateral transactions.

Now there are 2 scenarios.
1.) The MN owner is a miner himself. He waits until be finds a block and includes all of the signed collateral transactions that are still valid. He can increase the reward by a significant amount doing that.
2.) The MN owner sells the signed collateral Txs to a miner who then includes them in a block as soon as he finds one.

There is also another issue with MN Collateral: It's unmixed. That way, whatever MN you use, it always knows the (or an) origin address of yours that can potentially lead to your identity.

I have not quite finished my thoughts about a possible fix. However, one of my ideas is to not use the standard collateral anymore but instead pay the fee from the DS Tx itself.
To achieve the 1/40 of 0.1 DRK probability average, we could introduce a new denomination of 0.0025DRK (which represents 1/40 of 0.1 DRK). Unfortunately, since noone wanted to listened to by suggestion about convertibilty ( T_T ), this denomination would have to have the size of 0.0025000025 DRK (250,000.25 duffs) in order to fit the current implementation of denomination convertibility.
With my suggestion of leaving out the small amount at the end of each denomination that makes it recognizable as a denomination, a 0.0025 denomination would be convertible for this suggestion.
This "fee denomination" could be used to pay for the DS Transactions fee. Currently, there is no incentive for miners to mine DS Txs because there is no fee. With this, the "fee part" of the collateral would have been shifted right into the actual Tx, adding mining incentive and using mixed coins. Note that the fee denomination can be mixed just the same way as other denominations. That way, masternodes cannot spy on someones origin Tx by looking at the collateral Tx, which adds anonymity in regards to malicious masternode owners.
Furthermore, because of convertibility, no fee denominations have to be carried around when not needed. A DS Tx only having 1 DRK inputs can ouput 1 DRK outputs and 0.0025 DRK outputs, having already substracted the fee.

So who pays the fee?
I thought about X transactions getting created, where X is the amount of DS participants. Each of those Txs lets another participant pay the fee, but only 1 Tx will be published. Every participant has to sign the Tx with him paying the fee. However, the Tx won't be valid until everyone signed.
I am not done thinking about a way to decide which Tx will eventually be signed by the others, but something along the lines of what the provably fair betting sites do. Maybe even in combination with a proof of work element (last blocks hash?).

So what about ppl spamming the network then?
Well, good question, but one thing is sure: non-mixed collateral is a privacy issue and we will have to come up with something else eventually.
I will keep thinking about it.

It's 4:40 AM here and I am more than just tired, so forgive me if I made some mistakes. It's not a finished concept, I am just sharing my thoughts.
Aswan , almost every your long post makes me angry (that I didn't find these issues by myself) and make me happy (that we have you here) at the same time. :confused::D Great job!
 

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
Aswan , almost every your long post makes me angry (that I didn't find these issues by myself) and make me happy (that we have you here) at the same time. :confused::D Great job!
This is why I love Darkcoin! You guys are great and this coin keeps getting better and better!!!!!
:):cool::):cool::):cool:
 
  • Like
Reactions: Sub-Ether

moli

Grizzled Member
Aug 5, 2014
3,255
1,830
1,183
UdjinM6, I also agree with what he said, "Well, good question, but one thing is sure: non-mixed collateral is a privacy issue "... When I tested by sending the collateral fees plus two denoms back to myself so I could mix them again... I thought, "hm not sure if i like this.." so i reposted that personally I wouldn't do it.