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

[Minotaur26]

The quantity going in and out of the mix is still obvious. Maybe it can't be tied to me with IP obfuscation, but block timing will still give away too much info

Do you mean that the nature of the transaction could be identified simply from the amount being transacted ?

An outside observer will have no idea whatsoever of the amount being transacted, because ALL transactions will use denominated amounts. It's just one big sea of zero useful information.

That doesn't appear to be true from where I am standing.

If I am standing in the wrong place, help me relocate.

The ones that could help you relocate I think would be Evan and team, this is a very recent announcement the other posters don’t have enough information to address your concerns.  I guess we will have to wait a bit but you are asking interesting questions I am taking notes for future reference.

[1715198869]

1715198869

[1715198869]

1715198869

[1715198869]

1715198869

[1715198869]

1715198869

[thelonecrouton]

The quantity going in and out of the mix is still obvious. Maybe it can't be tied to me with IP obfuscation, but block timing will still give away too much info

Do you mean that the nature of the transaction could be identified simply from the amount being transacted ?

An outside observer will have no idea whatsoever of the amount being transacted, because ALL transactions will use denominated amounts. It's just one big sea of zero useful information.

That doesn't appear to be true from where I am standing.

If I am standing in the wrong place, help me relocate.

In your previous post you said, "There's too much information." Sure, there's all the information you can shake a stick at and it all looks exactly the same. You can see a bunch of denominated amounts shifting about but there's no way of knowing which particular chunk belongs to which particular transaction.

No way to know how much was sent, how much was received, except for the parties concerned. Any observer is presented with a whole load of identical fuck-all happening between a bunch of zero-history addresses. 

[hartvercoint]

I don't think IP obfuscation should be of concern right now. It is near trivial to do by either using Tor/I2P themselves or by propagating transactions using a Tor-like onion-routing via the masternode network. Which means that only masternodes will propagate transactions.

I'd actually like the latter quite a lot. I'll think about it some more.

[camosoul]

The quantity going in and out of the mix is still obvious. Maybe it can't be tied to me with IP obfuscation, but block timing will still give away too much info

Do you mean that the nature of the transaction could be identified simply from the amount being transacted ?

I'm saying that the send can be correlated to the receive. The nature of it, who knows.

I'm saying that it's too much information. The blockchain is still transparent, and always should be. Information always adds up. Put as little correlative data out there as possible. The same script that correlates BTC could still correlate DRK.

It's less information, but it's still enough for a 3rd party to gather that A sent X to B.

You won't be able to tell that the change addresses from which A sends belong to A. So you'll see that B received X coins, but there's no way to link A and B.

This is a complicated argument to describe...

Lets back up just a little.

Lets pretend that MNs have IP obfuscation already implemented.

They still have identifiable signatures on the blockchain.

MNs will show up on the blockchain many orders of magnitude more often than non-MN clients. It's a blockchain-based form of traffic analysis. We can tell the difference between clients and MNs by this alone and it's REALLY obvious.

So, it will be clear to tell when the send is an MN and when it is not. Also, by the even more obvious fact that MNs just sign, they don't send/receive... (I was showing how IP obfuscation won't have any impact) So, even pre-denominated, pre-mixed coin quantity can be identified on block on which the TX is initiated: A. And, since it all pays out on one TX as well, it exits the fog on 1 block: B. Since A and B are obviously NOT MNs, A sent X to B. Just look at it backwards. Start with B and check the chain history of all non-MN traffic-level signature, poof, you find the input that matches.

Basically, we don't know that A is A, until wee see B, and it's the same as A, and there's a bunch of signatures in between, but no actual TX.... A sent X to B. Now, we still don't know who A and B are, but if they goof up just one time in their entire lives... Just like BTC's chain. amirite?

It's essentially the same qty/timing attack that exists on current BTC-forked blockchains. It just shifts from one metric to another.

Maybe I'll just ahve to wait for someone else to relocate me, that's just how it looks from here.

[maese123]

Great to hear another update from the darkcoin team!

Development on RC4 is nearing an end and we expect that we’ll be firing up testnet in the coming week. Depending on what we find, testing and QA should take 2 to 4 weeks.

I'm all for taking the time needed to do it right, but, ugh.  Does that mean no RC4 in late July as originally planned, then?  Don't know how much more of this price slide I can stomach.

i´m afraid so

[conf]

Hi
One more time thx for the cheap coins!
Have a nice day

[GhostPlayer]

I don't believe you. Link ?

I think it's this...

https://www.youtube.com/watch?v=ohiCNDT7W08

Start 16:00

Maybe evolution ;(

LIAR LIAR PANTS ON FIRE !!  

minute 14:00 !!

[luigi1111]

The quantity going in and out of the mix is still obvious. Maybe it can't be tied to me with IP obfuscation, but block timing will still give away too much info

Do you mean that the nature of the transaction could be identified simply from the amount being transacted ?

An outside observer will have no idea whatsoever of the amount being transacted, because ALL transactions will use denominated amounts. It's just one big sea of zero useful information.

That doesn't appear to be true from where I am standing.

If I am standing in the wrong place, help me relocate.

It seems you're missing the critical piece of the puzzle: the mixing. Multiple random-sized inputs go in, in multiple stages; denominated, homogeneous outputs come out at various stages. If you're not missing that, then your analysis does indeed apply, but only in cases of people mixing everything then sending the whole chunk back to some other address. Why would you do that? What would it accomplish?

[thelonecrouton]

MNs will show up on the blockchain many orders of magnitude more often than non-MN clients. It's a blockchain-based form of traffic analysis. We can tell the difference between clients and MNs by this alone and it's REALLY obvious.

Not necessarily. When RC4 hits, there's going to be a frenzy of MN activity as everyone's balances get randomly denominated. After that, my gut instinct is that with increased actual use, the MN tx's aren't going to stand out at all amongst 'real' transactions.

[camosoul]

The quantity going in and out of the mix is still obvious. Maybe it can't be tied to me with IP obfuscation, but block timing will still give away too much info

Do you mean that the nature of the transaction could be identified simply from the amount being transacted ?

An outside observer will have no idea whatsoever of the amount being transacted, because ALL transactions will use denominated amounts. It's just one big sea of zero useful information.

That doesn't appear to be true from where I am standing.

If I am standing in the wrong place, help me relocate.

It seems you're missing the critical piece of the puzzle: the mixing. Multiple random-sized inputs go in, in multiple stages; denominated, homogeneous outputs come out at various stages. If you're not missing that, then your analysis does indeed apply, but only in cases of people mixing everything then sending the whole chunk back to some other address. Why would you do that? What would it accomplish?

Point valid.

BUT!

They don't happen at random intervals. They happen all at once. So, the overall quantity can be correlated by sig. It's as if entry-point sends aren't denominated at all, even if they are. It still correlates.

If 1, 5 and 10 go in at J, then 1, 5, and 10, come out at P, and 1, 5 and 10 are signed by the same key at J, and end up at the same place at P... X = 1+5+10 A sent X to B on block J and P.

Same analysis, you just have to build it backwards. Backwards or forwards doesn't matter when the chain is documented for all eternity.

I await big cheese response.

I want to be clear. I am not trying to troll or say "DRK iz brokenZ! Abadon ship!" Or any other such bullshit. I know that it is a work in progress, I'm just trying to figure out where the progress needs to be... If I'm way the fuck off, by all means, I crave the Pimp Hand of Truth.

[luigi1111]

MNs will show up on the blockchain many orders of magnitude more often than non-MN clients. It's a blockchain-based form of traffic analysis. We can tell the difference between clients and MNs by this alone and it's REALLY obvious.

Not necessarily. When RC4 hits, there's going to be a frenzy of MN activity as everyone's balances get randomly denominated. After that, my gut instinct is that with increased actual use, the MN tx's aren't going to stand out at all amongst 'real' transactions.

They're still going to be fundamentally different TX types: denominating transactions, versus combining (multiple inputs) transactions. The point is it doesn't matter.

As I mentioned above, if you have, say, 27.000 DRK (27 DRK exactly, comma users), and you denominate it into whatever, and if you later recombine all your denominated addresses (via multiple input) to send 27 DRK to someone else (or even yourself), there exists a *suggestive* link between the original denomination TX and the new sending TX. It's not mathematical proof or anything, though.

[chaeplin]

DarkSend+

Over the last week or two, Darksend+ has made some significant advances. We’re happy to say that we’re closing in on a finished product.

We've opted to employ a strategy for Darksend+ that is slightly different than the one we outlined in our last update. This new strategy has several advantages, and we think it is a significant improvement over the previous iteration in terms of both privacy and efficiency. The Darkcoin client will now store pre-mixed, denominated Darkcoins in the user’s wallet, to be used instantly at any time the user desires. The mixing and denomination process is seamless, automatic, and requires no intervention on the part of the user. The 10 DRK limit previously in place with Darksend v1 will be permanently removed. With RC4, the amount that users can send via Darksend+ is limited only by the available balance in their wallet.

Here's how it works:

Every 10 blocks, user clients network-wide will send any unmixed, traceable Darkcoins in their possession through an anonymization phase. In this phase, Masternodes are used in chained succession to mix the coins they receive from the network and break them down into homogenous denominations. After being processed by a minimum of 2 Masternodes, the coins are either sent to the next Masternode in the chain or back to the user’s wallet at randomly generated change addresses.

Depending on the desired depth of security and privacy, users may select between 2 and 8 “hops” to successive Masternodes before their coins are sent back to the client. Hops are made every 10 blocks, so anonymization at a depth of 2 hops will take 10*2*2.5=50 minutes, 3 hops 10*3*2.5=75 minutes, and so on. The desired mixing depth can be selected in the client GUI.

At the end of the anonymization phase, the user’s coins are returned to their client at randomly generated change addresses. When the user wishes to make a transaction, the client forwards the intended amount from these anonymous change addresses directly to the intended receiver’s address. There is no direct involvement of of Masternodes in the final person-to-person transaction.

Proof of payment will work as it always has: a user can see the send transaction with the receiver’s address in their own wallet, and the blockchain will show that the receiver’s address received an input in the corresponding amount.

[camosoul]

MNs will show up on the blockchain many orders of magnitude more often than non-MN clients. It's a blockchain-based form of traffic analysis. We can tell the difference between clients and MNs by this alone and it's REALLY obvious.

Not necessarily. When RC4 hits, there's going to be a frenzy of MN activity as everyone's balances get randomly denominated. After that, my gut instinct is that with increased actual use, the MN tx's aren't going to stand out at all amongst 'real' transactions.

They're still going to be fundamentally different TX types: denominating transactions, versus combining (multiple inputs) transactions. The point is it doesn't matter.

As I mentioned above, if you have, say, 27.000 DRK (27 DRK exactly, comma users), and you denominate it into whatever, and if you later recombine all your denominated addresses (via multiple input) to send 27 DRK to someone else (or even yourself), there exists a *suggestive* link between the original denomination TX and the new sending TX. It's not mathematical proof or anything, though.

This is very close to what I'm trying to explain.

It doesn't absolutely PROVE anything, but it lets the nosy fuckers in on a hint that might find them something more... As such, it's not really helping anything...

The banking laws for the EU have already been changed to declare deposits in savings are not actually your's anymore. If you're hiding your money in DRK, they can claim you've stolen your own money... Ask a Cypriot how that works out... Oh, you didn't notice that the entire European Union has quietly adopted that which Cyprus didn't quite get away with? All they need is a "suggestive link," that's what guvthugs call a "lead." It's not proof, but now they're all over you like a bad suit, and they don't even have to find anything. If they hate you enough, they'll just make shit up. You'll be yet another faux child pornographer locked away, you dirty pervert! If those addresses ever budge, they'll know who...

I'm trying to demonstrate that this is a very good move by Evan, but it doesn't go far enough... I also might not understand it accurately and I await the Pimp Hand of Truth by one who actually wields it.

[DogTheHunter]

At the end of the anonymization phase, the user’s coins are returned to their client at randomly generated change addresses. When the user wishes to make a transaction, the client forwards the intended amount from these anonymous change addresses directly to the intended receiver’s address. There is no direct involvement of of Masternodes in the final person-to-person transaction.

One time disposable addresses?

[luigi1111]

The quantity going in and out of the mix is still obvious. Maybe it can't be tied to me with IP obfuscation, but block timing will still give away too much info

Do you mean that the nature of the transaction could be identified simply from the amount being transacted ?

An outside observer will have no idea whatsoever of the amount being transacted, because ALL transactions will use denominated amounts. It's just one big sea of zero useful information.

That doesn't appear to be true from where I am standing.

If I am standing in the wrong place, help me relocate.

It seems you're missing the critical piece of the puzzle: the mixing. Multiple random-sized inputs go in, in multiple stages; denominated, homogeneous outputs come out at various stages. If you're not missing that, then your analysis does indeed apply, but only in cases of people mixing everything then sending the whole chunk back to some other address. Why would you do that? What would it accomplish?

Point valid.

BUT!

They don't happen at random intervals. They happen all at once. But they don't happen all at once; mixing occurs over more than one round, and inputs don't all occur at round 1. Your inputs might begin at round 1 (in the graphic), while Joe's inputs might start at 2, and Sally's at 3, and so forth. So, the overall quantity can be correlated by sig. It's as if entry-point sends aren't denominated at all, even if they are. It still correlates.

If 1, 5 and 10 go in at J, then 1, 5, and 10, come out at P, and 1, 5 and 10 are signed by the same key at J, and end up at the same place at P... X = 1+5+10 A sent X to B on block J and P.
Somehow, we're not quite on the same page here.   (IMO) you might need to reword and flesh out clearly and exactly what you're saying, as it seems to be one of those things that seems clear in your head, but isn't translating that well to paper.
Same analysis, you just have to build it backwards. Backwards or forwards doesn't matter when the chain is documented for all eternity.

I await big cheese response.

I want to be clear. I am not trying to troll or say "DRK iz brokenZ! Abadon ship!" Or any other such bullshit. I know that it is a work in progress, I'm just trying to figure out where the progress needs to be... If I'm way the fuck off, by all means, I crave the Pimp Hand of Truth.

To your last point, we're on the same page there.

[camosoul]

At the end of the anonymization phase, the user’s coins are returned to their client at randomly generated change addresses. When the user wishes to make a transaction, the client forwards the intended amount from these anonymous change addresses directly to the intended receiver’s address. There is no direct involvement of of Masternodes in the final person-to-person transaction.

One time disposable addresses?

All addresses are permanent. Whether you chose to use it twice is up to you...

[luigi1111]

MNs will show up on the blockchain many orders of magnitude more often than non-MN clients. It's a blockchain-based form of traffic analysis. We can tell the difference between clients and MNs by this alone and it's REALLY obvious.

Not necessarily. When RC4 hits, there's going to be a frenzy of MN activity as everyone's balances get randomly denominated. After that, my gut instinct is that with increased actual use, the MN tx's aren't going to stand out at all amongst 'real' transactions.

They're still going to be fundamentally different TX types: denominating transactions, versus combining (multiple inputs) transactions. The point is it doesn't matter.

As I mentioned above, if you have, say, 27.000 DRK (27 DRK exactly, comma users), and you denominate it into whatever, and if you later recombine all your denominated addresses (via multiple input) to send 27 DRK to someone else (or even yourself), there exists a *suggestive* link between the original denomination TX and the new sending TX. It's not mathematical proof or anything, though.

This is very close to what I'm trying to explain.

It doesn't absolutely PROVE anything, but it lets the nosy fuckers in on a hint that might find them something more... As such, it's not really helping anything...

The banking laws for the EU have already been changed to declare deposits in savings are not actually your's anymore. If you're hiding your money in DRK, they can claim you've stolen your own money... Ask a Cypriot how that works out... Oh, you didn't notice that the entire European Union has quietly adopted that which Cyprus didn't quite get away with? All they need is a "suggestive link," that's what guvthugs call a "lead." It's not proof, but now they're all over you like a bad suit, and they don't even have to find anything. If they hate you enough, they'll just make shit up. You'll be yet another faux child pornographer locked away, you dirty pervert! If those addresses ever budge, they'll know who...

I'm trying to demonstrate that this is a very good move by Evan, but it doesn't go far enough... I also might not understand it accurately and I await the Pimp Hand of Truth by one who actually wields it.

Just one point about this: sending your *full* balance anonymously has always been a problem (unless your full balance happens to be a denomination size (good luck)). It's not a problem that is easy to fix in a transparent blockchain model. I'm not sure it even can be fixed, but would love to read a solution to it.

[hartvercoint]

Since A and B are obviously NOT MNs, A sent X to B.

I don't see the problem here. A sent X to B. So what?
Imho what's important to achieve is that B doesn't know who A is, nor how much money A possesses or where X came from. And that's done with what Evan described.

My idea for IP obfuscation and protecting against timing attacks would be:

Every MN has an SSL keypair. A wants to send coins and signs a transaction at block height 100. The signed transaction is encrypted with MN1's pub key and a future block height (say 104). The encrypted block and a not-as-far in the future block height (say 102) are encrypted with MN2's pub key.

The encrypted block is now broadcast into the network. MN2 decrypts the message. It waits for block 102 to be found and then broadcasts the inner encrypted block (containing the signed tx). MN1 will receive that block and decrypt it to get ahold of the signed tx. It knows it is to wait until block 104 was found and then broadcasts the actual transaction into the network. MN1 has no idea where the tx originally came from, nor when it was sent, while MN2 doesn't know the transaction at all.

This is very similar to the Tor concept and could of course chain more than 2 MN's. Because every node involved holds the transaction back until a certain block was found, timing attacks become impossible.

The "future block heights" could be user's choice or randomly generated within a fixed or user-chosen range.

[chaeplin]

DarkSend+

Over the last week or two, Darksend+ has made some significant advances. We’re happy to say that we’re closing in on a finished product.

We've opted to employ a strategy for Darksend+ that is slightly different than the one we outlined in our last update. This new strategy has several advantages, and we think it is a significant improvement over the previous iteration in terms of both privacy and efficiency. The Darkcoin client will now store pre-mixed, denominated Darkcoins in the user’s wallet, to be used instantly at any time the user desires. The mixing and denomination process is seamless, automatic, and requires no intervention on the part of the user. The 10 DRK limit previously in place with Darksend v1 will be permanently removed. With RC4, the amount that users can send via Darksend+ is limited only by the available balance in their wallet.

Here's how it works:

Every 10 blocks, user clients network-wide will send any unmixed, traceable Darkcoins in their possession through an anonymization phase. In this phase, Masternodes are used in chained succession to mix the coins they receive from the network and break them down into homogenous denominations. After being processed by a minimum of 2 Masternodes, the coins are either sent to the next Masternode in the chain or back to the user’s wallet at randomly generated change addresses.

Depending on the desired depth of security and privacy, users may select between 2 and 8 “hops” to successive Masternodes before their coins are sent back to the client. Hops are made every 10 blocks, so anonymization at a depth of 2 hops will take 10*2*2.5=50 minutes, 3 hops 10*3*2.5=75 minutes, and so on. The desired mixing depth can be selected in the client GUI.

At the end of the anonymization phase, the user’s coins are returned to their client at randomly generated change addresses. When the user wishes to make a transaction, the client forwards the intended amount from these anonymous change addresses directly to the intended receiver’s address. There is no direct involvement of of Masternodes in the final person-to-person transaction.

Proof of payment will work as it always has: a user can see the send transaction with the receiver’s address in their own wallet, and the blockchain will show that the receiver’s address received an input in the corresponding amount.

Hops are made every 10 blocks, so anonymization at a depth of 2 hops will take 10*2*2.5=50 minutes, 3 hops 10*3*2.5=75 minutes, and so on.

I have understand this as following..
Every 10 blocks(25 min, block height (1), 11, 21, 31, 41, 51....)

[HinnomTX]

MNs will show up on the blockchain many orders of magnitude more often than non-MN clients. It's a blockchain-based form of traffic analysis. We can tell the difference between clients and MNs by this alone and it's REALLY obvious.

Not necessarily. When RC4 hits, there's going to be a frenzy of MN activity as everyone's balances get randomly denominated. After that, my gut instinct is that with increased actual use, the MN tx's aren't going to stand out at all amongst 'real' transactions.

They're still going to be fundamentally different TX types: denominating transactions, versus combining (multiple inputs) transactions. The point is it doesn't matter.

As I mentioned above, if you have, say, 27.000 DRK (27 DRK exactly, comma users), and you denominate it into whatever, and if you later recombine all your denominated addresses (via multiple input) to send 27 DRK to someone else (or even yourself), there exists a *suggestive* link between the original denomination TX and the new sending TX. It's not mathematical proof or anything, though.

You've latched onto a trivialized case of Darksend+. The laundered amount and the transaction amount do not normally match! The only way they would match is if you laundered your wallet of 27 DRK and then emptied all the denominated addresses totally to a new address to pay for something costing 27 DRK. That's not how it will work in practical terms. You'll launder 27 coins and then send 12 of them to pay for something that costs 12 DRK. Now there's no suggestive link between laundering and transaction amount. These events also occur at different points in time (and for the laundering part, you can mix your coins 2 to 8 times over).