Decouple lite mode and client-side PrivateSend - #2893
Conversation
171617a to
ec8f7fa
Compare
|
Travis is green after manual restart https://travis-ci.org/UdjinM6/dash |
PastaPastaPasta
left a comment
There was a problem hiding this comment.
One suggestion(that's not terribly relevant to this PR but 🤷♂️), otherwise utACK. didn't test tho
There was a problem hiding this comment.
Testing on testnet commit ec8f7faa64 : works not in litemode, on litemode doesn't work.
Started client with ./dash-qt --testnet --litemode
In console privatesend start yields Mixing start failed: , will retry Starting with --privatesend didn't work either.
Hmm, forgot about the -enableprivatesend command, but still, I don't like that error message, not very clear that I need to enable privatesend via launch option
Alright, testing on litemode and it's working now with -enableprivatesend
364d900 to
cbf7cae
Compare
|
Rebased to fix conflicts after #2936 |
PastaPastaPasta
left a comment
There was a problem hiding this comment.
There should be a better error message when attempting to start PS from non lite-mode client
There was a problem hiding this comment.
See inline comments.
I'm also wondering if it actually makes sense to have -enableprivatesend at all if at the same time fPrivateSendRunning is actually controlling whether its running or not. What about removing all the conditionals around fEnablePrivateSend (treat it as if its always "enabled") and just handle fPrivateSendRunning? The only real effect this would have on users is that they can't disable the PS UI.
There was a problem hiding this comment.
Maybe out of scope of this PR, but I have the feeling that this check and the corresponding = false should happen at inititialization time instead of here and this location should just check for !fEnablePrivateSend || !fPrivateSendRunning
There was a problem hiding this comment.
cbf7caef629306246d979ecbb54da8e503b5efac kind of does the init part but I pushed more replacements for !pwalletMain just now.
There was a problem hiding this comment.
Is the move of this into the !fEnablePrivateSend intended? If I'm not mistaken, this was present run in all cases before.
There was a problem hiding this comment.
Same with updateInstantSend actually, but I assume it's ok in that case as you're moving it into the !fLiteMode case.
There was a problem hiding this comment.
Yes, there is no reason to use connect for an invisible PS checkbox (which is the case when PS is disabled, line 93).
|
|
|
Was there ever any change for the error message if a user launches in lightmode but doesn't |
|
@PastaPastaPasta ah, I see what you mean now, wasn't clear before :) |
|
Added 7050f08, pls re-review. |
`-enableprivatesend`: 1. off by default in lite mode but can be overridden 2. does not start mixing, use `-privatesendautostart` (default is off) or `privatesend` rpc instead
… `!pwalletMain` in ps client code
…n mmixing is disabled
|
Rebased to fix merge conflicts after #2992 (added a couple of |
This allows client-side mixing on pruned nodes running in lite mode.
Redefines
fEnablePrivateSendand-enableprivatesend:offby default in lite mode andonin full mode (but can be overridden in both modes);Introduces
fPrivateSendRunningand-privatesendautostart(default is off). Use this to start mixing automatically (orprivatesendrpc to start mixing manually).Also,
privatesend_balanceis shown in rpcs regardless of lite mode or PS state now.