• 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

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).
 
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
 
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 =/
 
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.
 
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:
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! :)
 
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::grin: Great job!
 
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::grin: Great job!
This is why I love Darkcoin! You guys are great and this coin keeps getting better and better!!!!!
:smile::cool::smile::cool::smile::cool:
 
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.
 
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.
 
I think the collateral system is flawed.
:grin: 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
thumbsup.gif
 
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
thumbsup.gif
That's why i joined 8 months ago and i am still here :)
 
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.
 
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
thumbsup.gif

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?
 
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).
 
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:
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.
 
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.
 
Back
Top