[ANN][DASH] Dash (dash.org) | First Self-Funding Self-Governing Crypto Currency

[salmion]

Talk about timing, LOL, just sat down and refreshed my browser and saw this

https://darkcointalk.org/threads/development-updates-july-7th.1735/

Thanks Evan!

+101





Very elegant. Master node passes denominated coins to one or more master nodes in series.

Thats Kick-ass.

Masternode passes denominated coins back to client on random addresses,  client passes them from random addresses to a 2nd Masternode.

bump

[hartvercoint]

https://darkcointalk.org/threads/development-updates-july-7th.1735/page-2#post-11487


fernando

You are right. If someone controlling both masternodes can deanonymize transactions (haven't checked with devs, maybe there is some measure in that area already), the risk is still there. However, thanks to the high number of masternodes, it is extremely low. I've done some numbers for 600 masternodes (we are at 605 now), 800 and 1000. At 600 you need 61 masternodes (now about 436k USD) coordinated to act roguely to get a 1% chance of deanonymize a transaction. With 1000 masternodes you need more than 100 masternodes for that 1%.

Of course, if you are just looking for any transaction, even a low percentage maybe good enough, but I'm sure devs can do something in the communication with MNs so the probability goes to zero. Something needs to be left for Darksend++ or the fun is going to be over too fast :wink:

You can check the numbers at the table below or in Google Docs: http://j.mp/1mEtWz4

- snip -

Not selecting MN2 from the same IP range that MN1 is in, will already help to mitigate the risk of choosing two nodes that are run by the same entity. It also shouldn't happen that MN1 and MN2 have very similar or very little uptime.

The problem of one entity owning the used nodes is inherent to Tor as well and a lot of the countermeasures Tor takes might be used for masternodes too.

But masternodes can be hosted anywhere, if I had another I wouldn't host it on Amazon Australia servers where my first one is.

That's not an argument against prohibiting the selection of two nodes that are _obviously_ run by the same person.

[luigi1111]

Please tell me someone will be ready to put this on the OP and draw attention to the fact that DS has been drastically changed/improved?

Shame to wait for days for an OP update on something this big...

How does it deal with decimal point leftovers? Those could act like flags on change addresses... When do you send exact even numbers anywhere? Shouldn't these be duff-level denominations? Image just dumbed down?

That sub-1 change still has all sorts of problems from my perspective (note: when sending a "rounded" tx, the above method seems pretty nearly flawless; the only weakness I can think of at this time is if there's say 3 transactions happening, and one of the wallets doing the sending has (and is trying to send) less than either of the other two. It wouldn't work in this case, as one could still simply follow inputs/outputs.)

A way to somewhat alleviate the above scenario would be to have a "Prepare wallet for Darksend+" button, which would complete step one (with masternode 1), leaving a bunch of denominated change around to send in later transactions. Then you would have different transactions involved in an actual Darksend+ transaction versus who shared in the change denomination session.

But back to the sub-1 change issue. Let's say we need to send 17.54321 DRK from A to B (we can ignore other senders/receivers):

A sends 20 DRK to MN1; he get's change back as follows:
C gets 10 DRK
D gets 5 DRK
E gets 1 DRK
F gets 1 DRK
G gets 1 DRK
H gets 1 DRK
I gets 0.54321 DRK
J gets 0.45679 DRK

Now the transaction can proceed as normal, going to MN2 as expected (addresses C, D, E, F, and I get sent). B receives the requested 17.54321 DRK.

The problem is address J is now tainted and could potentially link some things together if used for future transactions with F, G, and H (if used with all 3 simultaneously, it would 100% link the original A to B tx). Additionally, it has the further weakness of not being very useful for future Darksend+'s, as it won't denominate well.

The potential "fix" that's on my mind (maybe just a workaround) is to store up these "tainted", mostly useless addresses until you have them totaling more than 1 (or 5, or whatever), at which point they could be sent to a special "redenominating" pool (and maybe you don't even need a pool, I haven't taken the time to think through all the implications of just doing it like a normal Darksend+) for recycling back to standard sized change addresses. You would still end up with one sub-1 address every time, but that's not too big of deal in my view.

Any thoughts?

[JGCMiner]

https://darkcointalk.org/threads/development-updates-july-7th.1735/page-2#post-11487


fernando

You are right. If someone controlling both masternodes can deanonymize transactions (haven't checked with devs, maybe there is some measure in that area already), the risk is still there. However, thanks to the high number of masternodes, it is extremely low. I've done some numbers for 600 masternodes (we are at 605 now), 800 and 1000. At 600 you need 61 masternodes (now about 436k USD) coordinated to act roguely to get a 1% chance of deanonymize a transaction. With 1000 masternodes you need more than 100 masternodes for that 1%.

Of course, if you are just looking for any transaction, even a low percentage maybe good enough, but I'm sure devs can do something in the communication with MNs so the probability goes to zero. Something needs to be left for Darksend++ or the fun is going to be over too fast :wink:

You can check the numbers at the table below or in Google Docs: http://j.mp/1mEtWz4

- snip -

Not selecting MN2 from the same IP range that MN1 is in, will already help to mitigate the risk of choosing two nodes that are run by the same entity. It also shouldn't happen that MN1 and MN2 have very similar or very little uptime.

The problem of one entity owning the used nodes is inherent to Tor as well and a lot of the countermeasures Tor takes might be used for masternodes too.

But masternodes can be hosted anywhere, if I had another I wouldn't host it on Amazon Australia servers where my first one is.

That's not an argument against prohibiting the selection of two nodes that are _obviously_ run by the same person.

Can you explain in more detail? Or are there some Tor reference materials?  

[dotnetmin]

Has anybody also had a problem with vultr server. Mine was shut down again and i don't know why.
Server was running but darkoind was shut down. It looks like server gets started new but darcoind
is not into startup routine.

[thelonecrouton]

Given the percentage chart posted earlier (soon you will need 100 masternodes just to de-anonymize 1% of the transactions), I think this is the real concern.  Just how much can amazon unveil if prodded by the gov't? This alone is reason for some sort of encryption even if it is a major undertaking.  

I don't know, but from my limited software development experience I suspect that getting the machinery in place to process the transactions is the bigger job by far, encrypting the traffic should be fairly straightforward once Darksend+ is in place, and the developers will probably have an easier time testing without encryption to begin with.

In short I expect some form of encryption/IP obfuscation to be rolled out pretty soon after Darksend+ has been shown robust on main net. Of course it depends on the team's longer term strategy - what else they have planned and how it all fits together.

[luigi1111]

Has anybody also had a problem with vultr server. Mine was shut down again and i don't know why.
Server was running but darkoind was shut down. It looks like server gets started new but darcoind
is not into startup routine.

I have not had any trouble with them. I set up alerts as El Presidenté suggested, and they have only showed down once (been up since payments started). I went and looked right away when the alerts showed down, but they were all up, so even that must have been a glitch.

[SoapMaker]

I should change my name to the PeaceMaker.
My post to the Cloak thread.

A little bit dissapointed that the PoSA diddnt finished before the deadline again, but i see you guys working really hard to get this coin on the right place. And i appreciate it very much.
Good luck with futher developents.

& How many darkcoiners are in here turning this thread into a fud warzone ?
---NONE---
Respect is a 2 way street please.
Best wishes & good job Cloakcoin devs & community.
Keep up the great work in the name of all cryptocurrencies.
We have bigger enemies than each other

(I only post this because DutchTrades was a touch nasty & offensive some days ago, insulting our community & pumping Cloak in our thread. It really doesn't help anyone.)

Hmm..
No spamming, but with cloak around the corner, i think its better if you sell (a part) of your darks.

[Propulsion]

Has anybody also had a problem with vultr server. Mine was shut down again and i don't know why.
Server was running but darkoind was shut down. It looks like server gets started new but darcoind
is not into startup routine.

Look into Crontab.

[hartvercoint]

Can you explain in more detail? Or are there some Tor reference materials?  

Say you have 5 master nodes on the network:

1.1.1.1
1.1.1.2
12.41.11.35
5.24.156.3
96.4.223.44

1.1.1.1 is selected as MN1. Now it'd be obviously foolish to choose 1.1.1.2 as MN2, because 1.1.1.1 and 1.1.1.2 are very likely run by the same person. Additionally in case of compromise it would (regardless of the fact who runs them) be more likely that both of them are compromised because they are likely running similar setups or may even be running on the same physical machine.

[humanitee]

Is anyone knowledgeable enough about Amazon EC2 to tell me whether or not they are a threat to the masternode network? What I mean is, could they unveil large amounts of users if they wanted to simply because they have access to the physical machines? With all the xKEYSCORE and general NSA bullshit it seems like you can never be sure that a private company is operating privately any more.

Anyone using Amazon has an account there, with credit card or something.  So yah, Amazon has all the information to out you if you have a Masternode with them.  Like Google, they could give the Gov any info the Gov asked for (with a warrant) It has nothing to do with Amazon having access to your virtual machine, they don't have to mess with that any.

Our masternode ip addresses on the network will definitively show that we are running masternodes.

But, there is no law against crypto currency, and if they try to do that, they lose.

I meant could the whole Amazon network act similarly to one entity owning 300 master nodes, being a bad actor, and unveiling users trying to Darksend. Thanks for your reply though! 

Can you explain in more detail? Or are there some Tor reference materials? 

Say you have 5 master nodes on the network:

1.1.1.1
1.1.1.2
12.41.11.35
5.24.156.3
96.4.223.44

1.1.1.1 is selected as MN1. Now it'd be obviously foolish to choose 1.1.1.2 as MN2, because 1.1.1.1 and 1.1.1.2 are very likely run by the same person. Additionally in case of compromise it would (regardless of the fact who runs them) be more likely that both of them are compromised because they are likely running similar setups or may even be running on the same physical machine.

I like this idea.

[thelonecrouton]

The problem is address J is now tainted and could potentially link some things together if used for future transactions with F, G, and H (if used with all 3 simultaneously, it would 100% link the original A to B tx). Additionally, it has the further weakness of not being very useful for future Darksend+'s, as it won't denominate well.

The potential "fix" that's on my mind (maybe just a workaround) is to store up these "tainted", mostly useless addresses until you have them totaling more than 1 (or 5, or whatever), at which point they could be sent to a special "redenominating" pool (and maybe you don't even need a pool, I haven't taken the time to think through all the implications of just doing it like a normal Darksend+) for recycling back to standard sized change addresses. You would still end up with one sub-1 address every time, but that's not too big of deal in my view.

Any thoughts?

Does this become a non-issue if Darksend is mandatory? If not then yes, some in-wallet automagic might need to happen.

[salmion]

It paaaaains me seeing litecoin's price higher than dark... 0.018 and stable seems reasonable. Above that when we've sporked and it works.

[JGCMiner]

Is anyone knowledgeable enough about Amazon EC2 to tell me whether or not they are a threat to the masternode network? What I mean is, could they unveil large amounts of users if they wanted to simply because they have access to the physical machines? With all the xKEYSCORE and general NSA bullshit it seems like you can never be sure that a private company is operating privately any more.

Anyone using Amazon has an account there, with credit card or something.  So yah, Amazon has all the information to out you if you have a Masternode with them.  Like Google, they could give the Gov any info the Gov asked for (with a warrant) It has nothing to do with Amazon having access to your virtual machine, they don't have to mess with that any.

Our masternode ip addresses on the network will definitively show that we are running masternodes.

But, there is no law against crypto currency, and if they try to do that, they lose.

I meant could the whole Amazon network act similarly to one entity owning 300 master nodes, being a bad actor, and unveiling users trying to Darksend. Thanks for your reply though!  

Can you explain in more detail? Or are there some Tor reference materials?  

Say you have 5 master nodes on the network:

1.1.1.1
1.1.1.2
12.41.11.35
5.24.156.3
96.4.223.44

1.1.1.1 is selected as MN1. Now it'd be obviously foolish to choose 1.1.1.2 as MN2, because 1.1.1.1 and 1.1.1.2 are very likely run by the same person. Additionally in case of compromise it would (regardless of the fact who runs them) be more likely that both of them are compromised because they are likely running similar setups or may even be running on the same physical machine.

I like this idea.

Yeah, that does seem like an very good intermediate step before I2P or data encryption.  

[hartvercoint]

But back to the sub-1 change issue. Let's say we need to send 17.54321 DRK from A to B (we can ignore other senders/receivers):

A sends 20 DRK to MN1; he get's change back as follows:
C gets 10 DRK
D gets 5 DRK
E gets 1 DRK
F gets 1 DRK
G gets 1 DRK
H gets 1 DRK
I gets 0.54321 DRK
J gets 0.45679 DRK

I think it's obvious that this will work the same way with 0.5, 0.2, 0.1, 0.05 ... and smaller inputs.

[dotnetmin]

Has anybody also had a problem with vultr server. Mine was shut down again and i don't know why.
Server was running but darkoind was shut down. It looks like server gets started new but darcoind
is not into startup routine.

Look into Crontab.

Do you think there could be a entry that reboots the server ?

[SoapMaker]

MORE from the PeaceMaker. ...Soap & Peace are related now that I think about it.
I posted this 4 days ago when we were crashing HARD & XC was up 40 or so %.

Congrats to the XC community ! XC is doing very well today. We at drk are taking quite a beating. Such is life. I am really enjoying the peace between our communities. Enjoy these good times, you guys deserve it. Peace.
-Darkcoiner.

Thank you sir! Much appreciated, and thanks also for your generosity here.

Thanks for the kind words. I'm sure that the situation with Dark is just traders doing their thing. Good luck, I hope we see you around some time soon.

+1.

can't believe that peace is coming in this way.

tks

It is so nice.   Wished it was like this from the beginning.

Wow... thanks man.. I want to hold your hand and sing songs.. but my screen is in the way

Thank you sir for the kind words!

 

[luigi1111]

The problem is address J is now tainted and could potentially link some things together if used for future transactions with F, G, and H (if used with all 3 simultaneously, it would 100% link the original A to B tx). Additionally, it has the further weakness of not being very useful for future Darksend+'s, as it won't denominate well.

The potential "fix" that's on my mind (maybe just a workaround) is to store up these "tainted", mostly useless addresses until you have them totaling more than 1 (or 5, or whatever), at which point they could be sent to a special "redenominating" pool (and maybe you don't even need a pool, I haven't taken the time to think through all the implications of just doing it like a normal Darksend+) for recycling back to standard sized change addresses. You would still end up with one sub-1 address every time, but that's not too big of deal in my view.

Any thoughts?

Does this become a non-issue if Darksend is mandatory? If not then yes, some in-wallet automagic might need to happen.

I don't really know. With Darksend+ going around all over the place, the blockchain will be really foggy, particularly to humans. But a computer might be able to figure some of it out, maybe just in specific situations dependent on size of tx.

Whether Darksend+ should be mandatory is another topic entirely. I'm not presently sure you could even make it so. Nodes (or the block finder) would need to reject transactions not originating from the elected masternode(s) with an exception for the block reward I guess.

[salmion]

Development Update - July 7th

https://darkcointalk.org/threads/development-updates-july-7th.1735/

bump

[dark-sailor]

Has anybody also had a problem with vultr server. Mine was shut down again and i don't know why.
Server was running but darkoind was shut down. It looks like server gets started new but darcoind
is not into startup routine.

Look into Crontab.

Mine all good been up 9 days now no problems