Darksend technical diskussion - anonymity, liquidity, improvements

[Stealth923]

There's no way to guarantee anything. I guess that's the only catch. As we get bigger, this shouldn't be a problem. There should be liquidity.

Yep agreed - chicken and egg thing....

After thinking about it a little more I definitely agree this is the best way to go.

Thanks Evan!

 

[darkwing]

This is why a darksend session might be better than a subscription. You get what you pay for. How long it takes depends on how many rounds you've set/liquidity but as long as you don't close the session it runs until done?

 

[eduffield]

This is why a darksend session might be better than a subscription. You get what you pay for. How long it takes depends on how many rounds you've set/liquidity but as long as you don't close the session it runs until done?

Fees per round isn't possible, unless it's in the transaction. How does the user prove he didn't get 8 rounds?

 

[darkwing]

Fees per round isn't possible, unless it's in the transaction. How does the user prove he didn't get 8 rounds?

I meant 1 fee to denominate.. not fee per round. So pay a fee to denominate choose how many rounds (this doesn't affect the fee, just how long it takes) and press go.

1 fee for the session.

A separate idea: would routing the fee via a stealth address help?

 

[Dr.Crypto]

How about porting stealth addresses (SX) from vertcoin's recently open-sourced code and combine them with Darksend? Two results:
1/ impossibility to trace back the coins to the source, so no reason to run rogue liquidity providers to gain information by monitoring DS transactions
2/ possibility to lower the DS fees or completely remove them if desired as sybil attacks are rendered impossible

 

[coingun]

I personally love the idea of a pay for access type system.

This would scale really well to other (potential) services that could be run by the masternodes. Want to mix some darkcoins? Pay for the time to mix them. Want to use DPN? Pay for the time you need your routes in place. Want to sync the blockchain faster? Pay to sync from the MN network.

This scales really well and would definitely be useful in the future with other services that became "paid for".

Aside: I really love all the constructive criticism in this thread. This community is really growing up fast!

 

[moli]

Fees per round isn't possible, unless it's in the transaction. How does the user prove he didn't get 8 rounds?

The user can see from the Coin Control how many rounds he's got, and that info should be enough, right?

 

[crowning]

I'm thinking the user will pay for Darksend access for a period of time. For example, you do one transaction for 0.1 to the Darksend access address, this is the very first thing you do when Darksend starts. Then you send that transaction ID, and a signature proving you own the input. That gives you access to darksend for 1 day or something.

So for ONE single fee I'll be able to SPAM the Masternodes with Darksend mixing requests for 24 hours?

 

[JGCMiner]

So for ONE single fee I'll be able to SPAM the Masternodes with Darksend mixing requests for 24 hours?

This has changed. Here is the current idea (from Evan on BCT):

"Solution 3:
Pay per round of Darksend, in a separate transaction, paid directly to the miners as a fee. The masternodes would hold on to them and publish them later on. To double spend attack this, you would need to pay the miners more fees, so it's impossible to double spend against and it's timing attack resistant. "

Link:
https://bitcointalk.org/index.php?topic=421615.msg9503956#msg9503956

 

[crowning]

This has changed. Here is the current idea (from Evan on BCT):

"Solution 3:
Pay per round of Darksend, in a separate transaction, paid directly to the miners as a fee. The masternodes would hold on to them and publish them later on. To double spend attack this, you would need to pay the miners more fees, so it's impossible to double spend against and it's timing attack resistant. "

Link:
https://bitcointalk.org/index.php?topic=421615.msg9503956#msg9503956

Ah, thanks, these days I rarely read bitcointalk.org because it causes brain-cancer.

Solution 3 is similar to what I was thinking. Not 100% sure why the extra step to pay the miners is needed (IMO it would be sufficient to add the paid fee to the next Masternode payment as a bonus).

 

[Aswan]

Hello Aswan,

This is some great feedback, you've shown you really know your way around the protocol. It's great to get feedback, even if it's showing flaws in the system. I'll address these in the next release. But in the meantime, here's some thoughts:

Thanks! I followed darkcoin closely when it first came out and even tho I don't have a huge stack of DRK, I am more than willing to share my thoughts and ideas about how to improve DRKs features, especially the ones related to anonymity.

Problem #1:

Darksend makes the transaction fees in batches, which usually don't have enough fee inputs to get a user all the way through the process. So at some point during the process the chain usually be broken. However, the issue still remains and darksend needs a fee mixing phase. That should at least be very fast because all of the inputs are one size.

I have read the thread and there have been different suggestions on how to fix this fee problem. I kinda like the one with a miners fee being paid for each round, which then acts as a proof of payment to the masternode.
I imagine this proof proof of payment is a transaction ID which is signed with the address to proof ownership (if it wouldn't be signed everyone could claim it's his).
The problem I see here is that the masternode knows who paid the fee even though this information is not publicly available. A malicious masternode could therefore weaken the mixing process and in the case of it being the masternode of the last round of Darksend, if could even break the anonymizatio. This process is still better than the one with the fee included in the Tx, because it would prevent de-anonymization through blockchain analysis, but the masternode owner could still use the information the same way as in my described problem #1.

The other solution of doing a single round of fee mixing only provides exactly that. A single round of mixing and therefore a single masternode can break the anonymization. It's not an option here.

What I want to suggest is a modified version of my initial suggestion:

There could be an additional denomination size representing the fee. For conformities sake, this could be a 0.01000001 denomination, which is included into the darksend process as usual.
However, instead of it just being mixed, it can be used to pay the fee. So if you have 3 x 0.01000001 denominations, you'd only have 2 left after a round of dark send because the other one has been used as a fee.
As stated above, the chain will eventually have to be broken,but it does not have to happen within 8 rounds. there could be always at least 8x 0.01000001 denominations created when starting darksend. the only downside I see here is that for each transaction, it is known how many rounds are left because of the amount of 0.01000001 denominations. But this it only the combined rounds of all 3 participants and not an anonymity issue imo.
Still this could be prevented by always generating a random amount of 0.01000001 denominations between 8 and 15. That way, there is no way to know how many darksend rounds are to come.
Why up to 15? because then even the last round of darksend can have 7 of those denominations left (8 would overkill since there just was a darksend transaction using one fee, leaving potentially 7 more, which makes 8 and is the max. standard amount of darksend rounds users do).

This way, neither blockchain analysis nor a a malicious last masternode can break anonymity.
the downside would be that darksend transaction would increase in size, but the 0.01000001 denominations should be darksend compliant. One could argue about allowing up to 15 of them per participant or limiting them to 9 per participant (because then the next higher denomination would already be used).

What I can see being disastrous is the 1 day subscription idea with the signed proof of payment. This proof of payment can be just handed around. There could be a wallet which you can always mix for free with because "someone" paid the daily fee and the proof of payment gets distributed to all clients. Also this would enable attacks on the masternode network.

Liquidity providers mix random amounts each round already, so they will make good partners for stopping this type of tracking until #3 is done. E.g. they don't spend the whole previous round as the default client does.

I didn't know they did this but I think it's good practice to do so.

Problem #2:

I think the way it works is a pretty good mix of speed and lack of bloating. If we allowed inputs to be split up in the mixing phase like you say, you could split 100DRK into 10x10, or 10DRK into 10x1, that would cause a lot of bloating. I see this as being a problem with bootstrapping the currency. We just don't have enough active volume of Darksends to really speed up the process. There's really only a few mixes a day, it's went up recently, but it's still not very high. If we were doing hundreds a day, then it should just take an hour to complete.

In the future we actually shouldn't need liquidity providers. At that point we could increase the mixes to 4 or 5, which even makes the anonymity much more robust.

It's true that we probably don't need liquidity providers in the future. It was just a suggestion to get this whole thing started. Because of the few participants right now, a little bigger transactions wouldn't hurt and it would add liquidity.
It's a trade - chain size for liquidity. I just thought DRK could afford this right now and it would help a lot to get things rolling. It could be reverted later on when there is enough liquidity.
Anyway, it was just a thought about a feature, not a bug so no reason to jump on it like theres no alternative

Problem #3:

This is a great idea and I'll implement it in the next version. It should speed up mixing for everyone on the network. By using random amounts each time, we'll match with random denomination mixes, which will match with more users.

Well, it has to be made sure that all the coins are still sufficiently mixed. If one denomination is only mixed once while the others are mixed 5x+, that might be a problem.
Also, there would probably have to be more fees paid since there would be more mixing instances for every participant.
Thats why I said I haven't been able to wrap my head around the transaction fee thing in this case.

Aswan, The community would like to thank you. Got a donation address?

sure,
DRK: XnNazPB1fPS59P9CfEtZWtqcmDttFWNj7A
BTC: 1FGJjQHesURPnLWFEU1R5fZy8PdP7KBkEY
Thanks

+1

Thank you for that excellent analysis...

Thank you

 

[Ignition75]

Tip Sent - fcbd62abe082985f3d0a58a3d7a3012a740e287c163fe8e373cf3b42106091dc-000

 

[jpr]

Aswan you do know we need more devs, don't you?

 

[Raico]

Thanks for your contribution~
Glade we have you in the community

TX:8e78b8b86c8352678a8e92743471c7ceb3fa9f73cf2290ba6bc9abbf477c735c

 

[Aswan]

Tip Sent - fcbd62abe082985f3d0a58a3d7a3012a740e287c163fe8e373cf3b42106091dc-000

Thank you for the donation

Thanks for your contribution~
Glade we have you in the community

TX:8e78b8b86c8352678a8e92743471c7ceb3fa9f73cf2290ba6bc9abbf477c735c

Thank you as well.

And thanks to everyone else for the kind donations.

Aswan you do know we need more devs, don't you?

Well, I usually only code in php and related, but thank you for your trust. I will stick around and throw in some ideas though