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..."