Masternode private send mixing...

joezippy

Member
May 21, 2015
112
66
78
Hello,

I have been thinking on this for a couple days and was asked by @TroyDASH to pull this out of the #slack and post it here for discussion... So, here goes.... Happy discussing! :)

Problems:
(1) Private Send mixing in the QT wallet is slower than most would like.
(2) Only the QT wallet can support Private Send transactions at this time.
(3) The scalability of Private Send, depends on the number of mixing requests at a point in time.​

The discussion that followed, could prompt solutions:

Problem Section (1):
@kcolussi (aka me @joezippy) said...

What if you flag the trans as "mix", so when the MN receives the request; it could then forward the payment from a "private" pre-mixed address...

@TroyDASH :
"if there was a way to prove coins are privatesent then it would be possible to come up with a solution that doesnt even involve masternodes"​

@Macrochip :
"Well... ironically Masternodes could -while mixing the inputs they received from the mixing partners- flag the funds as "PS". But so could any other client. Would have to be a non-forgeable signature

The discussion lead to using the MN voting PrivKey to sign transactions as being sent "Privately"... Then the question of how secure private voting keys really are, based on DashCentral, hosting, etc.; new "transaction keys" were suggested; the scalability of this type of transaction signing was brought into question.

@TroyDASH :
"the thing is, the functionality already exists to obfuscate all of your transactions using privatesend. it's just a matter of how fast it can happen. there might be other ways of doing this and i wouldn't put this as a #1 priority"
Problem Section (2):
@kcolussi: "(If the flag were sent in the transaction) Then all wallets could implement the "flag" and send private transactions...."​

Problem Section (3):
@kcolussi: "It doesn't seem like it's (coin mixing) a function of the endpoint, but that is my opinion...."
The ability to scale, shouldn't depend on usage. Even sounds weird to me. :)

Other notes on the thread of relevance...


@kcolussi originally suggested functionality that would required a "hot-wallet" on the MN... After more discussion, all agreed it probably wasn't best and should be avoided. Comments follow:

@kcolussi: "The MN could keep a % of the collateral pre-mixed for any and all future transactions, knowing it's not desirable to have all transactions sent privately... "​

@TroyDASH said this... " i'm not sold on the idea at all because I don't see any way of getting around the masternode hot-wallet issue. Any solution would have to not have that problem, imo"

@Macrochip :
"I don't think having hackers constantly trying to steal Masternode funds is a good basis for a viable infrastructure (edited)"

@kcolussi:
"If you own the MN... I think it's like root.... ;)"​


@TroyDASH said at one point... "if there was a way to prove that a tx is privatesent, then someone could set up a market / smart contract where you can pay to receive privatesent funds from pre-mixed coins"

@TaoOfSatoshi said when asked what he thought of the idea...
"@kcolussi I would favor it, but it's a little above my pay grade..."
 
  • Like
Reactions: lynx

Vedran Yoweri

Active Member
Apr 29, 2015
334
152
113
I don't see a problem and i don't see a proposed solution, just a lot of blah blah. What's it you wanna achieve here?
If you propose that MN will hold mixed funds then i get it, you're Tone Vays. :cool:
 

joezippy

Member
May 21, 2015
112
66
78
I don't see a problem and i don't see a proposed solution, just a lot of blah blah. What's it you wanna achieve here?
If you propose that MN will hold mixed funds then i get it, you're Tone Vays. :cool:
So..... I want the "problem(s)" I see, solved...

1) I don't want to run the QT wallet for hours / days / weeks mixing my coins, all the while my coins are off my HW wallet.
2) I want to send "Private Send" transactions from a wallet other than my QT wallet... Like my hardware wallet direct, or jaxx, etc where I have shapeshift functionality. (one wallet)
3) I don't want to wait for others to mix my coins.

It's not up to me alone to come up w/ solutions... That's not how open source projects work... If you read the bla, bla, bla again ;) you'll see @TroyDASH and I were just thinking
that maybe... If the coins on the chain where flagged, as previously "Private Sent" then the MN could complete future "mix" flagged requested transaction, with those coins... Making
them "Private Send" auto-magically.... No mixing, not wallet dependent, not dependent on others.

Hope this helps... Clarify my bla, bla, bla... Cheers! :)

PS: How did you get that MN Owner / Operator badge on your profile... I like it, and want one! :cool:
 

Vedran Yoweri

Active Member
Apr 29, 2015
334
152
113
1) I don't want to run the QT wallet for hours / days / weeks mixing my coins, all the while my coins are off my HW wallet.
2) I want to send "Private Send" transactions from a wallet other than my QT wallet... Like my hardware wallet direct, or jaxx, etc where I have shapeshift functionality. (one wallet)
3) I don't want to wait for others to mix my coins.
Go buy monero.

PS: How did you get that MN Owner / Operator badge on your profile... I like it, and want one!
https://www.dash.org/forum/threads/how-to-get-masternode-operator-tag.14189/#post-121445

Barging in here, proposing changes to the core protocol, doesn't make me a fan.
 

joezippy

Member
May 21, 2015
112
66
78
@TroyDASH ... After sleeping on this one more night, I thought of this.... I'm not sure if it's applicable, because I don't know the codebase, but lend me your ear... :D

So once... I wanted to set a specific IP address that the JVM was returning, on a hosted server, in a J2EE container (don't laugh I'm old)... I couldn't control the JVM code, so I wrote
a Java Aspect to slice through all the running code in the JVM, thus returning the value I wanted...

What if... We were able to obfuscate the transaction details for a given address, not by changing the historical record on the chain (because that's not possible)... But by changing the
result when the value is 'read' from the chain... This maybe could be done, with some type of 'Private Send' address registry.....

So, flip the idea from obfuscating transaction on the 'write' to the 'read'... Now, obfuscation is possible for future and past transactions... So long as the address is flagged, as "private" and in the "address registry"....

Crazy... I know, but maybe their is a clue somewhere their and it's out of my head... Cheers!
 

TroyDASH

Well-known Member
Jul 31, 2015
1,251
794
183
I'm kind of hoping this turns into a more general discussion about PrivateSend mixing speed, and whether or not the concept of purchasing provably pre-mixed coins (whether from Masternodes or elsewhere) is valid.

I have no idea what you mean by differentiating between the 'write' and the 'read'?
 

joezippy

Member
May 21, 2015
112
66
78
I'm kind of hoping this turns into a more general discussion about PrivateSend mixing speed, and whether or not the concept of purchasing provably pre-mixed coins (whether from Masternodes or elsewhere) is valid.
Agree.... We can do better with PrivateSend... How and when is up to the community... I too just want to have the discussion... :)

I have no idea what you mean by differentiating between the 'write' and the 'read'?
So I might be way off base, but somewhere in the dApp lives a 'write' function and somewhere their lives a 'read'... If that is true... Maybe something like this could be done...

Code:
public read(addr) {
   // psAddressRegistry contains all address that are private 
   if (addr in psAddressReqistry) {
       addr.trans.obfuscate.sender()
       addr.trans.obfuscate.receiver()
   }
}

public write(addr) {
   addr.trans.do-what-you-do-today()
}
Hope this helps with my cryptic explanation... :D
 

t0dd

Active Member
Mar 21, 2016
150
132
103
keybase.io
Dash Address
XyxQq4qgp9B53QWQgSqSxJb4xddhzk5Zhh
Dedicated Mixers

Another thought -- How performant PrivateSend mixing is, is dependent on how many other folks are mixing, correct?

An idea (maybe a proposal): Can the infrastructure team maintain, say, 8 wallets (more?), with 1000 Dash each (is that enough? too much?) that never cease mixing? They would keep a liquid pool of entropy rolling through the masternodes ready for anyone that comes to mix, regardless of how many people are participating on the network.

How to fund it: You could just straight up propose the needed funds, or maybe estimate a safe number of unallocated proposal funds that would be never created, and propose that amount for the months needed to build up to enough Dash.

How to secure it: Multi-sig with a number of individuals? Add the confirmation safety-valve (withdrawal delay and notification) that evolution is going to bring to vaults? This would have to be thought through. Exchanges deal with this stuff all the time.

How to implement it: Would have to set dedicated wallets that never cease creating enough change addresses and never stop mixing. The current dashcore wallet can do this, right? And once funded, estimate the fees paid out over time and create proposals to periodically re-fund the wallets.

This would be an interesting work-around to the "solitary mixer" problem until masternodes better address privatesend in some distant future, and though it is a centralized service, the network is not "dependent" on it.

What say, y'all? I can't imagine I am the first person to think of this.

-t0dd
 
  • Like
Reactions: joezippy

dashmeister

New Member
Apr 10, 2017
12
1
3
43
Good idea. but if everybody always mixing with the same guys, is it then really untraceable?
 

t0dd

Active Member
Mar 21, 2016
150
132
103
keybase.io
Dash Address
XyxQq4qgp9B53QWQgSqSxJb4xddhzk5Zhh
Good idea. but if everybody always mixing with the same guys, is it then really untraceable?
All folks know is that those 8 wallets are adding to the pool. They don't know how many others were in the pool. Could be 0 ... could be 10,000.
 

joezippy

Member
May 21, 2015
112
66
78
Heck ya... "What say, y'all? I can't imagine I am the first person to think of this." You might be with regards to vaults and evo... @t0dd... ;)
 
Last edited:

dashmeister

New Member
Apr 10, 2017
12
1
3
43
"All folks know is that those 8 wallets are adding to the pool. They don't know how many others were in the pool. Could be 0 ... could be 10,000."
Yes, but if the number is 0 I think the mixing is not really untracable, because ist always the same 8 wallets, the same coins from the 8 wallets. At least I have to trust the owner of the 8 wallets that they are not logging the mixing
 

joezippy

Member
May 21, 2015
112
66
78
"All folks know is that those 8 wallets are adding to the pool. They don't know how many others were in the pool. Could be 0 ... could be 10,000."
Yes, but if the number is 0 I think the mixing is not really untracable, because ist always the same 8 wallets, the same coins from the 8 wallets. At least I have to trust the owner of the 8 wallets that they are not logging the mixing
I wonder if masternode host providers, would be willing to run the wallets for mixing... This would be a somewhat trusted source with a vested interest in the network.... If they dropped the service, they wouldn't be missed... Just a thought...
 

amanda_b_johnson

Well-known Member
Dec 22, 2015
176
599
153
"All folks know is that those 8 wallets are adding to the pool. They don't know how many others were in the pool. Could be 0 ... could be 10,000."
Yes, but if the number is 0 I think the mixing is not really untracable, because ist always the same 8 wallets, the same coins from the 8 wallets. At least I have to trust the owner of the 8 wallets that they are not logging the mixing
Client wallets cannot log mixing. Only the specific masternode performing that specific mixing session can log it. I believe @UdjinM6 can confirm this?

Maybe it is time to re-introduce the "liquidity providers" proposal to get faster mix times until we grow our userbase sufficiently?
 

dashmeister

New Member
Apr 10, 2017
12
1
3
43
I like the idea of "liquidity providers", but
1. Its not a solution for high amount mixing. Let's say I would like to mix 27.000 dash (I know it's a huge amount, but even a simple house in Auckland costs more), then 8 liquidity providers with1000 dash each are not making much difference.
2. I'm not an expert here, but if the mixing partners are always the same group of people, is the mixing then really untracable?
As I understand mixing now (I simplifying it):
I'm mixing 11 dahes: 10 went from me to B, 1 from me to C, and get 10 from D and 1 from E. But if B, C, D and E are liquidity providers, which always are the partner of mixing, I think a good blockchain analyse software can find this out? At least we have to trust the liquidity providers, that they delete all logs, all wallet addresses from their mixing.

Btw; I'm waiting now 7 hours for my 150 dash to get mixed and its still at 30 % only (see my other posting). I this speed it would take several months just to mix only 1 million us$.
 
Last edited:

joezippy

Member
May 21, 2015
112
66
78
Btw; I'm waiting now 10 hours for my 150 dash to get mixed and its still at 30 % only (see my other posting). I this speed it would take several months just to mix only 1 million us$.
@dashmeister I can't agree with all you said, because of my knowledge level... However, I agree with this, and as privacy is one of the main reasons DASH is the best.... Today. It's broke in my opinion... Which is why I started this thread.... Glad to see the dialog. Thanks to all who have commented!
 
  • Like
Reactions: dashmeister

UdjinM6

Official Dash Dev
Dash Core Team
Moderator
May 20, 2014
3,637
3,536
1,183
Client wallets cannot log mixing. Only the specific masternode performing that specific mixing session can log it. I believe @UdjinM6 can confirm this?
...
Yes, the mixing masternode sees the whole picture of one specific session and no single client can figure out who 2 others are. But if not so many users are mixing then few colluding clients can try to look for txes they have in common and try to follow the 3rd participant. If they are lucky enough they can even catch few rounds but, again, only if number of users is low. For interactive mixing protocols it's really crucial how many non-colluding users are mixing at some point of a time.