- 
                Notifications
    You must be signed in to change notification settings 
- Fork 1.2k
Add 5th denom, drop deprecated logic and bump min PS version #2318
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
| How will the rollout occur? Will some users not be able to mix if they have the new version and the majority of the network doesn't? Based on what you said the upgrade doesn't sound like it would be smooth | 
| Also, mostly fixes #2198 but doesn't remove the 10 denom. I'd still like to see that change done. I don't think the 10 has enough usage for it to retain its privacy | 
| 
 Yes, there will be a couple of days when it won't make sense to even try to mix on a newest version. If you reeeeally need mixing you probably should just wait and keep using the old version until majority of the network is upgraded. Probably smth to be highlighted in release notes. 
 I'm not sure about that one, imo 10s still have non-negligible mixing volume https://dashradar.com/charts/mixing-transactions-per-day-by-denomination | 
| Yesterday there were only 24 mixes using 10 denoms. I would consider that very very low mixing volume | 
| Low number of mixing sessions - yes, but low volume - I wouldn't say so. Full stats for yesterday are like this: For 1 input per session that would be: Yes, avg number of inputs might be higher for smaller denoms. Let's say it's 5 inputs for all other denoms but 10s: Which still gives the 2nd place by volume for 10s and it would be the 1st place if avg for 10s would be 2 inputs per session (per participant) instead. | 
| I don't see how that is relevant to its effective privacy. Low volume was likely bad word choice on my side as the number of mixing sessions is what really matters | 
| The problem with removing 10s is basically like this: if you are mixing large amounts and want to spend > 10 DASH via PS later you need 10s because otherwise you are stuck with so many 1s in 1 spending tx that it becomes not-so-private for cluster analysis algos. Having not so many sessions is not that bad imo. | 
| Agreed, lack of sessions concerns me but I agree with you on the cluster analysis remark | 
| utACK | 
        
          
                src/privatesend.h
              
                Outdated
          
        
      There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would prefer to not assume knowledge of vecStandardDenominations here and instead use some kind of GetSmallestDenomination, but I guess we can do some clean up later.
(Only because this exposes internals of how we manage PS denoms, and we are directly accessing the internal vector instead of using accessors, which provide an abstraction and allow calling code to not worry about implementation.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note: I'm not suggesting any changes here, just commenting my thoughts for future clean up.
        
          
                src/privatesend.h
              
                Outdated
          
        
      There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@UdjinM6 Will this change the wire serialization of DSQ (and cause incompatibility between versions)? Or does that not matter since Spork 6 was never activated?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, serialization will change, but we are bumping MIN_PRIVATESEND_PEER_PROTO_VERSION too here (and we don't process PS messages from/to nodes below it), so it should be fine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All 12.4 nodes will reject DSA and DSQ from any 12.3 node, and all 12.3 nodes will not be able to decode DSA and DSQ from any 12.4 node.
I see 2 issues here during the network upgrade:
- there may be problems with propagation of DSQ messages through the network,
- 12.3 nodes can mix only with another 12.3 nodes only through 12.3 MNs, the same for 12.4 nodes/MNs
The Second issue would not be so big if the First issue didn't make mixing unstable for quite long time. Thoughts?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Small correction: 12.4 won't relay any PS message to 12.3 nodes. But yes, migration issues you highlighted are correct - mixing usability will be degraded for a week or so while network is upgrading, especially if you are not using the version which is used by the majority (MNs/mixing participants) atm.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just one inline question about dsq serialization, otherwise looks good.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK, 👍
| Rebased to fix merge conflict (due to dropping  | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK
| Bumped  | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK
| Rebased to fix merge conflicts after #2373 . Ready for the final review :) | 
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
utACK
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
re-utACK
| NOTE: revert this ( 2624547 ) is you want to keep mixing on current testnet/mainnet | 
* P2P - Remove dsa and dsq input count Related to dashpay/dash#2075, dashpay/dash#2259, and dashpay/dash#2318 * P2P - Update dsq and dstx to include BLS signature Related to dashpay/dash#2352 * P2P - Update govobj and govobjvote to include BLS signature Related to dashpay/dash#2352
7021170212 to avoid conflicts with 70210 (esp. during migration)Note: After merging this
developwon't be able to mix on current mainnet until migration, you'd have to revert it locally to keep mixing on mainnet.