-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
[v22.0.x] backport: 22.0.0 rc.4 backports #6454
[v22.0.x] backport: 22.0.0 rc.4 backports #6454
Conversation
…atures@7e747e8a as 62fa665 f25a936 build: stop tracking cmake dependency relic_conf.h.in (Kittywhiskers Van Gogh) 62fa665 Squashed 'src/dashbls/' changes from 4e070243ae..7e747e8a07 (Kittywhiskers Van Gogh) b1b3840 revert: stop tracking cmake dependency relic_conf.h.in (Kittywhiskers Van Gogh) Pull request description: ## Additional Information * Closes dashpay#6343 * Includes [bls-signatures#102](dashpay/bls-signatures#102) and [bls-signatures#104](dashpay/bls-signatures#104) ## Breaking Changes None expected. ## Checklist: - [x] I have performed a self-review of my own code **(note: N/A)** - [x] I have commented my code, particularly in hard-to-understand areas **(note: N/A)** - [x] I have added or updated relevant unit/integration/functional/e2e tests **(note: N/A)** - [x] I have made corresponding changes to the documentation **(note: N/A)** - [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_ ACKs for top commit: PastaPastaPasta: utACK f25a936 UdjinM6: utACK f25a936 Tree-SHA512: 394a02a50f57538e9d12f836fd1ea1598d8a20e2d0079fcb44bb317a42a64a638a1ef906222f2d3bab06d2c0b8cfac43c6e0055d87fbdb86abe680c53ecd6b7a
24dcce9 fix: store ready queues on the mixing masternode (UdjinM6) Pull request description: ## Issue being fixed or feature implemented We normally do not re-relay/store "ready" `dsq`-s because these are ment to be relayed between mixing clients and the mixing masternode only. I works ok when you simply send `dsq` messages because no extra steps are required. However since 70235 we send `dsq` _`inv`-s_ first and we send actual `dsq`-s only if they are requested via `getdata`. The problem here is that `ProcessGetData()` queries `vecCoinJoinQueue` via `GetQueueFromHash()` to get the data to send back but there is none because we never saved it. ## What was done? ## How Has This Been Tested? To test this patch you need a MN but you can test 2 cases _without this patch_ to indirectly test the idea: 1. try mixing on develop: almost no mixing txes, maybe 10 or so in an hour if you are lucky to mix on an old MN that often 2. ignore old MNs (`MIN_PEER_PROTO_VERSION = 70235`): 0 mixing txes, no matter how long you wait 3. pretend being an old client to receive no-inv `dsq` only (`PROTOCOL_VERSION = 70233`): no issues, mixing on these nodes is as fast as usual, several txes per block (need a couple of nodes like that on the network so that a mixing session could be completed, I'm running one node for now so that anyone could join and test it) I'm running a testnet MN with this fix and applied "ignore old mn" patch on my local machine. Local wallet got mixing tx when it finally hit the patched mn. Also confirmed this via MN`debug.log` (`Create`/`Relay`/`CommitFinalTransaction` in logs). ## Breaking Changes ## Checklist: - [ ] I have performed a self-review of my own code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have added or updated relevant unit/integration/functional/e2e tests - [ ] I have made corresponding changes to the documentation - [ ] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_ ACKs for top commit: PastaPastaPasta: utACK 24dcce9 Tree-SHA512: 69cee5401d26eec3f66166a754b8020e7f550dac4a0fdea8ec48ea1082f1286e647ac0a26a189c4d39e1a9da4e7ac36f71913684b13ea0fb4b3cfe831174970e
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.
LGTM 758cd64
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 758cd64
…shing d296005 fix(qt): allow refreshing wallet data without crashing (UdjinM6) Pull request description: ## Issue being fixed or feature implemented We re-use `refreshWallet` method to optimise loading for huge wallets dashpay#5453. However gui121 backport (via 25f87b9) added a condition that prevents this logic. Fix it by allowing explicit wallet refresh (force=true). ## What was done? ## How Has This Been Tested? Open a wallet with 10k+ txes, do `rescanblockchain` via rpc console ## Breaking Changes ## Checklist: - [ ] I have performed a self-review of my own code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have added or updated relevant unit/integration/functional/e2e tests - [ ] I have made corresponding changes to the documentation - [ ] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_ ACKs for top commit: PastaPastaPasta: utACK d296005; Tree-SHA512: d308b3fe9c4fbbfbf2e2339aa14c825aa6f69c72d1f04dab7a14dc1c8721138beca47c7b3801db9782d6cecf2c54023a19a6d22e04b84615f9bddb0b8ec1696c
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 fa29ed5
Issue being fixed or feature implemented
batch of backports to go into rc.4
What was done?
Bls library updated to compile on freebsd, fix for mixing
How Has This Been Tested?
Breaking Changes
Checklist:
Go over all the following points, and put an
x
in all the boxes that apply.