Dash v12.3 Release Announcement - available July 3rd
- Thread starter bob
- Start date
- Apr 8, 2014
- 1,971
- 1,339
- 1,283
Also, it's hard not to notice that the roadmap is pretty much out the window. Not merely the time frame, but the content of the releases... It doesn't even resemble the original notion.
While that in itself is pretty much expected and normal, the lack of explanation or description of the current path being completely missing is a bit concerning.
I know it's considered verboten to approach the ivory tower with even the most innocent of inquiries, but I'm going to do it anyway.
Hey guys, what's going on? What's 12.4 gonna do? What will change for MNs? When's it going to exist? What have you been doing with these devnet thingamajigs? How has it helped? What have you learned from it?
Of all the opportunities you've been handed, the current myopic market would be a great time to show up and be "Cryptocurrency for grown-ups." Just sayin'...
While that in itself is pretty much expected and normal, the lack of explanation or description of the current path being completely missing is a bit concerning.
I know it's considered verboten to approach the ivory tower with even the most innocent of inquiries, but I'm going to do it anyway.
Hey guys, what's going on? What's 12.4 gonna do? What will change for MNs? When's it going to exist? What have you been doing with these devnet thingamajigs? How has it helped? What have you learned from it?
Of all the opportunities you've been handed, the current myopic market would be a great time to show up and be "Cryptocurrency for grown-ups." Just sayin'...
Last edited:
There will be a new roadmap released to the community during the next quarterly call, which should be pretty soon. As i understand, the new roadmap will mostly be about milestones for both v.0.12.4 and v.0.13.0 (Dash Evolution). It will not be about specific dates.
Version 0.12.4 most important elements will most likely be Special Transactions, Deterministic Masternode Lists, and Simplified Verification of Masternode Lists (https://www.dashforcenews.com/dash-...asternode-lists-in-major-structural-overhaul/) , these are part of Dash new three DIPS. I think some of these DIPS already got introduced in v.0.12.3 but await further implementation in v.0.12.4
Also this pull request seems interesting (if it makes it into the developer branche) : https://github.com/dashpay/dash/pull/2140
Last edited:
Specific dates are less important than milestones.
It is very hard to aim for a goal, when the goal is undefined.
Milestones, yay!
Special Transactions?
That sorta resembles something I mentioned a long time ago...
I never saw a reason for IX to be so complicated.
If IX is just a "those VINs can't be used until X block depth," why can't it be as simple as paying a fee to have the network disallow VINs being re-used until X blocks? "Here's a dollar; see that TXID, forbid those VINs for 6 blocks!"
If you wanted to make it complicated, add a requirement that the Lock request is only valid if it contains a signature from one of the VINs, or the receiving address.
It's perfectly workable in this open-loop scenario, as far as I can tell. No need to the currently overly complicated closed-loop methodology.
@UdjinM6 once explained to me that this isn't how IX works. I know! I'm suggesting that this is how it should work, and apparently, could work.
It kinda-sorta looks like this thing you linked?
- - - - - - - - - - - - - - - - - - -
But, a Pink Elephant which has been in this very small room for a few years now... Dead Change solution Evan mentioned, uh, ~3 years ago?
- - - - - - - - - - - - - - - - - - -
Is it still a plan to DAPI the blockchainchain (making Proof of Chain part of Proof of Service)? It seems like an easy way to test an isolated subset of DAPI functionality by requiring something the MNs are already doing... Bandwidth increase.... But, not really adding much in the way of requirements, while having the major, huge, monumental user-facing demonstrable upgrade of all clients becoming trustless light clients. I mean, how long have blockchains been sitting on MNs? Oh, right, ever since MNs existed... Why not do this? Make it an optional feature on install, like using HD wallets. "Use DAPI for blockchain data (experimental), or download and maintain blockchain per legacy systems?" I see no reason why these couldn't operate in parallel. Kinda like how you did multi-session DS as an "experimental" feature that eventually became standard. If something goes wrong with it, just disable it and do things the old way... No big deal. You told them it was experimental... This is one of the most visible things DASH could be doing to demonstrate it's divergence from Legacy Cryptocurrency in a very noticeable way. You should be doing it.
I bring this up for the very important point that Governments have taken a big notice of crypto lately... Showing that DASH isn't just another Tulip game is important for more reasons than mere marketing and hype BS. This is the most visible way to demonstrate the DASH is trying to be real money, not a get-rich-quick game with petty excuses to pretend itself more than that. As you know from the ridiculous legal infrastructure you've had to implement, regulations are not exactly favorable to legitimate development. The longer you don't stand out from the crowd, the more solidified the fraudulent regulatory mess becomes. You're just another Tulip, why shouldn't you continue to be regulated like just another Tulip? This would be a great way to show that DASH is not just another Tulip, and it's just the tip of the iceberg...
Last edited:
Doube-tap
https://www.dash.org/forum/threads/12-1-testnet-testing-phase-two-ignition.10818/page-12#post-110493
https://www.dash.org/forum/threads/dead-change-an-anonymity-issue.3019/
Essentially, the dust left over from sending PS/DS funds, when re-lumped, prove same wallet source. It all goes downhill from there... If any single one of those is exposed, the whole thing is exposed. With people using DASH in a vacuum of steganographic understanding, it's very dangerous. There needs to be some way to handle it on behalf of clueless users, which is most users. Nobody wants to talk about it because it gives XMR ammo... Well, it's only ammo for XMR because it still hasn't been handled! So handle it instead of blaming people for bringing it up! It doen't take long for this dust to build up to dozens of DASH you don't dare touch, ever, for any reason.
This discussion occurred back in 2014. Instead of handling it, it's discouraged from discussion. If you've been running a wallet for 4 years, you've got a ton of DASH that you better not spend. If you don't understand why, never heard of this Dead Change problem, you've probably screwed yourself out of privacy and don't even know it. You think DASH is teh anonz and that's all there is to it... Nope!
Steganographic methods beat cryptographic methods; if managed properly.
DASH currently does not manage it for the user at all, much less properly. So, it is left to the users to manage it. But, the users don't even know its a problem. They don't even know this is a thing.
12.3 does make an effort to minimize taint, but it's pretty weak...
Last edited:
The community is very active in other places than just this forum. Virtually everyone on Discord is aware of what's planned for 12.4 and I'm sure codablock posted his article here, too:
https://blog.dash.org/introducing-deterministic-masternode-lists-daaa7c9bef34
Who's blaming you, Don Quijote? Quit daydreaming and take Jordan Peterson's advice: Start paying attention. Here is what "nobody wants to talk about", but not because of some imaginary ammo, but because the issue has been put to rest 3.5 years ago:
Current wallet implementations do handle the issue for the user and have been doing so for years, otherwise PrivateSend-transactions would've been exposed long ago and you know damn well that's the Holy Grail for trolls like the one you've just responded to. How come there is not a single instance of that happening if the issue is as pressing as you're portraying it? If your interpretation was correct there should be thousands of exposed PS-tx out there.
Where are they?
I think you missed my point. Combine that with artificially limiting the scope to fail to include precisely the point I was making...
There a lot of 0.00999999 and smaller still collecting.
What happens when you combine it all?
Every single one of those spent denoms is now known to be from the same wallet by virtue of observing the change being combined. That change couldn't be combined if it weren't all in the same wallet. How would it all get signed in the same TX if it weren't? This means that the risk of exposure is not limited to any given IX, but all of them. Any TX of any kind, DS or not, can expose the entire wallet. The matter is not the narrow "DS exposure" perspective, but the data mining option from what happens later on... How many DSes have been performed on wallet X? Nobody knows. Until the change from each one of them goes into a new VIN... Just watch the dust, and log the TXIDs for every TX that had denom inputs and change... The change points to the DS. Now months years later, how many? If you were sloppy on any one of them, now they all have your name on them...
I assume you're familiar with
getwalletinfo
followed by
sendtoaddress "Xstuffstuffstuff" exact.balance "" "" true false false
To empty a wallet leaving 0 duffs behind?
PART of the Dead Change problem was fixed.
Dead Change presents more than one problem. That one of those problems was fixed does not distract or rectify the others...
This is a client TX, not an MN.
Further; information which is withheld, or made very hard to find, or kept out of reach, disseminated only among certain chosen people, etc., no amount of "paying attention" will help. If discord is the only way to find out, you're excluding a lot of people. The forum is the lowest friction option available to most people, myself included. If the forums have become vestigial in favor of a more closed and policed system, which excludes people based on totally unrelated matters above and beyond the increased friction it already presents...
Last edited:
If I'm wrong, please show me how.
Right now, I'm looking at the blockchain and seeing exactly what I'm talking about.
Your contradiction looks like gaslighting and distraction tactics to me.
Perhaps it is because I am ignorant, as you previously suggested with a suggestion that didn't appear to pertain at all. Prove me wrong. Show me what I'm not understanding. I can't find it, though you say I should "pay attention." You have my 100% un-devided attention. I hate to be asking for fact welfare, I'm the first person to have a problem with that concept. But, if you're hiding these facts so well that even someone like me can't find them, someone needs to step up and put that information in a place it can be more easily found. This is not the challenge of a troll. I'd like to be wrong. If I'm not really seeing what I'm seeing, explain it to me.
If I have to be "that guy" then so be it. It's not like I'm a stranger to the role...
When you roll dust into a transaction, you associate every VIN from which that dust was derived. If that's not true, show me how. If it is true, why lie about it?
Let us also note that there are several other topics I raised, yet this is the only one garnering further discussion...
Right now, I'm looking at the blockchain and seeing exactly what I'm talking about.
Your contradiction looks like gaslighting and distraction tactics to me.
Perhaps it is because I am ignorant, as you previously suggested with a suggestion that didn't appear to pertain at all. Prove me wrong. Show me what I'm not understanding. I can't find it, though you say I should "pay attention." You have my 100% un-devided attention. I hate to be asking for fact welfare, I'm the first person to have a problem with that concept. But, if you're hiding these facts so well that even someone like me can't find them, someone needs to step up and put that information in a place it can be more easily found. This is not the challenge of a troll. I'd like to be wrong. If I'm not really seeing what I'm seeing, explain it to me.
If I have to be "that guy" then so be it. It's not like I'm a stranger to the role...
When you roll dust into a transaction, you associate every VIN from which that dust was derived. If that's not true, show me how. If it is true, why lie about it?
Let us also note that there are several other topics I raised, yet this is the only one garnering further discussion...
Last edited:
I'm neither trying to distract nor gaslight.
You brought up dead change and made the claim that Dash "does not manage it at all". You even claimed it's "discouraged from discussion" when it's not. How do I know? We're talking about it right now. Without coercion. To be precise no discouragement of any sort is happening on this forum, neither from Core nor from the mod team, because IMO it's way too tolerant for it's own good. But I digress.
I went through the trouble of browsing through ancient forum threads to deliver you evidence that the issues was indeed addressed, despite your claim to the contrary.
Because as far as I'm aware what you're describing is exactly the dead change issue. I see no "part" that was fixed. It was exactly fixed what you're talking about. Here's another time Evan addressed the issue
I went through even more trouble for you and looked through my personal Dash Core wallet from which I mixed a 3 digit amount of Dash a while ago. I've also spent some of those mixed funds and I looked at every single input and change I received. Not a single time does a "0.00999999" denomination or anything similar to it appear. I got many harmless 0.01000010 inputs as change indicating the issue to be successfully avoided.
So this is just one one data point from me personally, but as far as I can see you've ignored the very fix's existence and still claim it's a problem, when I just confirmed the fix to be effective from first hand research.
Can PrivateSend be improved? Obviously.
Is Dead Change still an issue after years of PS improvements? I haven't seen any evidence for that.
I'm ready to have my mind changed if you can present me recent evidence directly from the blockchain explaining how a PrivateSend tx resulted in the problem you've described.
You brought up dead change and made the claim that Dash "does not manage it at all". You even claimed it's "discouraged from discussion" when it's not. How do I know? We're talking about it right now. Without coercion. To be precise no discouragement of any sort is happening on this forum, neither from Core nor from the mod team, because IMO it's way too tolerant for it's own good. But I digress.
I went through the trouble of browsing through ancient forum threads to deliver you evidence that the issues was indeed addressed, despite your claim to the contrary.
Which one? And how many are there? Be precise.
Because as far as I'm aware what you're describing is exactly the dead change issue. I see no "part" that was fixed. It was exactly fixed what you're talking about. Here's another time Evan addressed the issue
I went through even more trouble for you and looked through my personal Dash Core wallet from which I mixed a 3 digit amount of Dash a while ago. I've also spent some of those mixed funds and I looked at every single input and change I received. Not a single time does a "0.00999999" denomination or anything similar to it appear. I got many harmless 0.01000010 inputs as change indicating the issue to be successfully avoided.
So this is just one one data point from me personally, but as far as I can see you've ignored the very fix's existence and still claim it's a problem, when I just confirmed the fix to be effective from first hand research.
Can PrivateSend be improved? Obviously.
Is Dead Change still an issue after years of PS improvements? I haven't seen any evidence for that.
I'm ready to have my mind changed if you can present me recent evidence directly from the blockchain explaining how a PrivateSend tx resulted in the problem you've described.
Preface, I reiterate and say the same thing a different way many times, because I'm trying to be explicit and ensure I'm communicating my point accurately.
Any conversation in the cryptosphere is already charged with hype/troll presumptions. Snowflakery doesn't help, either.
Can we just calm down and admit I've been here since DRKs were less than a penny and not trying to troll or feed trolls?
I'm looking at one of my wallets. I've made hundreds of DS TXes. Now, it's pretty rare that a TX comes out precisely matching the denominations. There is ALWAYS change.
I send 0.953487 DASH. 9x .1s get used, and 6x .01s get used. But, then there's change for one of those .01s, because only .003487 was actually needed.
(yes, I'm leaving out the fact that denoms are really 1.0001, etc. for simplicity)
Dozens of such transactions exist. All these .00xxxxxx change amounts add up. I've got several DASH that won't denominate and can't be mixed. So, I:
sendtoaddress "Xanaddressinanotherwalletoreventhesamewallet" exactcurrent.ballance "" "" true false false
Now all those bits of dust combine into one larger VIN that is big enough that it can be denominated and mixed. Most people think "problem solved!"
Notice, for obvious reasons, "true false true" is a combination which can never actually be used. Because Dead Change.
But... Every single one of those pieces of dust was tied to a denomination of 0.01 which was more than what the actual TX needed. That's why that dust/change exists to begin with. Now that they all got rolled into one VIN, this proves that all that dust/change was in the same wallet. You couldn't roll it into one TX unless this were true. This ALSO proves that those .01s from which the dust was derived, also all came from the same wallet. BUT, since each of those VINs were in the same TX with other denominations, it proves that every 10, 1, .1 and .01 in the same TX is in the same wallet. The original DS TXID has every denom for that TX in it. so, all the denomas are known because the TXID is known as a result of the change off of the original .01.
Even the denomination process leaves it's own change, which can/must be rolled in the same way if you ever expect to use it. But, this is to be expected. 436.54834651 does not divide evenly into 10, 1, .1 and .01. Just like pretty much every other TX ever...
So, yes, I've described the Dead Change problem to a T. How? By observing a transaction I made just now...
Not only do I not see how your logical explanation could detach this connectivity, the whole reason I'm bringing it up is because I'm looking at it with my own eyeballs right this moment... If it was fixed 3.5 years ago, why can I see it happening right now? This is why I bring up the "Why hasn't the Dead Change issue been fixed?" inquiry.
I did not bother to look for any statements of it being fixed, because I'm looking at it, so it obviously hasn't been fixed.
Why would I look for a statement regarding event X, when I can clearly observe that event X has not occurred, and that very observation is the reason for the inquiry?
Point to it on the chain? No thanks! Its already a security problem. I understand your perspective in wishing to see it, but due to the nature of it, we'll have to stick with this conversational model.
Go ahead and test it yourself. Mix up a DASH or two. Go crazy and make it 16 deep. Since this is a post-mix exposure, the depth doesn't matter.
Send some randomly sized DS TXes. Doesn't matter where. Same wallet, a different one, irrelevant.
There will be change off of those DS TXes. That change comes from one of the .01s being oversized. It has to be. It's inevitable. Every single one of those .01s is in the same TX as the 10s, 1s, and .1s, so this TXID ties everything in that TX to that bit of change. So far, it doesn't really matter. Everything in THAT TX is associated with THAT TX. This is normal. How could everything that's in the same TX not be associated? It's in the same TX, duh... But, it only takes one more thing to make it into a problem...
As long as it's just Dead Change, it doesn't matter.
But, when you get $4,000 worth of Dead Change piled up, you start to care about not being able to touch it...
A person who doesn't understand one more thing decides to stack all that Dead Change into a single VIN.
Poof. All that change is now in the same TXID. And all of the VINs that change came from have their own TXIDs, which are now proven to be of the same source. Every single one of those pre-existing DS transactions is now known to have been from the same wallet. Every single DS TX that this wallet has ever performed is now bundled up and tidy on the blockchain. Every DS had a TXID with a bit of dust, and all that dust is now linked together. So, if any single TX you've ever made has your name on it, every TX you've ever made has your name on it.
I don't see this unlinked or undone anywhere. Even if there is a claim of it being fixed, I'm looking at it with my own eyeballs, so... Claim irrelevant and obviously untrue. How could it be true when, 3.5 years later, I'm plainly observing it?
Tell me how I'm wrong. Please.
In other points of similar topic; DS mixing is stupid fast now. As soon as a block comes, bam, multi-session is finding triplets and hammering 10s, 1s, .1s, and .01s in rapid-fire succession. I don't think there's any more room for improvement there, it's 10/10. The only improvement I can see is altering it from 3 to 3 + N. N = however many more people show up, which is naturally entropic. Deliberately pause and wait for more. Sure, a fast block may bump it entirely, but that rare, and since it was a fast block, the very same proposed mix TX could just as well occur in the next block. Possibly allow repeats, too... But, that has some negative connotations, so, er...
Which is why I qualified my statement with the qualifier "appears."
Any conversation in the cryptosphere is already charged with hype/troll presumptions. Snowflakery doesn't help, either.
Can we just calm down and admit I've been here since DRKs were less than a penny and not trying to troll or feed trolls?
0.00999999 was just an example. What I'm referring to is any duffheap smaller than the smallest denomination.
I'm looking at one of my wallets. I've made hundreds of DS TXes. Now, it's pretty rare that a TX comes out precisely matching the denominations. There is ALWAYS change.
I send 0.953487 DASH. 9x .1s get used, and 6x .01s get used. But, then there's change for one of those .01s, because only .003487 was actually needed.
(yes, I'm leaving out the fact that denoms are really 1.0001, etc. for simplicity)
Dozens of such transactions exist. All these .00xxxxxx change amounts add up. I've got several DASH that won't denominate and can't be mixed. So, I:
sendtoaddress "Xanaddressinanotherwalletoreventhesamewallet" exactcurrent.ballance "" "" true false false
Now all those bits of dust combine into one larger VIN that is big enough that it can be denominated and mixed. Most people think "problem solved!"
Notice, for obvious reasons, "true false true" is a combination which can never actually be used. Because Dead Change.
But... Every single one of those pieces of dust was tied to a denomination of 0.01 which was more than what the actual TX needed. That's why that dust/change exists to begin with. Now that they all got rolled into one VIN, this proves that all that dust/change was in the same wallet. You couldn't roll it into one TX unless this were true. This ALSO proves that those .01s from which the dust was derived, also all came from the same wallet. BUT, since each of those VINs were in the same TX with other denominations, it proves that every 10, 1, .1 and .01 in the same TX is in the same wallet. The original DS TXID has every denom for that TX in it. so, all the denomas are known because the TXID is known as a result of the change off of the original .01.
Even the denomination process leaves it's own change, which can/must be rolled in the same way if you ever expect to use it. But, this is to be expected. 436.54834651 does not divide evenly into 10, 1, .1 and .01. Just like pretty much every other TX ever...
So, yes, I've described the Dead Change problem to a T. How? By observing a transaction I made just now...
Not only do I not see how your logical explanation could detach this connectivity, the whole reason I'm bringing it up is because I'm looking at it with my own eyeballs right this moment... If it was fixed 3.5 years ago, why can I see it happening right now? This is why I bring up the "Why hasn't the Dead Change issue been fixed?" inquiry.
I did not bother to look for any statements of it being fixed, because I'm looking at it, so it obviously hasn't been fixed.
Why would I look for a statement regarding event X, when I can clearly observe that event X has not occurred, and that very observation is the reason for the inquiry?
Point to it on the chain? No thanks! Its already a security problem. I understand your perspective in wishing to see it, but due to the nature of it, we'll have to stick with this conversational model.
Go ahead and test it yourself. Mix up a DASH or two. Go crazy and make it 16 deep. Since this is a post-mix exposure, the depth doesn't matter.
Send some randomly sized DS TXes. Doesn't matter where. Same wallet, a different one, irrelevant.
There will be change off of those DS TXes. That change comes from one of the .01s being oversized. It has to be. It's inevitable. Every single one of those .01s is in the same TX as the 10s, 1s, and .1s, so this TXID ties everything in that TX to that bit of change. So far, it doesn't really matter. Everything in THAT TX is associated with THAT TX. This is normal. How could everything that's in the same TX not be associated? It's in the same TX, duh... But, it only takes one more thing to make it into a problem...
As long as it's just Dead Change, it doesn't matter.
But, when you get $4,000 worth of Dead Change piled up, you start to care about not being able to touch it...
A person who doesn't understand one more thing decides to stack all that Dead Change into a single VIN.
Poof. All that change is now in the same TXID. And all of the VINs that change came from have their own TXIDs, which are now proven to be of the same source. Every single one of those pre-existing DS transactions is now known to have been from the same wallet. Every single DS TX that this wallet has ever performed is now bundled up and tidy on the blockchain. Every DS had a TXID with a bit of dust, and all that dust is now linked together. So, if any single TX you've ever made has your name on it, every TX you've ever made has your name on it.
I don't see this unlinked or undone anywhere. Even if there is a claim of it being fixed, I'm looking at it with my own eyeballs, so... Claim irrelevant and obviously untrue. How could it be true when, 3.5 years later, I'm plainly observing it?
Tell me how I'm wrong. Please.
In other points of similar topic; DS mixing is stupid fast now. As soon as a block comes, bam, multi-session is finding triplets and hammering 10s, 1s, .1s, and .01s in rapid-fire succession. I don't think there's any more room for improvement there, it's 10/10. The only improvement I can see is altering it from 3 to 3 + N. N = however many more people show up, which is naturally entropic. Deliberately pause and wait for more. Sure, a fast block may bump it entirely, but that rare, and since it was a fast block, the very same proposed mix TX could just as well occur in the next block. Possibly allow repeats, too... But, that has some negative connotations, so, er...
@camosoul
There is no change returned to you when you send a PrivateSend transaction, *ever*. If you try to send a transaction that does not break up perfectly into the denominations, what happens is the entire amount that is leftover is included in the transaction fee and there is no change. This has been the case for quite a while now.
If you are seeing any small 0.0099 bits in your wallet, they are probably the result of the change from the create denominations process. These small amounts are not connected to anonymized coins - they are connected to the addresses you started with and they are not in your PrivateSend balance.
There is no change returned to you when you send a PrivateSend transaction, *ever*. If you try to send a transaction that does not break up perfectly into the denominations, what happens is the entire amount that is leftover is included in the transaction fee and there is no change. This has been the case for quite a while now.
If you are seeing any small 0.0099 bits in your wallet, they are probably the result of the change from the create denominations process. These small amounts are not connected to anonymized coins - they are connected to the addresses you started with and they are not in your PrivateSend balance.
Last edited:
However- it is true that if you combine your final anonymized coins and the dust from the create denominations, then you've just botched things up. But in order to do this you would need to send a regular transaction, not a PrivateSend transaction - because the dust is never in your PrivateSend balance. Conceivably, if you do a regular tx and combine the create denominations dust with one of the final anonymized denominations, then you would be associating that non-private dust with the final denomination transaction, which I would imagine might severely weaken your privacy for other PrivateSend txs that you might have sent using vins from the same final denominate-tx (wouldn't it be like doing only one round of mixing?). I'd defer to @UdjinM6 to weigh in on this scenario.
Last edited:
Precisely my point when I said that
Code:
sendtoaddress "Xsomedashaddress" exactwallet.balance "" "" true false true
Code:
sendtoaddress "Xsomedashaddress" exactwallet.balance "" "" false false trueSo lets present this hypothetical scenario.
A MasterNode operator has, like, a shitload of MasterNodes. She gets about a dozen or more payments a day. Every single one of these payments hits her local wallet which is set to denominate.
That's a lot of Dead Change...
And as you confirmed, rolling it together would then prove that the same person owns all of those MasterNodes.
But, this isn't merely a problem for my hypothetical MNO. Such people probably don't even exist.........................................................................
Anyone receiving lots of small payments, say, pretty much any retail vendor... I know there's a neglect for the operative end of transactions, and only the snowflake matters, but...
Every sender was a recipient at some point. Where did you get your DASH? It came from somewhere... When you received it, it denominated, and you're going to have dead change. If it's not a whole lot, the same scenario still effects you. Poor people don't tend to like pennies going to waste. I know. I used to be poor and I still have this habit.
They're not going to call dust a loss... They're going to roll it into a big VIN so it doesn't go to waste. Even if it's just 1 duff on one change VIN. And they used DASH only once for one thing. And they're not going to know what just happened to their privacy because "The Dead Change Problem was fixed 3.5 years ago, pay attention! Oh, and Clean Your Room!(tm)(c)" All that mixing basically did nothing for that person and they don't know it.
Pointing out the problem is only the first step in doing something about it... Don't fail to do something about it by getting all triggered that some troll dared to bring up the issue... In the 12.3 ANN thread. Which is probably off topic, but I tried to bring it up elsewhere and never could get any traction. So, yeah, I stuck it here where someone might notice and take it seriously...
Last edited:
I hope you see what I'm talking about now. Its about the source of the Dead Change. Maybe the DS TX didn't outright "reveal" it, but the nature of the rest of this mess reveals it, and it doesn't matter the method that the change came to be.
Sure, DS didn't reveal it during the send. There were two holes in the dyke and you put your finger in one of them. DS "change" doesn't show up, but change still shows up from other places. And it's still an issue. And it's still Dead Change. And it can still bone you. And most people don't know it. And I don't know what, if anything can be done about that... So, I ask.
Maybe Shakespeare can explain it... A turd by any other name would stink so bad... Er, something like that...
Yes I do. To me it looks like you've inflated a mosquito into an elephant. Troy brought in the crucial information I completely forgot about: There is no change at all to be linked with. "But what about the dust elsewhere" is shifting the focus from the core problem that was shown not to exist.
Up until now you implied there would be PrivateSend dust. Now we've established it's just transparent dust that never touches your PrivateSend balance. Troy then theorized that mixing transparent dust with the PS balance would botch privacy, which is absolutely correct.
Here's the kicker though: That never happens.
Because neither the devs nor the wallet are stupid. PrivateSend balances and transparent balances are strictly and explicitly kept apart, that's why you have two balances shown after mixing. They never touch (which means it's also not gay).
The only way to force transparent dust and PS funds to touch is to privatesend coins to yourself, turning said coins transparent again, and then mix with the dust. That has no impact on privacy, because there is no privacy left to impact.
Last edited:
Ah, there you go, limiting the scope to avoid the issue...
I never said PrivateSend Change. I said Dead Change.
Dust still exists. Change still exists. Every incoming TX that doesn't denominate evenly.
Since the only way you can combone your dust is to do a non-PrivateSend TX, the Dead Change issue still exists. You put your finger in the Change from PrivateSend hole of the Dead Change problem, but you didn't plug up the problem I was talking about, as @TroyDASH points out here. Dead Change can come from other places, and it's not fixed.
This would clearly apply to any and all dust smaller than a denomination no matter how it is achieved.
And after thinking about it for a bit, I actually came up with a solution for it. Perhaps you can build upon this, or tell me why I'm stupid, but the basic premise seems like it would work...
I'd been toying the idea of a delayed PS mixing function that allowed a mix of 3 + N. Then I started thinking about the brilliant simplicity that got @UdjinM6 hired...
Since the "pile the change into a bigger VIN" problem can't be fixed by breaking it down, by definition, maybe it can be fixed by building it up?
What if a daily, weekly or monthly (or, in real terms, every 100 blocks, every 400 blocks, oer every 100 blocks, or better dynamically based on TX volume) "garbage collection" transaction was signed and created similar to the voting superblock?
Since the damning associations aren't made until the non-PrivateSend TX occurs, maybe EVERYONE could get together in one bigass TX? Sure, you just gave away associations...Or did you? Everyone was in it! Which one was whose? You'd need MN blinding or maybe a more robust onion routing for messaging... Essentially, you'd be making the same association as the original TX. You'd be giving away no more information than the original TX. To a 3rd party observer, it's nothing more than "Yup, that thing that happened certainly did happen."
That same mechanic could even facilitate the roll-forward notion for a rolling BlockChain instead of a perpetual one... Sort of. If built at protocol-level...
Normal PS mixing is all about speed. So, going the minimum 3, and going as fast as possible matters. This is why other possible modes of operation for PS are unacceptable. But, as Garbage Collection, other modes could work...
Feel free to tell me that there's no point to this, but I can clearly see a point to this.
At it's lowest form, "the dust problem" is still a thing and DASH isn't alone in having it. The only way to denominate a large collection of dust is to roll it into a bigger VIN. Even if it didn't do anything else, it still proves that all of those came from the same client. Maybe that's not catastrophic. Maybe that's not even bad. But it's still ungood. And it does seem fixable.
Perhaps I've generated my own distraction by calling it Dead Change. To me, that's exactly what it is...
Last edited:
...I continue to see a use of distraction tactics. I mention Dead Change is still a problem, everyone so far insists that DS TXes can't be de-pirvatized by it.
Sure.
Fine.
That's all well and good.
I honestly don't see it, but even if I concede the point.
It hasn't got anything to do with the topic I've brought up.
What about change/dust from all the other sources from which change/dust can come?
What if a person operates in micropayments? These never get denominated to begin with. They are dust. DS is not involved.
Change from denomination can come from a variety of inputs.
Non-DS VINs.
Payment from MNs are another thing. I brought that up first since it's the biggest deal... If you receive payments from multiple MNs (which by nature will not be DS), and each one goes into a wallet to be denominated, They make dust as they do it. This associates every MN as owned by the same person through it's dust, exactly like the microtransaction example. MNs should care about this, but I don't think most realize it...
At this time, all a sender has to do is watch what they sent, and wait for it to be rolled into a bigger VIN, and they can see every dust/change VIN that was rolled into it.
"But muh DS TXes weren't compromised!"
There weren't any DS TXes involved! These scenarios are not privatized.
Lets say you had, you know a vending machine... Soda isn't $100. $0.50 of DASH is a non-denominatable amount (though, if you don't start taking reality seriously, it may soon be...). It's easy for anyone who makes a single purchase to then view the vendor's entire transaction history publicly. From this perspective, you really don't support micropayments. At least DS doesn't...
The rendezvous system for DS could operate in another way that solves this sort of problem. Instead of distracting from the problem I'm pointing out by pointing to a solution that has noting to do with what I'm talking about, address the problem I'm actually talking about instead of using that distraction tactic to pull the wool over the eyes of onlookers.
If you used a dust collection system that allows, nay, expects, far more than 3 participants, and deliberately waits a set amount of time, this allows dust consolidation that doesn't give away information. It's an improvement. But if you won't admit that it's a thing, and keep pointing at an irrelevant fix to something completely different, that will continue to be overlooked.
Maybe my idea for dust collection isn't the best way to do it. It's just an idea silly ol' me had for dealing with the fact that, no, the Dead Change problem is still in effect. Yes, one hole was plugged, the biggest and most obvious hole. But, yes, dust still does come into existence, and no, there is no way to consolidate it without generating a provable rollup VIN. Duh, that's the very definition of what you're doing when you roll your dust into a bigger total VIN... But, if 40 people got into a DS-like pool to roll all their dust at once... Now that problem is lessened significantly. The result goes into the normal DS denomination process (maybe the MNs don't send it back proportionally, but immediately start the denominating themselves?), the single leftover dust VIN awaits the next dust collection cycle... It never ends. Nothing escapes DS anymore. You don't have an ever growing amount of dust that you better not touch for the association it will generate to consolidate it.
Dust is really DS's only shortcoming, and this gets rid of it...
Why are distraction tactics (pointing at a fix for something completely different) used instead of addressing it?
If the car is out of gas, proudly declaring that you put air in the tires 3.5 years ago does not solve the problem... Car still out of gas.
Sure.
Fine.
That's all well and good.
I honestly don't see it, but even if I concede the point.
It hasn't got anything to do with the topic I've brought up.
What about change/dust from all the other sources from which change/dust can come?
What if a person operates in micropayments? These never get denominated to begin with. They are dust. DS is not involved.
Change from denomination can come from a variety of inputs.
Non-DS VINs.
Payment from MNs are another thing. I brought that up first since it's the biggest deal... If you receive payments from multiple MNs (which by nature will not be DS), and each one goes into a wallet to be denominated, They make dust as they do it. This associates every MN as owned by the same person through it's dust, exactly like the microtransaction example. MNs should care about this, but I don't think most realize it...
At this time, all a sender has to do is watch what they sent, and wait for it to be rolled into a bigger VIN, and they can see every dust/change VIN that was rolled into it.
"But muh DS TXes weren't compromised!"
There weren't any DS TXes involved! These scenarios are not privatized.
Lets say you had, you know a vending machine... Soda isn't $100. $0.50 of DASH is a non-denominatable amount (though, if you don't start taking reality seriously, it may soon be...). It's easy for anyone who makes a single purchase to then view the vendor's entire transaction history publicly. From this perspective, you really don't support micropayments. At least DS doesn't...
The rendezvous system for DS could operate in another way that solves this sort of problem. Instead of distracting from the problem I'm pointing out by pointing to a solution that has noting to do with what I'm talking about, address the problem I'm actually talking about instead of using that distraction tactic to pull the wool over the eyes of onlookers.
If you used a dust collection system that allows, nay, expects, far more than 3 participants, and deliberately waits a set amount of time, this allows dust consolidation that doesn't give away information. It's an improvement. But if you won't admit that it's a thing, and keep pointing at an irrelevant fix to something completely different, that will continue to be overlooked.
Maybe my idea for dust collection isn't the best way to do it. It's just an idea silly ol' me had for dealing with the fact that, no, the Dead Change problem is still in effect. Yes, one hole was plugged, the biggest and most obvious hole. But, yes, dust still does come into existence, and no, there is no way to consolidate it without generating a provable rollup VIN. Duh, that's the very definition of what you're doing when you roll your dust into a bigger total VIN... But, if 40 people got into a DS-like pool to roll all their dust at once... Now that problem is lessened significantly. The result goes into the normal DS denomination process (maybe the MNs don't send it back proportionally, but immediately start the denominating themselves?), the single leftover dust VIN awaits the next dust collection cycle... It never ends. Nothing escapes DS anymore. You don't have an ever growing amount of dust that you better not touch for the association it will generate to consolidate it.
Dust is really DS's only shortcoming, and this gets rid of it...
Why are distraction tactics (pointing at a fix for something completely different) used instead of addressing it?
If the car is out of gas, proudly declaring that you put air in the tires 3.5 years ago does not solve the problem... Car still out of gas.
Last edited:
Hey @camosoul, I really appreciate you looking into this, it's been a good conversation to read through. A little about myself, I am as close to what one might call an active PrivateSend "researcher" and enthusiast and I have discovered many things worth improving and that have been improved, that's just to say I know the privatesend system and even codebase pretty well.
With that being said, what you've described is something that can be improved on but is not a flaw in the current system. The current system was designed to protect sends, which it does, what you are talking about is potential de-anon through receiving coins. What you've described will not break a PS.
In the current setup, in the create denominations step, any inputs spendable by the same private key, ie they were received with the same address, will be automatically 'combined'. Any other inputs, smaller than the smallest denom must be manually combined. I believe those inputs are the ones you refer to as 'dead.' And yes, there is no way to combine those without affecting receiving privacy. As in anyone that sent funds to you can see some of the other funds you received, however this will not affect send privacy. You could manually combine inputs in such a way that only a small amount of the receiving history is affected.
All in all, receiving privacy, especially when receiving small amounts, is definitely an area where dash is somewhat lacking, and it could use some improvement. However, is it that high of a focus? Not in my opinion.
With that being said, what you've described is something that can be improved on but is not a flaw in the current system. The current system was designed to protect sends, which it does, what you are talking about is potential de-anon through receiving coins. What you've described will not break a PS.
In the current setup, in the create denominations step, any inputs spendable by the same private key, ie they were received with the same address, will be automatically 'combined'. Any other inputs, smaller than the smallest denom must be manually combined. I believe those inputs are the ones you refer to as 'dead.' And yes, there is no way to combine those without affecting receiving privacy. As in anyone that sent funds to you can see some of the other funds you received, however this will not affect send privacy. You could manually combine inputs in such a way that only a small amount of the receiving history is affected.
All in all, receiving privacy, especially when receiving small amounts, is definitely an area where dash is somewhat lacking, and it could use some improvement. However, is it that high of a focus? Not in my opinion.
Dash Spork 10 is now active , only 12.3 Masternodes are now accepted in the payment cycle
https://github.com/dashpay/dash/blob/v0.12.3.1/doc/release-notes.md
https://github.com/dashpay/dash/blob/v0.12.3.1/doc/release-notes.md
Last edited:
Hi guys please can someone point me in the right direction.I'm pretty new to dash so go easy,
I got in about 2 years ago everything has been fine...but last night I turned on my laptop to buy and send some dash to my wallet, I then noticed my balance hadn't changed and it was out of sync.
My dash wallet is not syncd and has frozen I can't do anything on it, it still shows the balance of my dash, but not from my latest transactions..im hoping they will show once its all syncd again? iv done some research and I'm thinking maybe I need to UPDATE my wallet to the latest version 12.3.3. could this cause my wallet to freeze?
My main question to you is I can't find a update button in the wallet, so if I download the latest version to my Mac, when it say (replace wallet or keep both )what do I need to do to update it? will this replace my wallet completely with a new one and ill lose my dash? or will it auto update it from the old version and just start to sync with the new update?
Or if this is completely wrong what is the correct way ?
kind regards Spencer
I got in about 2 years ago everything has been fine...but last night I turned on my laptop to buy and send some dash to my wallet, I then noticed my balance hadn't changed and it was out of sync.
My dash wallet is not syncd and has frozen I can't do anything on it, it still shows the balance of my dash, but not from my latest transactions..im hoping they will show once its all syncd again? iv done some research and I'm thinking maybe I need to UPDATE my wallet to the latest version 12.3.3. could this cause my wallet to freeze?
My main question to you is I can't find a update button in the wallet, so if I download the latest version to my Mac, when it say (replace wallet or keep both )what do I need to do to update it? will this replace my wallet completely with a new one and ill lose my dash? or will it auto update it from the old version and just start to sync with the new update?
Or if this is completely wrong what is the correct way ?
kind regards Spencer
Dash wallet updates need to be downloaded and installed manually, there is no auto update within DashCore wallets. First make a backup of your wallet and put it somewhere safe, see if you can make that backup from within your current wallet. If the freeze of your wallet makes that impossible, then close your wallet and copy your wallet.dat which you can find in your Dash installation directory and put that somewhere safe (pref on some usb sticks that you keep offline).
Next pls tell us what Dash version you are currently on and check the current balance of your address here : https://chainz.cryptoid.info/dash/ to see if your latest transaction is known on the blockchain.
If your current version of your Dash wallet is very old (older than v0.12.1.x), then check following guide : https://docs.dash.org/en/stable/wallets/recovery.html#dashcore-restore
Last edited:
t
thanks for your reply,
I have backed up wallet and put on usb, I also checked on that link you sent me and yes the transactions are on there which is good thank you.
The current version Iv got on my wallet is v0.12.2.
Is it normal for wallets to freeze from time to time? mines been stuck on 80.33% for 5 days now and just says connecting to peers in the bottom bar.
What would be the best thing for me to do now with the wallet frozen? install the new one and fingers crossed my coins will sync over?
thanks for your reply,
I have backed up wallet and put on usb, I also checked on that link you sent me and yes the transactions are on there which is good thank you.
The current version Iv got on my wallet is v0.12.2.
Is it normal for wallets to freeze from time to time? mines been stuck on 80.33% for 5 days now and just says connecting to peers in the bottom bar.
What would be the best thing for me to do now with the wallet frozen? install the new one and fingers crossed my coins will sync over?
Best is just to remove the peers.dat file from your installation directory (should be in the same folder as where your wallet.dat is located) and install
the new Dash wallet. The wallet will create a new peers.dat file with new connections, when you start it again. This should help with the syncing.
With windows there is a zip file that you can download and where you can extract the dash-qt.exe from and simply replace the old dash-qt.exe.
With MAC there should be something similiar to updating your dash wallet.
Edit : looks like you will download a .dmg file for OSX, which means installation is a bit different (I'm not a MAC user). Just follow installation guide here : https://docs.dash.org/en/stable/wallets/dashcore/installation-macos.html
The update from v0.12.2 to v0.12.3 should not effect your wallet.dat (you have a backup anyways).
If you still have problems syncing, then try removing the following files from your Dash installation directory when wallet is closed :
mncache.dat
fee_estimates.dat
governance.dat
mnpayments.dat
netfulfilled.dat
banlist.dat
peers.dat
These files are safe to delete (they get re-created at wallet restart), do NOT delete your wallet.dat
Restart wallet.
Last edited:
For a more complete list, here's the dash-related section of my crontab:
Code:
# */30 */* * * ~/.dashcore/dashd
# 1 */6 * * * ~/.dashcore/dash-cli stop
# 2 */6 * * * cd ~/.dashcore && srm masternode.conf banlist.dat db.log debug.log fee_estimates.dat governance.dat .lock mempool.dat mncache.dat mnpayments.dat netfulfilled.dat peers.dat