dfe708993d chore: bump assumevalid, minchainwork, checkpoints, chaintxdata (pasta)
Pull request description:
## Issue being fixed or feature implemented
bump assumevalid, minchainwork, checkpoints, chaintxdata in prep for v21 release final
## What was done?
## How Has This Been Tested?
Reindex TBD
## Breaking Changes
None
## Checklist:
_Go over all the following points, and put an `x` in all the boxes that apply._
- [ ] 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
- [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_
ACKs for top commit:
UdjinM6:
utACK dfe708993d
kwvg:
utACK dfe708993d
Tree-SHA512: 34ef58092cbae4389db87e3f4fc9978356abf19ea110575b89663f00c7621091141f138ce03bc21d7deca9f5b86588c1c2e0874aa8a85d7c54efa41a201d51cc
dfd144b64d docs: add v21.0.0 release notes, archive old release notes, delete partials (pasta)
Pull request description:
## Issue being fixed or feature implemented
Add release notes for v21.0.0
## What was done?
See commits
## How Has This Been Tested?
## Breaking Changes
## Checklist:
_Go over all the following points, and put an `x` in all the boxes that apply._
- [x] I have performed a self-review of my own code
- [x] 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
- [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_
Top commit has no ACKs.
Tree-SHA512: fafe225f7db59ccea6aa998b04204f22b913ab4d0a178737ca2311b093c04be39ce57c2a6ab3e8e0e312a10159118a024371a7315dcb5df3d8651d3535417861
dfd144b64d docs: add v21.0.0 release notes, archive old release notes, delete partials (pasta)
Pull request description:
## Issue being fixed or feature implemented
Add release notes for v21.0.0
## What was done?
See commits
## How Has This Been Tested?
## Breaking Changes
## Checklist:
_Go over all the following points, and put an `x` in all the boxes that apply._
- [x] I have performed a self-review of my own code
- [x] 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
- [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_
Top commit has no ACKs.
Tree-SHA512: fafe225f7db59ccea6aa998b04204f22b913ab4d0a178737ca2311b093c04be39ce57c2a6ab3e8e0e312a10159118a024371a7315dcb5df3d8651d3535417861
dfe708993d chore: bump assumevalid, minchainwork, checkpoints, chaintxdata (pasta)
Pull request description:
## Issue being fixed or feature implemented
bump assumevalid, minchainwork, checkpoints, chaintxdata in prep for v21 release final
## What was done?
## How Has This Been Tested?
Reindex TBD
## Breaking Changes
None
## Checklist:
_Go over all the following points, and put an `x` in all the boxes that apply._
- [ ] 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
- [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_
ACKs for top commit:
UdjinM6:
utACK dfe708993d
kwvg:
utACK dfe708993d
Tree-SHA512: 34ef58092cbae4389db87e3f4fc9978356abf19ea110575b89663f00c7621091141f138ce03bc21d7deca9f5b86588c1c2e0874aa8a85d7c54efa41a201d51cc
They run multiprocess build for ALL PRs in travis since that commit
```diff
- if: type != pull_request OR commit_message =~ /depends:|multiprocess:/ # Skip on non-depends, non-multiprocess PRs
```
fadea0bf371a38620b7f1f93f87d1da76d3314e0 Revert "test: Add tsan supp for leveldb::DBImpl::DeleteObsoleteFiles" (MarcoFalke)
fadbd9988590ba94e3fd2d87d773f3b09d73ef46 test: Remove spurious double lock tsan suppressions by bumping to clang-12 (MarcoFalke)
Pull request description:
The double lock warnings appeared in #19041, but they didn't make any sense. Also, our sync module would detect double locks, if there were any.
Bumping to clang-12 allows us to remove the spurious suppressions needed to run the tests, so do that.
ACKs for top commit:
practicalswift:
cr ACK fadea0bf371a38620b7f1f93f87d1da76d3314e0 assuming CI passes and more specifically that newer Clang agrees that these TSan suppressions are no longer needed.
Tree-SHA512: c411221a4b74d0af6ca8d686639b4f40b41c15906ccbb6647e8d569d6ab088264faafe075e1ac9523d5c0024b85f15a597bb3eedc7f07d4f5816245f75cfc08b
fa5362a9a0c5665c1a4de51c3ce4758c93a9449e rpc: Add missing BlockUntilSyncedToCurrentChain to wallet RPCs (MarcoFalke)
Pull request description:
Wallet RPCs that allow a rescan based on block-timestamp or block-height
need to sync with the active chain first, because the user might assume
the wallet is up-to-date with the latest block they got reported via a
blockchain RPC.
ACKs for top commit:
meshcollider:
utACK fa5362a9a0c5665c1a4de51c3ce4758c93a9449e
Tree-SHA512: d4831f1f08f854f9a49fc969de86c438f856e41c2163c801a6ff36dc2f6299cb342b44663279c524a8b7ca9a50895db1243cd7d49bed79277ada857213f20a26
fa4d0aacf2bbddaf1709660ffd8d520570533aa8 test: * -> & (MarcoFalke)
Pull request description:
This changes background_cs from being a pointer to a reference to work
around a gcc false warning. Also, this makes the test easier to read.
Fixes bitcoin#23101
Can be reviewed with --ignore-all-space.
ACKs for top commit:
practicalswift:
cr ACK fa4d0aacf2bbddaf1709660ffd8d520570533aa8
jamesob:
ACK fa4d0aacf2
hebasto:
ACK fa4d0aacf2bbddaf1709660ffd8d520570533aa8, tested on Linux Mint 20.2 (x86_64) by merging this PR on top of the current master.
Tree-SHA512: 93a0d8859201f7074bea52fab8f6701409148bc50cfbb142cacfa6c991fc12c07584df04fead645f11703883df99535423d154f9945202e1c5aff49540d9b607
7e32fde912b3924fdb27ec1f658ac11fcf160b3e test: feature_cltv.py: don't return tx copies in modification functions (Sebastian Falbesoner)
9ab2ce0a6673acc7ee0f85158fc087fce0fc7dd8 test: drop unused node parameters in feature_cltv.py (Sebastian Falbesoner)
0c2139a3f160d1d443460e4c5928109a6ab8cd11 test: fix typo in feature_cltv.py (s/ctlv/cltv/) (Sebastian Falbesoner)
Pull request description:
This tiny PR cleans up the test `feature_cltv.py` in the following ways:
* fixes a typo (s/ctlv/cltv/); compared to CHECKLOCKTIMEVERIFY, CHECKTIMELOCKVERIFY probably also sounds good and you [even get some search results for it](https://www.google.com/search?q=%22CHECKTIMELOCKVERIFY%22), but it's still wrong ;)
* drops the unused "node" parameters from the tx modification functions
* don't return a copy from the tx modification functions; it's modified in-place, hence a copy is not needed and `cltv_validate(tx, ...)` looks more natural than `tx = cltv_validate(tx, ...)`
ACKs for top commit:
MarcoFalke:
review ACK 7e32fde912b3924fdb27ec1f658ac11fcf160b3e 📼
Tree-SHA512: d2e6230977442f6a511d0f7c99431a44ad3a423647f4f327ce2ce8efe78bf9616c0d2093f5e3c3550f690dcb3f625ddf53227505c01ced70227425f249c25364
2917c33206 partial Merge bitcoin-core/gui#205: Save/restore TransactionView and recentRequestsView tables column sizes (Konstantin Akimov)
e5c2c03984 Merge bitcoin-core/gui#154: qt: Support macOS Dark mode (MarcoFalke)
29a98c7826 Merge bitcoin-core/gui#251: Improve URI/file handling message (MarcoFalke)
48d66fd1ab Merge bitcoin-core/gui#248: Fix: For values of "Bytes transferred" and "Bytes/s" with 1000-based prefix names use 1000-based divisor instead of 1024-based (MarcoFalke)
63b18006a3 Merge bitcoin-core/gui#221: qt, refactor: rpcconsole translatable string fixes and improvements (MarcoFalke)
0d1faa203e fix: removed maximum width of transaction list on overview page (Konstantin Akimov)
458384ab93 Merge bitcoin-core/gui#176: Fix TxViewDelegate layout (MarcoFalke)
d670240d13 Revert "fix: remove stretching from Overview page when it's not needed" (Konstantin Akimov)
Pull request description:
## Issue being fixed or feature implemented
Backports of QT related improvements from bitcoin v22
## What was done?
See commits for list of backports.
Changes related to improved behavior of columns while resizing for Transactions List and Recent Requests is dropped due to low performance and buggy behaviour. bitcoin-core/gui#205 and bitcoin-core/gui#229 are DNM due to incompatibility with our table view.
It reverts also #5992 as better fix is found (see css changes).
## How Has This Been Tested?
Run qt app, try to resize main view with overview page.
## Breaking Changes
N/A
## Checklist:
- [x] 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
- [x] I have assigned this pull request to a milestone
ACKs for top commit:
UdjinM6:
light ACK 2917c33206 (CI failure is unrelated)
PastaPastaPasta:
light-ACK 2917c33206
Tree-SHA512: b84c7e254562d86da30515d05572587edd1b451d988bbcfe16b8874f13d6b581910bed9008a7f8a408aae9181faa86703463fd508711e6e09b299be232ba3f48
1c5ea38c68 merge bitcoin#24197: Replace lock with thread safety annotation in CBlockTreeDB::LoadBlockIndexGuts() (Kittywhiskers Van Gogh)
e5e37458bb merge bitcoin#24002: add thread safety lock assertion to WriteBlockIndexDB() (Kittywhiskers Van Gogh)
04a3f65032 merge bitcoin#23721: Move restorewallet() logic to the wallet section (Kittywhiskers Van Gogh)
e47d5ac81e merge bitcoin#23154: add assumeutxo notes (Kittywhiskers Van Gogh)
847d866ff5 merge bitcoin#22738: fix failure in feature_nulldummy.py on single-core machines (Kittywhiskers Van Gogh)
ad96ef2d25 merge bitcoin#22633: Replace remaining binascii method calls (Kittywhiskers Van Gogh)
b37f609fd0 merge bitcoin-core/gui#399: Fix "Load PSBT" functionality when no wallet loaded (Kittywhiskers Van Gogh)
94173f14dd merge bitcoin#21850: Remove `GetDataDir(net_specific)` function (Kittywhiskers Van Gogh)
6264c7b7c7 merge bitcoin#21953: fuzz: Add utxo_snapshot target (Konstantin Akimov)
8b7ea28e80 merge bitcoin#21754: Run feature_cltv with MiniWallet (Kittywhiskers Van Gogh)
bd750140be merge bitcoin#21762: Speed up mempool_spend_coinbase.py (Kittywhiskers Van Gogh)
72eeb9a0d6 merge bitcoin#21732: Move common init code to init/common (Kittywhiskers Van Gogh)
3944d4ed96 chore: resolve nit from dash#6085 (blockstorage backports) (Kittywhiskers Van Gogh)
92509e2eee fix: don't suppress `-logtimestamps` help if `HAVE_THREAD_LOCAL` undef (Kittywhiskers Van Gogh)
Pull request description:
## Additional Information
* Dependency for https://github.com/dashpay/dash/pull/6138
* In [bitcoin#21754](https://github.com/bitcoin/bitcoin/pull/21754), the `scriptSig` padding multiplier (`24`) differs from upstream (`35`) as the `vsize` value it corresponds to must match what is ordinarily generated (`85` vs `96` upstream) in order to fulfill an assertion ([source](d9835515cc/test/functional/test_framework/wallet.py (L107))).
* In [bitcoin#21953](https://github.com/bitcoin/bitcoin/pull/21953), the hash associated with height `200` is generated like this (this is the same method used in [dash#5236](https://github.com/dashpay/dash/pull/5236)):
* Add the height desired to the `CRegTestParams::m_assumeutxo_data` map with a garbage hash value (like `uint256::ONE`). This is to avoid an unrecognized metadata failure ([source](5211886fb4/src/validation.cpp (L5755-L5761))) caused by looking through the map to see if the height's there.
* Change the `LogPrintf(..)` in the serialized hash check error log message located [here](5211886fb4/src/validation.cpp (L5876-L5880)) to a `std::cout << strprintf(..)`
* Edit the value of `mineBlocks` [here](5211886fb4/src/test/validation_chainstatemanager_tests.cpp (L248-L253)) to be 100 blocks _less_ than the desired height.
* Compile Dash Core and run `./src/test/test_dash -t validation_chainstatemanager_tests`
* Take the `got` value printed to your terminal window/`stdout` (the `expected` value should be our garbage value from earlier, ignore that). That's your good hash.
* Update the `CRegTestParams::m_assumeutxo_data` map entry with the correct entry, reverse every change _except_ the map entry (for obvious reasons) and the `mineBlocks` change.
* Remember to add/update the hash [here](5211886fb4/src/test/validation_tests.cpp (L29-L31)) in `validation_tests`, it simply tests the hardcoded chainparams value with its own hardcoded value. That's also why we don't use this test since it'll just regurgitate the garbage values we give it.
* Compile and re-run the test. If it passes, your hash is good. Revert the `mineBlocks` change.
* Profit?
## Breaking Changes
None expected.
## Checklist:
- [x] I have performed a self-review of my own code
- [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
- [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:
UdjinM6:
utACK 1c5ea38c68
PastaPastaPasta:
utACK 1c5ea38c68
Tree-SHA512: 1ce0d4f1cef68990412e2e7046b36db7425059ee41b39e3681fa05d59fe24a0a74ad8c5d833c0e4c0686f693af665ca749e504b88ad30e708fc163045160aa58
85762dc633 60%+: bg, ro, vi (UdjinM6)
2d0e68dcd6 80%+: ar, de, es, fi, fr, it, ja, ko, nl, pl, pt, ru, sk, th, tr, zh_CN, zh_TW (UdjinM6)
f7992b0b03 en (UdjinM6)
49fc976121 dashstrings (UdjinM6)
c8333a59c5 chore: replace remaining `...` with `…` in translated strings (UdjinM6)
ac2e9ea1e7 qt: Extract translations correctly from UTF-8 formatted source (Hennadii Stepanov)
Pull request description:
## Issue being fixed or feature implemented
Mostly regular translation updates but with 2 additional fixes:
- ac2e9ea is a backport, without it `make translate` fails to update `dashstrings.cpp` properly (but I couldn't figure out which PR it belongs to 🤷♂️ )
- c8333a5 is needed to make it easier to replace all `...` with `…` in `*.ts` files locally to avoid annoying translators (`...` and `…` are visually the same in transifex interface)
## What was done?
## How Has This Been Tested?
## Breaking Changes
## Checklist:
- [x] 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
- [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_
ACKs for top commit:
PastaPastaPasta:
utACK 85762dc633
Tree-SHA512: c3624d8e5b26b0fd4d488e6988e81000d05bdc66f9e126b5d3fe3c1f6bceaa846ee81dfc7c0d18613b0ac682a94e0b17007e86724e7cc02d9cfce87b22ce6916
85762dc633 60%+: bg, ro, vi (UdjinM6)
2d0e68dcd6 80%+: ar, de, es, fi, fr, it, ja, ko, nl, pl, pt, ru, sk, th, tr, zh_CN, zh_TW (UdjinM6)
f7992b0b03 en (UdjinM6)
49fc976121 dashstrings (UdjinM6)
c8333a59c5 chore: replace remaining `...` with `…` in translated strings (UdjinM6)
ac2e9ea1e7 qt: Extract translations correctly from UTF-8 formatted source (Hennadii Stepanov)
Pull request description:
## Issue being fixed or feature implemented
Mostly regular translation updates but with 2 additional fixes:
- ac2e9ea is a backport, without it `make translate` fails to update `dashstrings.cpp` properly (but I couldn't figure out which PR it belongs to 🤷♂️ )
- c8333a5 is needed to make it easier to replace all `...` with `…` in `*.ts` files locally to avoid annoying translators (`...` and `…` are visually the same in transifex interface)
## What was done?
## How Has This Been Tested?
## Breaking Changes
## Checklist:
- [x] 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
- [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_
ACKs for top commit:
PastaPastaPasta:
utACK 85762dc633
Tree-SHA512: c3624d8e5b26b0fd4d488e6988e81000d05bdc66f9e126b5d3fe3c1f6bceaa846ee81dfc7c0d18613b0ac682a94e0b17007e86724e7cc02d9cfce87b22ce6916
e1030a058c docs: add release notes for 6140 (pasta)
9ed292a6e1 feat: harden all sporks on mainnet to current values (pasta)
Pull request description:
## Issue being fixed or feature implemented
Harden all sporks on the mainnet; they are no longer necessary. Although retaining them might be beneficial in addressing bugs or issues, the greater priority is to protect mainnet by minimizing risks associated with potential centralization or even its perception. Sporks will continue to be valuable for testing on developer networks; however, on mainnet, the risks of maintaining them now outweigh the benefits of retaining them.
## What was done?
Adjust CSporkManager::GetSporkValue to always return 0 for sporks in general and 1 for SPORK_21_QUORUM_ALL_CONNECTED specifically.
## How Has This Been Tested?
Ran main net node with this patch. Sporks show as expected
## Breaking Changes
This is not a breaking change.
## Checklist:
- [x] I have performed a self-review of my own code
- [x] 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
- [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_
ACKs for top commit:
knst:
utACK e1030a058c
UdjinM6:
utACK e1030a058c (CI failure is unrelated)
Tree-SHA512: f20d0f614b7e9d6eb5606c545d0747a9d415f2905512dd6100a2f9fb00bb6de02c8d5aa74cb41aa39163fde0ab05fe472913acc227b1b4afce7e984f8897940d
a8a3ea0e90 feat: enable EHF activation of MN_RR on mainnet (Konstantin Akimov)
Pull request description:
## Issue being fixed or feature implemented
https://github.com/dashpay/dash/issues/6081
## What was done?
Removed a code, that disabled MN_RR activation with EHF on Main Net
## How Has This Been Tested?
This code is tested on devnet, is in process of testing on testnet.
## Breaking Changes
It make MN_RR possible to get active on mainnet.
## Checklist:
- [x] 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
- [x] I have assigned this pull request to a milestone
ACKs for top commit:
UdjinM6:
utACK a8a3ea0e90
PastaPastaPasta:
utACK a8a3ea0e90
Tree-SHA512: 0ae7aecca8463436e952154210cf564333cd77dd1149f7ff88ca144f3b7c434e75e473ea3a6850da1b126efd8a9cece34e46b4bf2b37f5937bcf1f5780e18f50
e2f56de7f4 docs: update manpages for 21.0 (Konstantin Akimov)
Pull request description:
## Issue being fixed or feature implemented
https://github.com/dashpay/dash/issues/6081
## What was done?
run `./contrib/devtools/gen-manpages.sh`, sanitize version name
## How Has This Been Tested?
n/a
## Breaking Changes
n/a
## Checklist:
- [x] 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
- [x] I have assigned this pull request to a milestone
ACKs for top commit:
UdjinM6:
utACK e2f56de7f4
PastaPastaPasta:
utACK e2f56de7f4
Tree-SHA512: 9b56f7a31279457aed1b7ed0b627d4364f786948f6df3176e24ab73b68d785fc90d9bf6136d7965c1c5b97b589b4d228edd338e666d1999e841c6e544f054c05
8a66af25e8 docs: add release notes notifying change of default branch to `develop` (Kittywhiskers Van Gogh)
Pull request description:
## Additional Information
Add a release note notifying the new default branch as `develop`.
## 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
- [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_
ACKs for top commit:
PastaPastaPasta:
utACK 8a66af25e8
UdjinM6:
utACK 8a66af25e8
Tree-SHA512: 82212ce670cf4b0f243a79170914ad04b1d118406ce6402b33dfb42a5ae0865c36de4b816530238bb9ded796c66f3dcc36fa9400ace59b6e7dad24ba47653e4f
878bce0f45 docs: update SECURITY.md supported versions (Kittywhiskers Van Gogh)
Pull request description:
## Additional Information
Updates the supported versions list in `SECURITY.md`
## 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
- [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_
ACKs for top commit:
PastaPastaPasta:
utACK 878bce0f45
UdjinM6:
utACK 878bce0f45
knst:
utACK 878bce0f45
Tree-SHA512: d941a3ca0792b2f08f68cab562a35d869d8e93f627918a25a9753955b6103d1515899b0ca50ff936c966b9f9fd603e12d27b03267361c8f1030a31f9fffdf2ae
69c37f4ec2 rpc: make sure `upgradetohd` always has the passphrase for `UpgradeToHD` (Kittywhiskers Van Gogh)
619b640a77 wallet: unify HD chain generation in CWallet (Kittywhiskers Van Gogh)
163d31861c wallet: unify HD chain generation in LegacyScriptPubKeyMan (Kittywhiskers Van Gogh)
Pull request description:
## Motivation
When filming demo footage for https://github.com/dashpay/dash/pull/6093, I realized that if I tried to create an encrypted blank legacy wallet and run `upgradetohd [mnemonic]`, the client would crash.
```
dash@b9c6631a824d:/src/dash$ ./src/qt/dash-qt
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-dash'
dash-qt: wallet/scriptpubkeyman.cpp:399: void LegacyScriptPubKeyMan::GenerateNewCryptedHDChain(const SecureString &, const SecureString &, CKeyingMaterial): Assertion `res' failed.
Posix Signal: Aborted
No debug information available for stacktrace. You should add debug information and then run:
dash-qt -printcrashinfo=bvcgc43iinzgc43ijfxgm3ybaadwiyltnawxc5avkbxxg2lyebjwsz3omfwduicbmjxxe5dfmqaaa===
```
The expected set of operations when performing privileged operations is to first use `walletpassphrase [passphrase] [time]` to unlock the wallet and then perform the privileged operation. This routine that applies for almost all privileged RPCs doesn't apply here, the unlock state of the wallet has no bearing on constructing an encrypted HD chain as it needs to be encrypted with the master key stored in the wallet, which in turn is encrypted with a key derived from the passphrase (i.e., `upgradetohd` imports **always** need the passphrase, if encrypted).
You might have noticed that I used `upgradetohd [mnemonic]` instead of the correct syntax, `upgradetohd [mnemonic] "" [passphrase]` that is supposed to be used when supplying a mnemonic to an encrypted wallet, because when you run the former, you don't get told to enter the passphrase into the RPC command, you're told.
```
Error: Please enter the wallet passphrase with walletpassphrase first.
```
Which tells you to treat it like any other routine privileged operation and follow the routine as mentioned above. This is where insufficient validation starts rearing its head, we only validate the passphrase if we're supplied one even though we should be demanding one if the wallet is encrypted and it isn't supplied. We didn't supply a passphrase because we're following the normal routine, we unlocked the wallet so `EnsureWalletIsUnlocked()` is happy, so now the following happens.
```
upgradetohd()
| Insufficient validation has allowed us to supply a blank passphrase
| for an encrypted wallet
|- CWallet::UpgradeToHD()
|- CWallet::GenerateNewHDChainEncrypted()
| We get our hands on vMasterKey by generating the key from our passphrase
| and using it to unlock vCryptedMasterKey.
|
| There's one small problem, we don't know if the output of CCrypter::Decrypt
| isn't just gibberish. Since we don't have a passphrase, whatever came from
| CCrypter::SetKeyFromPassphrase isn't the decryption key, meaning, the
| vMasterKey we just got is gibberish
|- LegacyScriptPubKeyMan::GenerateNewCryptedHDChain()
|- res = LegacyScriptPubKeyMan::EncryptHDChain()
| |- EncryptSecret()
| |- CCrypter::SetKey()
| This is where everything unravels, the gibberish key's size doesn't
| match WALLET_CRYPTO_KEY_SIZE, it's no good for encryption. We bail out.
|- assert(res)
We assume are inputs are safe so there's no real reason we should crash.
Except our inputs aren't safe, so we crash. Welp! :c
```
This problem has existed for a while but didn't cause the client to crash, in v20.1.1 (19512988c6), trying to do the same thing would return you a vague error
```
Failed to generate encrypted HD wallet (code -4)
```
In the process of working on mitigating this crash, another edge case was discovered, where if the wallet was unlocked and an incorrect passphrase was provided to `upgradetohd`, the user would not receive any feedback that they entered the wrong passphrase and the client would similarly crash.
```
upgradetohd()
| We've been supplied a passphrase, so we can try and validate it by
| trying to unlock the wallet with it. If it fails, we know we got the
| wrong passphrase.
|- CWallet::Unlock()
| | Before we bother unlocking the wallet, we should check if we're
| | already unlocked, if we are, we can just say "unlock successful".
| |- CWallet::IsLocked()
| | Wallet is indeed unlocked.
| |- return true;
| The validation method we just tried to use has a bail-out mechanism
| that we don't account for, the "unlock" succeded so I guess we have the
| right passphrase.
[...] (continue call chain as mentioned earlier)
|- assert(res)
Oh...
```
This pull request aims to resolve crashes caused by the above two edge cases.
## Additional Information
As this PR was required me to add additional guardrails on `GenerateNewCryptedHDChain()` and `GenerateNewHDChainEncrypted()`, it was taken as an opportunity to resolve a TODO ([source](9456d0761d/src/wallet/wallet.cpp (L5028-L5038))). The following mitigations have been implemented.
* Validating `vMasterKey` size (any key not of `WALLET_CRYPTO_KEY_SIZE` size cannot be used for encryption and so, cannot be a valid key)
* Validating `secureWalletPassphrase`'s presence to catch attempts at passing a blank value (an encrypted wallet cannot have a blank passphrase)
* Using `Unlock()` to validate the correctness of `vMasterKey`. (the two other instances of iterating through `mapMasterKeys` use `Unlock()`, see [here](1394c41c8d/src/wallet/wallet.cpp (L5498-L5500)) and [here](1394c41c8d/src/wallet/wallet.cpp (L429-L431)))
* `Lock()`'ing the wallet before `Unlock()`'ing the wallet to avoid the `IsLocked()` bail-out condition and then restoring to the previous lock state afterwards.
* Add an `IsCrypted()` check to see if `upgradetohd`'s `walletpassphrase` is allowed to be empty.
## Checklist:
- [x] I have performed a self-review of my own code
- [x] I have commented my code, particularly in hard-to-understand areas
- [x] I have added or updated relevant unit/integration/functional/e2e tests
- [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:
knst:
utACK 69c37f4ec2
UdjinM6:
utACK 69c37f4ec2
PastaPastaPasta:
utACK 69c37f4ec2
Tree-SHA512: 4bda1f7155511447d6672bbaa22b909f5e2fc7efd1fd8ae1c61e0cdbbf3f6c28f6e8c1a8fe2a270fdedff7279322c93bf0f8e01890aff556fb17288ef6907b3e
a35f0c6a99 Merge bitcoin/bitcoin#22501: netinfo: display addr_{processed, rate_limited, relay_enabled} and relaytxes data (W. J. van der Laan)
f263bea244 Merge bitcoin/bitcoin#22755: fuzz: Avoid timeout in blockfilter fuzz target (MarcoFalke)
dd26a7a806 Merge bitcoin/bitcoin#22797: test, doc: refer to the correct variable names in p2p_invalid_tx.py (fanquake)
c3ea99e492 Merge bitcoin/bitcoin#22780: doc: Remove incorrect INIT_PROTO_VERSION from nTime comment (MarcoFalke)
56c3f844dc Merge bitcoin/bitcoin#22622: util: Check if specified config file cannot be opened (MarcoFalke)
Pull request description:
bitcoin backports
Top commit has no ACKs.
Tree-SHA512: 4db8131cb97e4345f598fbef4f73fa601ee837a395ce00acb37e721078b0a13dba8f0a1a8047f2096482fc0c87388b01a2ea7ab2b2b2caacce4ecd55e0377b24
218862a01848f69d54380c780bb5eae6dfdb1416 Display peers in -netinfo that we don't relay addresses to (Jon Atack)
3834e23b251ed7b4a47bbb981faba65b97ecbba0 Display peers in -netinfo that request we not relay transactions (Jon Atack)
0a9ee3a2c787e97213a0456b0d6253c549b71e09 Simplify a few conditionals in -netinfo (Jon Atack)
5eeea8e2575a36587e70743af3bd7c2d87b8cf36 Add addr_processed and addr_rate_limited stats to -netinfo (Jon Atack)
Pull request description:
Update CLI -netinfo to display the getpeerinfo `addr_processed`, `addr_rate_limited`, `addr_relay_enabled` and `relaytxes` data with auto-adjusting column widths.
```
$ ./src/bitcoin-cli -netinfo help
txn Time since last novel transaction received from the peer and accepted into our mempool, in minutes
"*" - the peer requested we not relay transactions to it (relaytxes is false)
addrp Total number of addresses processed, excluding those dropped due to rate limiting
"." - we do not relay addresses to this peer (addr_relay_enabled is false)
addrl Total number of addresses dropped due to rate limiting
```
ACKs for top commit:
0xB10C:
Code review and tested ACK 218862a01848f69d54380c780bb5eae6dfdb1416
Zero-1729:
re-tACK 218862a01848f69d54380c780bb5eae6dfdb1416
vasild:
ACK 218862a01848f69d54380c780bb5eae6dfdb1416
jarolrod:
tACK 218862a01848f69d54380c780bb5eae6dfdb1416
Tree-SHA512: bb9da4bdd71859b234f6e4c2c46257a57ef0d0e0b363d2b8fded128bcaa28132f64a0a4651c622e1de1e3b7c05c7587a4369e9e79799895884fda9745c63409d
fa2547fc52b90b4bbde250803df24d7f665383a7 fuzz: Avoid timeout in blockfilter fuzz target (MarcoFalke)
Pull request description:
Previously it would take 10 seconds to run this input, now it takes 10ms: [clusterfuzz-testcase-blockfilter-5022838196142080.log](https://github.com/bitcoin/bitcoin/files/7021883/clusterfuzz-testcase-blockfilter-5022838196142080.log)
The fix is moving the `MatchAny` out of the hot loop.
Also, to avoid unlimited runtime, cap the hot loop at 30k iterations.
ACKs for top commit:
GeneFerneau:
Approach ACK [fa2547f](fa2547fc52)
Tree-SHA512: a04e7388856930ec81222da8f05b665a923fe9482aeb4c55c9be4561aa7320a0703dbbf8d438ae92854e877a8e3b46777a29c0b652b8f34c29c2142cc5d63ccb
0d9fdd329e81cb171d687042290f4e6b1507d7f4 test, doc: refer to the correct variable names in p2p_invalid_tx.py (aitorjs)
Pull request description:
_tx_orphan_no_fee_ and _tx_orphan_invalid_ don't exist as transactions.
Have been replaced by _tx_orphan_2_no_fee_ and _tx_orphan_2_invalid_ respectively.
**Motivation**: Comments are more accurate and easy understandable under the tests context (I think).
ACKs for top commit:
kristapsk:
utACK 0d9fdd329e81cb171d687042290f4e6b1507d7f4
theStack:
ACK 0d9fdd329e81cb171d687042290f4e6b1507d7f4 📃
Tree-SHA512: a4cafd931e51fe2a67085e10e9c61178c864c14982664d112b76327e040af08cd1de04eca4a8ae980fad57ba7078017ce02fc60e7658f38380e8172c2ae28b77
127b4608e9dbb8217c74c9332e82fcec8c326fa8 test: Check if specified config file cannot be opened (nthumann)
6bb54708e6457f21596793a7149dc6dfea1dc871 util: Check if specified config file cannot be opened (nthumann)
Pull request description:
Fixes https://github.com/bitcoin/bitcoin/issues/22612.
When running e.g. `./src/bitcoind -datadir=/tmp/bitcoin -regtest -conf=/tmp/bitcoin/regtest/bitcoin.conf` and the specified config cannot be opened (doesn't exist, permission denied, ...), the initialization silently uses the default config.
As voidburn already noted:
> I can't think of a situation in which a config file is specified explicitly (in the startup options, as per service unit linked above), but inaccessible, where the fail condition should be to keep booting using defaults instead.
With this patch applied, the initialization will fail immediately, if the specified config file cannot be opened. If no config file is explicitly specified, the behavior is unchanged. This not only affects `bitcoind`, but also `bitcoin-cli` and `bitcoin-qt`.
In the example below the datadir is accessible, but the config file is not due to insufficient permissions:
```
$ ./src/bitcoind -datadir=/tmp/bitcoin -regtest --debug=1 -conf=/tmp/bitcoin/regtest/bitcoin.conf
Error: Error reading configuration file: specified config file "/tmp/bitcoin/regtest/bitcoin.conf" could not be opened.
```
ACKs for top commit:
0xB10C:
ACK 127b4608e9dbb8217c74c9332e82fcec8c326fa8
Zero-1729:
tACK 127b4608e9dbb8217c74c9332e82fcec8c326fa8
theStack:
Tested ACK 127b4608e9dbb8217c74c9332e82fcec8c326fa8
Tree-SHA512: 4fe487921485426f1d1da8d256c388af517b984b639d776aec7b159b3e23b669824093d3bdd31139d9415ed5f5de405b3e6a51b110c8ab471f12b9c99ac67cc1
e1030a058c docs: add release notes for 6140 (pasta)
9ed292a6e1 feat: harden all sporks on mainnet to current values (pasta)
Pull request description:
## Issue being fixed or feature implemented
Harden all sporks on the mainnet; they are no longer necessary. Although retaining them might be beneficial in addressing bugs or issues, the greater priority is to protect mainnet by minimizing risks associated with potential centralization or even its perception. Sporks will continue to be valuable for testing on developer networks; however, on mainnet, the risks of maintaining them now outweigh the benefits of retaining them.
## What was done?
Adjust CSporkManager::GetSporkValue to always return 0 for sporks in general and 1 for SPORK_21_QUORUM_ALL_CONNECTED specifically.
## How Has This Been Tested?
Ran main net node with this patch. Sporks show as expected
## Breaking Changes
This is not a breaking change.
## Checklist:
- [x] I have performed a self-review of my own code
- [x] 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
- [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_
ACKs for top commit:
knst:
utACK e1030a058c
UdjinM6:
utACK e1030a058c (CI failure is unrelated)
Tree-SHA512: f20d0f614b7e9d6eb5606c545d0747a9d415f2905512dd6100a2f9fb00bb6de02c8d5aa74cb41aa39163fde0ab05fe472913acc227b1b4afce7e984f8897940d
1bf0bf492f merge bitcoin#24515: Only load BlockMan in BlockMan member functions (Kittywhiskers Van Gogh)
5c1eb67c42 merge bitcoin#24050: Give m_block_index ownership of CBlockIndexes (Kittywhiskers Van Gogh)
c440304c85 merge bitcoin#22932: Add CBlockIndex lock annotations, guard nStatus/nFile/nDataPos/nUndoPos by cs_main (Kittywhiskers Van Gogh)
e303a4ec45 merge bitcoin#23974: Make blockstorage globals private members of BlockManager (Kittywhiskers Van Gogh)
301163c65e merge bitcoin#23581: Move BlockManager to node/blockstorage (Kittywhiskers Van Gogh)
732e871a6b merge bitcoin#23785: Move stuff to ChainstateManager (Kittywhiskers Van Gogh)
b402fd57fa merge bitcoin#23174: have LoadBlockIndex account for snapshot use (Kittywhiskers Van Gogh)
a08f2f48bf merge bitcoin#21526: UpdateTip/CheckBlockIndex assumeutxo support (Kittywhiskers Van Gogh)
472caa048a merge bitcoin#22371: Move pblocktree global to BlockManager (Kittywhiskers Van Gogh)
d69ca833df merge bitcoin#21727: Move more stuff to blockstorage (Kittywhiskers Van Gogh)
6df927fc60 chore: exclude underscore placeholder from shadowing linter warnings (Kittywhiskers Van Gogh)
Pull request description:
## Additional Information
* Dependent on https://github.com/dashpay/dash/pull/6078
* Dependent on https://github.com/dashpay/dash/pull/6074
* Dependent on https://github.com/dashpay/dash/pull/6083
* Dependent on https://github.com/dashpay/dash/pull/6119
* Dependency for https://github.com/dashpay/dash/pull/6138
* In [bitcoin#24050](https://github.com/bitcoin/bitcoin/pull/24050), `BlockMap` is given ownership of the `CBlockIndex` instance contained within the `unordered_map`. The same has not been done for `PrevBlockMap` as `PrevBlockMap` is populated with `pprev` pointers and doing so seems to break validation logic.
* Dash has a specific linter for all Dash-specific code present in Core. The introduction of `util/translation.h` into `validation.h` has caused the linter to trigger shadowing warnings due to a conflict between the common use of `_` as a placeholder/throwaway name ([source](37e026a038/src/spork.cpp (L44))) and upstream's usage of it to process translatable strings ([source](37e026a038/src/util/translation.h (L55-L62))).
Neither C++17 nor C++20 have an _official_ placeholder/throwaway term or annotation for structured bindings (which cannot use `[[maybe_unused]` or `std::ignore`) but [P2169](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2169r4.pdf) is a proposal put forth to make it the official placeholder, in that light, the linter will silence shadowing warnings involving an underscore.
## Breaking Changes
None expected
## Checklist:
- [x] I have performed a self-review of my own code
- [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
- [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:
UdjinM6:
utACK 1bf0bf492f (with one nit)
knst:
utACK 1bf0bf492f
PastaPastaPasta:
utACK 1bf0bf492f
Tree-SHA512: 875fff34fe91916722f017526135697466e521d7179c473a5c0c444e3aa873369019b804dee9f5f795fc7ebed5c2481b5ce2d895b2950782a37de7b098157ad4
bebf391815 fix: build with -Wdocumentation - rename param pwallet to wallet (Konstantin Akimov)
Pull request description:
## Issue being fixed or feature implemented
CI failures like that:
https://gitlab.com/dashpay/dash/-/jobs/7400661581
It happened due to 2 PRs merged one after each other without rebasing:
- enabling -Wdocumentation in bitcoin#21631 (#6113)
- renaming param while doxygen comment is forgotten in #6114
## What was done?
It contains changes from https://github.com/dashpay/dash/pull/6133
Thanks Vijay for spotting issue, this PR is DNM if 6133 will get merged faster.
## How Has This Been Tested?
See CI
## Breaking Changes
N/A
## Checklist:
- [x] 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
- [x] I have assigned this pull request to a milestone
ACKs for top commit:
UdjinM6:
utACK bebf391815
PastaPastaPasta:
utACK bebf391815
Tree-SHA512: 34265f09098c04593a9d52709e5b8aed8460248762655945e5c86a65adb9aa49ab6f0bdb21cd907d353fe6b10e1ff2e07d05528166bf8e2140eb2c9ea1acbd33
