v0.11.1 - InstantX Development Update

UdjinM6

Official Dash Dev
Dash Core Team
Moderator
May 20, 2014
3,638
3,538
1,183
Few thoughts....
"He waits until be finds a block and includes all of the signed collateral transactions that are still valid" - it doesn't work that way actually, miner can't add anything after he found a block. To find a block means to find a hash of a block header which includes field "Transaction Merkle Root" which in its turn is a complex hash of hashes of txes that will be included in block. So to mine a block and gain these collateral fees malicious miner must include cached collaterals txes in every block he tries to find and check txes for validity before including them but the issue itself is still there of course.
There is no need to be so specific with 1/40 I guess - we can simply introduce 0.00200002 (1/50) or 0.00400004 (1/25) right now and use them.
 
  • Like
Reactions: coingun

crowning

Well-known Member
May 29, 2014
1,415
1,997
183
Alpha Centauri Bc
I think the collateral system is flawed.
:D Great job!
Do you know what I really LOVE about Darkcoin, above all other currencies?

There's someone showing up with the statement "You guys fucked things up", and instead of being offended and the usual fights and calling words and whatnot one of the Darkcoin team members shows up and says "Great find, thank you, want a beer?".

THAT's how you improve a software
 

flare

Administrator
Dash Core Team
Moderator
May 18, 2014
2,287
2,406
1,183
Germany
Do you know what I really LOVE about Darkcoin, above all other currencies?

There's someone showing up with the statement "You guys fucked things up", and instead of being offended and the usual fights and calling words and whatnot one of the Darkcoin team members shows up and says "Great find, thank you, want a beer?".

THAT's how you improve a software
That's why i joined 8 months ago and i am still here :)
 

eduffield

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

Thankfully I've known about this one and already have a strategy to fix it, I just haven't had time to implement it yet. It's rather simple, when the participant makes the collateral transaction, they currently use the normal CScript, which is OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG. This just checks their signature for validity, but that's it. I want to expand the script to say "Check the script and current time is before X". X will equal 5 minutes into the future, so the masternode can't collect these over a period of time and cash them in. Also, there's a requirement that all masternodes attempt to mix, before masternodes can attempt again. So they will be able to collect 1 every day or so, which is valid for five minutes then expires.

non-mixed collateral
Since the existing system is compatible with collateral payments that expire, we can simply begin using mixed 0.1 DRK denominations after they become available as collateral. These will have been through the mixer and serve as completely anonymous collateral.

This sounds like an excellent upgrade for after InstantX along with masternode blinding.
 

Aswan

Member
Jun 26, 2014
68
216
73
Do you know what I really LOVE about Darkcoin, above all other currencies?

There's someone showing up with the statement "You guys fucked things up", and instead of being offended and the usual fights and calling words and whatnot one of the Darkcoin team members shows up and says "Great find, thank you, want a beer?".

THAT's how you improve a software
Thats why I keep doing it. It's a pleasure to have development going that way.

I want to expand the script to say "Check the script and current time is before X". X will equal 5 minutes into the future, so the masternode can't collect these over a period of time and cash them in.
How is this enforced? I have made the experience that timestamps and the blockchain don't go well together. Why not make it 2 blocks or 3 blocks. Something like ntimelock, but in reverse (ntimecap?)

Since the existing system is compatible with collateral payments that expire, we can simply begin using mixed 0.1 DRK denominations after they become available as collateral. These will have been through the mixer and serve as completely anonymous collateral.

This sounds like an excellent upgrade for after InstantX along with masternode blinding.
There would still be the problem of Masternodes being able to cash Transactions at will. I think the "random" factor should not be up to the MNs, at least not exclusively. What do you think about introducing some PoW factor (like last blocks hash) so that MNs can't cheat when cashing collateral?
 

eduffield

Core Developer
Mar 9, 2014
1,084
5,319
183
How is this enforced? I have made the experience that timestamps and the blockchain don't go well together. Why not make it 2 blocks or 3 blocks. Something like ntimelock, but in reverse (ntimecap?)

There would still be the problem of Masternodes being able to cash Transactions at will. I think the "random" factor should not be up to the MNs, at least not exclusively. What do you think about introducing some PoW factor (like last blocks hash) so that MNs can't cheat when cashing collateral?

Actually the GetTime() function uses the average timestamps of recent blacks to calculate the current time. It's more like the current network time. But something like nTimeCap makes sense, seems like I could actually just reverse the nLockTime patch.

Masternodes have no incentive to cash in the collateral when it's not deserved. Collateral is paid to the miners directly, so they would have to be able to mine the block in order to be paid. Plus, collateral is suppose to be cashed every once in a while in order to reduce people spamming the blockchain. I think we'll just factor people doing that in. Let's say for example there's 10 attackers and 2000 masternodes, that means we'll have 10 out of 2000 more collateral charges, which doesn't really affect the overall amount paid (currently it's 1 of 40). I think the current way things are done makes sense and in unrealistic to exploit (with the nTimeCap changes anyway).
 

Mr. Spread

New Member
Jan 29, 2015
2
6
3
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.
This is how I implemented masternodes for SpreadCoin. Users can generate masternode secret with mnsecret command and then put it into spreadcoin.conf. This secret is essentially a new private key and a signature of the corresponding public key with masternode original private key. Will DarkCoin tokens be something similar?

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.
This is very similar to my implementation of masternodes. There are no special challenges though, each masternode is required to generate signed message containing hash of the last block, currently each masternode must confirm that it is running each 50 blocks but this number will probably be increased in the future.

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.
This is again similar to my implementation, in my implementation static IPs are not used at all, i.e. all masternodes can only confirm their existence by confirming blocks as described above and by confirming instant transactions in the future.

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.
I used similar method, there are 10 votes per block, each vote can be either to elect new masternode or to delect already elected masternode. But they are just votes, instead of immediately adding new masternodres they only contribute to this decision. If masternode has more than 30 votes in the last 60 blocks it is either elected or deelected. System where each miner can immediately add and remove new masternodes didn't look very reliable for me.

P.S. I can't post links but you can find source code for my implementation in the main SpreadCoin source tree in the "mn-test" branch.
 
Last edited by a moderator:

coingun

Active Member
Masternode Owner/Operator
Jul 8, 2014
489
402
133
masternode.io
This is how I implemented masternodes for SpreadCoin. Users can generate masternode secret with mnsecret command and then put it into spreadcoin.conf. This secret is essentially a new private key and a signature of the corresponding public key with masternode original private key. Will DarkCoin tokens be something similar?

This is very similar to my implementation of masternodes. There are no special challenges though, each masternode is required to generate signed message containing hash of the last block, currently each masternode must confirm that it is running each 50 blocks but this number will probably be increased in the future.

This is again similar to my implementation, in my implementation static IP are not used at all, i.e. all masternodes can only confirm their existence by confirming blocks as described above and by confirming instant transactions in the future.

I used similar method, there are 10 votes per block, each vote can be either to elect new masternode or to delect already elected masternode. But they are just votes, instead of immediately adding new masternodres they only contribute to this decision. If masternode has more than 30 votes in the last 60 blocks it is either elected or deelected. System where each miner can immediately add and remove new masternodes didn't look very reliable for me.

P.S. I can't post links but you can find source code for my implementation in the main SpreadCoin source tree in the "mn-test" branch.
Thanks for the recap on your ways of thinking about implementation Mr. Spread. Do you have anything else you decided to change in your implementation to add functionality or improvements. We would love to hear about anything else on your mind regarding constructively improving Masternode implementation.
 
  • Like
Reactions: moli

Mr. Spread

New Member
Jan 29, 2015
2
6
3
I'm not very familiar with DarkCoin implementation of masternodes so I can't tell you much about the differences in my implementation and DarkCoin's.
Regarding improvements in DarkCoin, I think is is better to use hash such as SHA-2 or X11 for masternode scores instead of some complicated algorithm which subtracts points in 4D space and does some other arbitrary things.