Dash v12.3 Release Announcement - available July 3rd
- Thread starter bob
- Start date
Matt Robertson
New member
When do all pre-70210 protocol nodes get kicked off?
bb2ebb
New member
perhaps you need rebuild your masternode from scratch
Meaby write what is your issue Nick?
camosoul
Well-known member
Bump.
camosoul
Well-known member
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:
qwizzie
Well-known member
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:
camosoul
Well-known member
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:
camosoul
Well-known member
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:
Macrochip
Active member
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?
camosoul
Well-known member
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:
camosoul
Well-known member
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:
Macrochip
Active member
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.
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.
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.
camosoul
Well-known member
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...
TroyDASH
Well-known member
@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:
TroyDASH
Well-known member
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:
camosoul
Well-known member
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:
camosoul
Well-known member
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...
Macrochip
Active member
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: