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

[blajde]

If my AWS shutdown my server and I have no back up. Did I lose my coins?

[UdjinM6]

If my AWS shutdown my server and I have no back up. Did I lose my coins?

No, if you are using Hot/Cold MN setup your coins never leave your local wallet.

[HinnomTX]

Looks like gmaxwell is pushing for more privacy in Bitcoin:
https://github.com/bitcoin/bitcoin/issues/6568

One of the responses is intriguing, and highlights a known weakness in CoinJoin (and also affects Darksend):

The problem with CoinJoin is the difficulty in ensuring most or all of the participants are not malicious. If you have 4 inputs and 3 of them are an attacker in a CoinJoin, then the attacker knows which input and output you own. This gives the illusion of privacy, which may be worse. As with all of the input mixing methods, including ring signatures with ZKPs to prevent double spending, there is the possibility of sybil attack which makes them less attractive as privacy solutions.

This got me thinking, what if your client could appear as two (or more) clients by submitting two DarkSend inputs to be mixed nearly simultaneously (with possibly different numbers of mixing sessions)? Now a malicious attacker would be unable to completely back out from his own mixes which inputs are owned by whom.  Put in the above terms, if the attacker is submitting 3 inputs and your client is submitting 2 (or more) inputs, the attacker cannot know which outputs are yours. Put another way, you would use your own wallet's coins to provide additional liquidity.

Obviously this technique would not be immune to network traffic analysis, but what's recorded on the blockchain would preserve the 'plausible deniability' of coin ownership.
 

[ddink7]

Looks like gmaxwell is pushing for more privacy in Bitcoin:
https://github.com/bitcoin/bitcoin/issues/6568

One of the responses is intriguing, and highlights a known weakness in CoinJoin (and also affects Darksend):

The problem with CoinJoin is the difficulty in ensuring most or all of the participants are not malicious. If you have 4 inputs and 3 of them are an attacker in a CoinJoin, then the attacker knows which input and output you own. This gives the illusion of privacy, which may be worse. As with all of the input mixing methods, including ring signatures with ZKPs to prevent double spending, there is the possibility of sybil attack which makes them less attractive as privacy solutions.

This got me thinking, what if your client could appear as two (or more) clients by submitting two DarkSend inputs to be mixed nearly simultaneously (with possibly different numbers of mixing sessions)? Now a malicious attacker would be unable to completely back out from his own mixes which inputs are owned by whom.  Put in the above terms, if the attacker is submitting 3 inputs and your client is submitting 2 (or more) inputs, the attacker cannot know which outputs are yours. Put another way, you would use your own wallet's coins to provide additional liquidity.

Obviously this technique would not be immune to network traffic analysis, but what's recorded on the blockchain would preserve the 'plausible deniability' of coin ownership.
 

But don't those odds get quite low with multiple rounds of Darksend?

[HinnomTX]

Looks like gmaxwell is pushing for more privacy in Bitcoin:
https://github.com/bitcoin/bitcoin/issues/6568

One of the responses is intriguing, and highlights a known weakness in CoinJoin (and also affects Darksend):

The problem with CoinJoin is the difficulty in ensuring most or all of the participants are not malicious. If you have 4 inputs and 3 of them are an attacker in a CoinJoin, then the attacker knows which input and output you own. This gives the illusion of privacy, which may be worse. As with all of the input mixing methods, including ring signatures with ZKPs to prevent double spending, there is the possibility of sybil attack which makes them less attractive as privacy solutions.

This got me thinking, what if your client could appear as two (or more) clients by submitting two DarkSend inputs to be mixed nearly simultaneously (with possibly different numbers of mixing sessions)? Now a malicious attacker would be unable to completely back out from his own mixes which inputs are owned by whom.  Put in the above terms, if the attacker is submitting 3 inputs and your client is submitting 2 (or more) inputs, the attacker cannot know which outputs are yours. Put another way, you would use your own wallet's coins to provide additional liquidity.

Obviously this technique would not be immune to network traffic analysis, but what's recorded on the blockchain would preserve the 'plausible deniability' of coin ownership.
 

But don't those odds get quite low with multiple rounds of Darksend?

What you are thinking of is protection from being identified by the masternodes. By using multiple masternodes, each masternode only has the information to link inputs and outputs for one DarkSend mix. If I'm not mistaken, this does not protect against a sybil attack.

If the attacker is acting as a continuous 'liquidity provider' with, say 3 wallets, he could still fully back out an 8 round DarkSend mix with just you. The outputs that don't come back to his wallets are yours. Right?

[ddink7]

https://www.cryptocoinsnews.com/block-size-bitcoin-not-scale-effectively/

The article is flawed because it assumes that Bitcoin XT advocates assume that a larger block size will scale and be used indefinitely. On the contrary, everybody understands that a completely different system must be developed in order to properly scale the network to Visa levels. Bitcoin XT isn't trying to scale up to Visa levels...it's just trying to buy everyone some time while Lightning Network and other solutions are developed and tested and hopefully implemented.

tl;dr Increasing block sizes aren't meant as a permanent solution, they are meant as a stop-gap to buy time for the solution to be developed. Core devs just want to stick their head in the sand and hope that 7 TPS is sufficient until the eventual miracle solution just materializes and lands in their lap.

[ddink7]

Looks like gmaxwell is pushing for more privacy in Bitcoin:
https://github.com/bitcoin/bitcoin/issues/6568

One of the responses is intriguing, and highlights a known weakness in CoinJoin (and also affects Darksend):

The problem with CoinJoin is the difficulty in ensuring most or all of the participants are not malicious. If you have 4 inputs and 3 of them are an attacker in a CoinJoin, then the attacker knows which input and output you own. This gives the illusion of privacy, which may be worse. As with all of the input mixing methods, including ring signatures with ZKPs to prevent double spending, there is the possibility of sybil attack which makes them less attractive as privacy solutions.

This got me thinking, what if your client could appear as two (or more) clients by submitting two DarkSend inputs to be mixed nearly simultaneously (with possibly different numbers of mixing sessions)? Now a malicious attacker would be unable to completely back out from his own mixes which inputs are owned by whom.  Put in the above terms, if the attacker is submitting 3 inputs and your client is submitting 2 (or more) inputs, the attacker cannot know which outputs are yours. Put another way, you would use your own wallet's coins to provide additional liquidity.

Obviously this technique would not be immune to network traffic analysis, but what's recorded on the blockchain would preserve the 'plausible deniability' of coin ownership.
 

But don't those odds get quite low with multiple rounds of Darksend?

What you are thinking of is protection from being identified by the masternodes. By using multiple masternodes, each masternode only has the information to link inputs and outputs for one DarkSend mix. If I'm not mistaken, this does not protect against a sybil attack.

If the attacker is acting as a continuous 'liquidity provider' with, say 3 wallets, he could still fully back out an 8 round DarkSend mix with just you. The outputs that don't come back to his wallets are yours. Right?

Yes, if he's the only one on the network that's mixing other than you. That's got to be pretty unlikely for a full 8 round Darksend. But you raise a good point! Impossible is way better than unlikely.

[Melech]

https://www.cryptocoinsnews.com/block-size-bitcoin-not-scale-effectively/

The article is flawed because it assumes that Bitcoin XT advocates assume that a larger block size will scale and be used indefinitely. On the contrary, everybody understands that a completely different system must be developed in order to properly scale the network to Visa levels. Bitcoin XT isn't trying to scale up to Visa levels...it's just trying to buy everyone some time while Lightning Network and other solutions are developed and tested and hopefully implemented.

tl;dr Increasing block sizes aren't meant as a permanent solution, they are meant as a stop-gap to buy time for the solution to be developed. Core devs just want to stick their head in the sand and hope that 7 TPS is sufficient until the eventual miracle solution just materializes and lands in their lap.

It seems to me that the block-size limit was originally an anti-spam measure, that is now trying to be used to force people into paying higher fees.

Is it just me, or is this the wrong way to force fees?
Is there another reason to limit block size besides anti-spam, or forcing fees?

If it is only about fees, its definitely a stupid solution...
Limiting transactions per second to force fees is equivalent to shooting yourself in the foot to get free surgery...

To enforce fees... you enforce fees in the code... right?  Make fees required and set a minimum?  Why debate about block size when they really want to enforce fees?

[blajde]

Is hosting a masternode user friendly?

[110110101]

V12.0.45 is working great for me, really impressive work, all the new tools, wallet repair, backups,  syncing budgets, sporks, everything is super slick. It feels like a huge step forward, looking forward to what we can do with the budget system.  

v12.0.45 crashed all my MNs every two days. Still can't find the problem. Very frustrating. Since 8 days without any payment for all my  MNs.

Same problem here running the .45 daemon. I did catch an error in the console after a crash, but I don't understand what it refers to:

Code:

~/dash-0.12.0/bin$ terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

I'm running on a small digitalocean droplet with Ubuntu 14.04 server. All up to date and otherwise working as expected. My dash masternode seems to stop 1-2 times every 24-48h so I need to constantly keep an eye on it.

[110110101]

Is hosting a masternode user friendly?

You might need to understand a tiny bit of Linux, but yes it's pretty easy.

[blajde]

Is hosting a masternode user friendly?

You might need to understand a tiny bit of Linux, but yes it's pretty easy.

So you are saying that if I dont have any interest in linux it is close to impossible?

[salmion]

Is hosting a masternode user friendly?

You might need to understand a tiny bit of Linux, but yes it's pretty easy.

So you are saying that if I dont have any interest in linux it is close to impossible?

Not at all - but you do have to be willing to learn - something - lol

Or use one of the hosting services splawlik, node40, flare etc

[Lebubar]

Is hosting a masternode user friendly?

You might need to understand a tiny bit of Linux, but yes it's pretty easy.

So you are saying that if I dont have any interest in linux it is close to impossible?

Not at all - but you do have to be willing to learn - something - lol

Or use one of the hosting services splawlik, node40, flare etc

This is true - nearly effortless at that point :-D

And trust-less. You keep your coins in your own wallet

[Sub-Ether]

Is hosting a masternode user friendly?

You might need to understand a tiny bit of Linux, but yes it's pretty easy.

You can have the remote machine as windows, depends if your host/location allows the option.

[Minotaur26]

Looks like gmaxwell is pushing for more privacy in Bitcoin:
https://github.com/bitcoin/bitcoin/issues/6568

One of the responses is intriguing, and highlights a known weakness in CoinJoin (and also affects Darksend):

The problem with CoinJoin is the difficulty in ensuring most or all of the participants are not malicious. If you have 4 inputs and 3 of them are an attacker in a CoinJoin, then the attacker knows which input and output you own. This gives the illusion of privacy, which may be worse. As with all of the input mixing methods, including ring signatures with ZKPs to prevent double spending, there is the possibility of sybil attack which makes them less attractive as privacy solutions.

This got me thinking, what if your client could appear as two (or more) clients by submitting two DarkSend inputs to be mixed nearly simultaneously (with possibly different numbers of mixing sessions)? Now a malicious attacker would be unable to completely back out from his own mixes which inputs are owned by whom.  Put in the above terms, if the attacker is submitting 3 inputs and your client is submitting 2 (or more) inputs, the attacker cannot know which outputs are yours. Put another way, you would use your own wallet's coins to provide additional liquidity.

Obviously this technique would not be immune to network traffic analysis, but what's recorded on the blockchain would preserve the 'plausible deniability' of coin ownership.
 

But don't those odds get quite low with multiple rounds of Darksend?

What you are thinking of is protection from being identified by the masternodes. By using multiple masternodes, each masternode only has the information to link inputs and outputs for one DarkSend mix. If I'm not mistaken, this does not protect against a sybil attack.

If the attacker is acting as a continuous 'liquidity provider' with, say 3 wallets, he could still fully back out an 8 round DarkSend mix with just you. The outputs that don't come back to his wallets are yours. Right?

Yes, if he's the only one on the network that's mixing other than you. That's got to be pretty unlikely for a full 8 round Darksend. But you raise a good point! Impossible is way better than unlikely.

The system does not mix with the same partners through several rounds so I dont think this would apply to Darksend.

[GhostPlayer]

 Holy McOff-Topic !!

 Ethereum has just surpassed LTC in trading volume  

 This is great news as there is work being done to interconnect the two ...    Dash and Ethereum are a match made in Skynet... errr .. heaven. 

[toknormal]

Greece-doms not staying out of the news.

http://libertyblitzkrieg.com/2015/08/18/this-is-sparta-1000-bitcoin-atms-are-coming-to-greece/

[blajde]

Is hosting a masternode user friendly?

You might need to understand a tiny bit of Linux, but yes it's pretty easy.

So you are saying that if I dont have any interest in linux it is close to impossible?

Not at all - but you do have to be willing to learn - something - lol

Or use one of the hosting services splawlik, node40, flare etc

This is true - nearly effortless at that point :-D

I am busy learning other stuf.
Point being dont limit user group when key is expansion.

[HinnomTX]

Looks like gmaxwell is pushing for more privacy in Bitcoin:
https://github.com/bitcoin/bitcoin/issues/6568

One of the responses is intriguing, and highlights a known weakness in CoinJoin (and also affects Darksend):

The problem with CoinJoin is the difficulty in ensuring most or all of the participants are not malicious. If you have 4 inputs and 3 of them are an attacker in a CoinJoin, then the attacker knows which input and output you own. This gives the illusion of privacy, which may be worse. As with all of the input mixing methods, including ring signatures with ZKPs to prevent double spending, there is the possibility of sybil attack which makes them less attractive as privacy solutions.

This got me thinking, what if your client could appear as two (or more) clients by submitting two DarkSend inputs to be mixed nearly simultaneously (with possibly different numbers of mixing sessions)? Now a malicious attacker would be unable to completely back out from his own mixes which inputs are owned by whom.  Put in the above terms, if the attacker is submitting 3 inputs and your client is submitting 2 (or more) inputs, the attacker cannot know which outputs are yours. Put another way, you would use your own wallet's coins to provide additional liquidity.

Obviously this technique would not be immune to network traffic analysis, but what's recorded on the blockchain would preserve the 'plausible deniability' of coin ownership.
 

But don't those odds get quite low with multiple rounds of Darksend?

What you are thinking of is protection from being identified by the masternodes. By using multiple masternodes, each masternode only has the information to link inputs and outputs for one DarkSend mix. If I'm not mistaken, this does not protect against a sybil attack.

If the attacker is acting as a continuous 'liquidity provider' with, say 3 wallets, he could still fully back out an 8 round DarkSend mix with just you. The outputs that don't come back to his wallets are yours. Right?

Yes, if he's the only one on the network that's mixing other than you. That's got to be pretty unlikely for a full 8 round Darksend. But you raise a good point! Impossible is way better than unlikely.

The system does not mix with the same partners through several rounds so I dont think this would apply to Darksend.

One has to assume all incoming mixing partners are potentially malicious. My original point is that when you have N inputs from a sybil attacker and 1 input from yourself, the sybil attacker knows your inputs and outputs. It shouldn't matter if it's CoinJoin or DarkSend. The new mixing partners can simply be more DarkSend mixes from wallets controlled by the attacker running in round robin fashion. However, once we have N inputs from a sybil attacker and 2 inputs from two trusted parties, then the sybil attacker cannot ascertain the trusted parties' inputs and outputs. By having two sets of mixes that you trust are not malicious, you suddenly have an effective countermeasure against the sybil attack. In the world of crypto you can't trust anyone but yourself, so why not let the trusted parties be two separate mixes from your wallet?