It's more likely that the stat is broken than the network running with
such low difficulty, the hash rate is reported as zero.
`*hashesPerSecond` are a gauge and we should let the last known good
value linger instead of potentially overwriting it with an improbable
value.
87b3c7f5d1 docs: update supported versions in SECURITY.md (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:
knst:
utACK 87b3c7f5d1
UdjinM6:
utACK 87b3c7f5d1
Tree-SHA512: 2a196b0e07e40a557f87a5137ede7d3984f14f48dedbec742e540c9ff1a9a762eccb317b35d102154745756cb83145ce5577495c2a2e581691edcfb0fa18553c
1ecfb891bc chore: bump MIN_MASTERNODE_PROTO_VERSION to latest proto (pasta)
Pull request description:
## Issue being fixed or feature implemented
Bump minimum master node protocol version to latest protocol.
## What was done?
## How Has This Been Tested?
## Breaking Changes
Masternodes that don't upgrade will end up getting a PoSe ban
## 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 1ecfb891bc
kwvg:
utACK 1ecfb891bc
Tree-SHA512: 18e0620370924c4f9b0c72b9f384a7b627b9d395b4a4a942d1eaabd8f4294869fb5831c8d237b825053a0ca5aa143cfbb4726312877670088333faa04ab10ef2
e50a9be1540c769a99fcdc1f7a109a6bf1c7516b Remove outdated comment on CFeeRate (Murch)
Pull request description:
This comment described how the constructor of CFeeRate was previously indirectly used to parse fee rate arguments from RPCs. The command line input was actually in sat/vB but due to the use of AmountFromValue() it got converted to BTC/vB which then got rectified in the constructor by creating a CFeeRate from that given value and COIN as the transaction size. Since this usage pattern was removed from the codebase some months ago, the comment is now obsolete.
ACKs for top commit:
michaelfolkson:
ACK e50a9be1540c769a99fcdc1f7a109a6bf1c7516b
jonatack:
ACK e50a9be1540c769a99fcdc1f7a109a6bf1c7516b
Tree-SHA512: f17bf0baeeca85a5c7883edadd407da845f6e3af1c949e93116bd67c02e601682a5f7f1ab2497172472e3acf1c4e3c234b01161a77e7d7f028e3551da34777f0
ce690847b69eb80b0232f818152dbb1db7c4c61a cli: describe quality/recency filtering in -addrinfo (Jon Atack)
7c975614c0fc6ff2084a1708a4c1f0368a4bc98f rpc: describe quality/recency filtering in getnodeaddresses (Jon Atack)
Pull request description:
Addresses #24278.
```
$ bitcoin-cli help getnodeaddresses
getnodeaddresses ( count "network" )
Return known addresses, after filtering for quality and recency.
These can potentially be used to find new peers in the network.
The total number of addresses known to the node may be higher.
```
```
$ bitcoin-cli -help | grep -A3 addrinfo
-addrinfo
Get the number of addresses known to the node, per network and total,
after filtering for quality and recency. The total number of
addresses known to the node may be higher.
```
ACKs for top commit:
mzumsande:
Thanks, Code Review ACK ce690847b69eb80b0232f818152dbb1db7c4c61a
prayank23:
reACK ce690847b6
Tree-SHA512: 82d23b15e64a99411eb8e70d7267a1b4f23182fabe072e824277569d9677e392b466be63f00e3d157d7db94bbe032d53f12ad4ab30b55b7b8a629c37d80d1d8c
62cc138ecb9cc7afcbe6fdb42b060a8f149826de Rename wallet-tool to bitcoin-wallet in code comment (Kristaps Kaupe)
0db3ad3ba41a76dff80bcb5f292e587da400ebf1 Mention -signet in bitcoin-wallet help output (Kristaps Kaupe)
Pull request description:
* Mention `-signet` in sentence where there is already `-testnet/-signet` in help output.
* Rename `wallet-tool` to `bitcoin-wallet` in single remaining place in code comments (was already done in #17648 at other places).
ACKs for top commit:
RandyMcMillan:
tACK 62cc138ecb
Tree-SHA512: c5df7811b8200f61943908dcf3b2b788fe991bf00bef28f069ab8784924556ffd5d86fc0ba2ad0b3c3f9be2ba73a34bc67059d7c057bba646c1801ffa3cb2070
fa8dad0e078c577d740a9667636733957586c035 rpc: Fix implicit-integer-sign-change in verifychain (MarcoFalke)
Pull request description:
It doesn't really make sense to treat `DEFAULT_CHECKLEVEL` as unsigned as long as `VerifyDB` accepts a signed integer.
Making it signed also avoids a cast round trip from signed->unsigned->signed in the RPC.
ACKs for top commit:
luke-jr:
utACK fa8dad0e078c577d740a9667636733957586c035
theStack:
Code-review ACK fa8dad0e078c577d740a9667636733957586c035
Tree-SHA512: 75499dbe4ace2962792e5fbec7defb10c25fdbbfde951d5e542a91daa880cc50395da0287173e2c84a28e18267c74af7b44b9f38ce364bcb0216c402f65b7641
a4da16fbd43ea1fff344f1602f7a5ace3d4a8a95 Improve -netinfo help based on feedback from users and devs (Jon Atack)
Pull request description:
Clarify which networks are displayed by the peer counts table (*reachable* networks; follow-up to #23324) in response to questions received over the past months, and a few other improvements.
ACKs for top commit:
laanwj:
Code review ACK a4da16fbd43ea1fff344f1602f7a5ace3d4a8a95
w0xlt:
ACK a4da16f
kristapsk:
utACK a4da16fbd43ea1fff344f1602f7a5ace3d4a8a95
Tree-SHA512: e6522c08421aa7f10d50723156d0a8fc5ec82cad2f0bd931bbec603077fcd4921c6505ef743d57386fba81c95dcfc77df75abf3378319886368e4ae33f9a6d73
fa29ed5b5e Merge #6456: fix(qt): allow refreshing wallet data without crashing (pasta)
758cd646a1 Merge #6452: fix: store ready queues on the mixing masternode (pasta)
395447bf30 Merge #6451: depends: update 'src/dashbls' to dashpay/bls-signatures@7e747e8a as 62fa6652 (pasta)
Pull request description:
## 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._
- [ ] 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 fa29ed5b5e
Tree-SHA512: 6a050bca13ca2e5324a6a8a7966d2d6aa3c0c97ee3c884aa35102f949dfef62e976d053cd05a549908c30e8bb6a81d996a82181852841809d8959ca78c96e823
d296005194 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 https://github.com/dashpay/dash/pull/5453.
However gui121 backport (via 25f87b9434) 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 d296005194c7bd8c65006ddf1b25052b2655c923;
Tree-SHA512: d308b3fe9c4fbbfbf2e2339aa14c825aa6f69c72d1f04dab7a14dc1c8721138beca47c7b3801db9782d6cecf2c54023a19a6d22e04b84615f9bddb0b8ec1696c
d296005194 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 https://github.com/dashpay/dash/pull/5453.
However gui121 backport (via 25f87b9434) 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 d296005194c7bd8c65006ddf1b25052b2655c923;
Tree-SHA512: d308b3fe9c4fbbfbf2e2339aa14c825aa6f69c72d1f04dab7a14dc1c8721138beca47c7b3801db9782d6cecf2c54023a19a6d22e04b84615f9bddb0b8ec1696c
08634e82c68ea1be79e1395f4f551082f497023f fix typos in logging messages (ShubhamPalriwala)
d447ded6babebe7c7948e585c9e78bf34dbef226 replace: self.nodes[0] with node (ShubhamPalriwala)
dddca3899c4738e512313a85aeb006310e34e31f test: use MiniWallet in mempool_limit.py (ShubhamPalriwala)
Pull request description:
This is a PR proposed in #20078
This PR enables running another non-wallet functional test even when the wallet is disabled thanks to the MiniWallet, i.e. it can be run even when bitcoin-core is compiled with --disable-wallet.
It also includes changes in wallet.py in the form of a new method, `create_large_transactions()` for the MiniWallet to create large transactions.
Efforts for this feature started in #20874 but were not continued and that PR was closed hence I picked this up.
To test this PR locally, compile and build bitcoin-core without the wallet and run:
```
$ test/functional/mempool_limit.py
```
ACKs for top commit:
amitiuttarwar:
ACK 08634e8, only git changes since last push (and one new line).
Zero-1729:
ACK 08634e82c68ea1be79e1395f4f551082f497023f 🧉
Tree-SHA512: 0f744ad26bf7a5a784aac1ed5077b59c95a36d1ff3ad0087ffd10ac8d5979f7362c63c20c2ce2bfa650fda02dfbcd60b1fceee049a2465c8d221cce51c20369f
fc471814dc34abb4d5479803ebb1033b572eda43 fuzz: FuzzedFileProvider::write should not return negative value (eugene)
Pull request description:
Doing so can lead to a glibc crash (from 2005 but I think it's relevant https://sourceware.org/bugzilla/show_bug.cgi?id=2074). Also the manpage for fopencookie warns against this: https://man7.org/linux/man-pages/man3/fopencookie.3.html. This would invalidate the autofile seeds (and maybe others?) in qa-assets.
On another note, I noticed that FuzzedFileProvider::seek has some confusing behavior with SEEK_END. It seems to me that if these handlers are supposed to mimic the real functions, that SEEK_END would use the offset from the end of the stream, rather than changing the offset with a random value between 0 and 4096. I could also open a PR to fix SEEK_END, but it would invalidate the seeds.
ACKs for top commit:
MarcoFalke:
cr ACK fc471814dc34abb4d5479803ebb1033b572eda43
Tree-SHA512: 9db41637f0df7f2b2407b82531cbc34f4ba9393063b63ec6786372e808fe991f7f24df45936c203fe0f9fc49686180c65ad57c2ce7d49e0c5402240616bcfede
fa6f29de516c7af5206b91b59ada466032329250 bitcoin-tx: Reject non-integral and out of range multisig numbers (MarcoFalke)
fafab8ea5e6ed6b87fac57a5cd16a8135236cdd6 bitcoin-tx: Reject non-integral and out of range sequence ids (MarcoFalke)
fa53d3d8266ad0257315d07b71b4f8a711134622 test: Check that bitcoin-tx accepts whitespace around sequence id and multisig numbers (MarcoFalke)
Pull request description:
Seems odd to silently accept arbitrary strings that don't even represent integral values.
Fix that.
ACKs for top commit:
practicalswift:
cr ACK fa6f29de516c7af5206b91b59ada466032329250
laanwj:
Code review ACK fa6f29de516c7af5206b91b59ada466032329250
Empact:
Code review ACK fa6f29de51
promag:
Code review ACK fa6f29de516c7af5206b91b59ada466032329250.
Tree-SHA512: e31f7f21fe55ac069e755557bdbcae8d5d29e20ff82e441ebdfc65153e3a31a4edd46ad3e6dea5190ecbd1b8ea5a8f94daa5d59a3b7558e46e794e30db0e6c79
dfe86b4fb2 fix: follow-up fixes (UdjinM6)
a254a7b70c refactor: sping LogAcceptCategory and LogAcceptDebug (Konstantin Akimov)
82238e6be2 refactor: Set log level in `LogAcceptCategory()` to `Debug` by default (UdjinM6)
Pull request description:
## Issue being fixed or feature implemented
#6399 introduced severity-based logging via b046e091c9. We use `LogAcceptCategory()` in quite a few places and it's always `BCLog::Level::Debug` so log level is kind of redundant for us and just makes it harder to read the code.
## What was done?
~Set log level in `LogAcceptCategory()` to `BCLog::Level::Debug` by default~. Introduce `LogAcceptDebug()` which is `LogAcceptCategory()` with `Debug` level. Simplify corresponding Dash-specific code.
## How Has This Been Tested?
## Breaking Changes
n/a
## 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:
kwvg:
utACK dfe86b4fb2
Tree-SHA512: 167da533af088c4a3bfca22abd223a2314848ec79af10f117368f6d94a4a7faa3b009477a7af455ff890f8001622494c1e3a05112f9a7204321cc237278bf387
24dcce979b 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 24dcce979b
Tree-SHA512: 69cee5401d26eec3f66166a754b8020e7f550dac4a0fdea8ec48ea1082f1286e647ac0a26a189c4d39e1a9da4e7ac36f71913684b13ea0fb4b3cfe831174970e
f25a93647b build: stop tracking cmake dependency relic_conf.h.in (Kittywhiskers Van Gogh)
62fa66524c Squashed 'src/dashbls/' changes from 4e070243ae..7e747e8a07 (Kittywhiskers Van Gogh)
b1b3840ac5 revert: stop tracking cmake dependency relic_conf.h.in (Kittywhiskers Van Gogh)
Pull request description:
## Additional Information
* Closes https://github.com/dashpay/dash/issues/6343
* Includes [bls-signatures#102](https://github.com/dashpay/bls-signatures/pull/102) and [bls-signatures#104](https://github.com/dashpay/bls-signatures/pull/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 f25a93647b
UdjinM6:
utACK f25a93647b
Tree-SHA512: 394a02a50f57538e9d12f836fd1ea1598d8a20e2d0079fcb44bb317a42a64a638a1ef906222f2d3bab06d2c0b8cfac43c6e0055d87fbdb86abe680c53ecd6b7a
24dcce979b 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 24dcce979b
Tree-SHA512: 69cee5401d26eec3f66166a754b8020e7f550dac4a0fdea8ec48ea1082f1286e647ac0a26a189c4d39e1a9da4e7ac36f71913684b13ea0fb4b3cfe831174970e
