3eaf5dbfe0 qt: Remove `QApplication::globalStrut()` call (Hennadii Stepanov)
Pull request description:
This function has been deprecated in Qt 5.15.0, and has been [removed](033d01bd6e) in Qt 6.
ACKs for top commit:
jarolrod:
ACK 3eaf5dbfe0
luke-jr:
utACK 3eaf5dbfe0
Tree-SHA512: 71ee539b6ffa3755f7e6beaa72a8937886471e298830878def6dd9f48c601611d94d52c638bc1602f938df2ba84ff8b130ea8da8e6c08ae7146173fa613a5003
0e5dedbc9e qt/wallettests: sort includes (William Casarin)
0554251d66 qt: Skip displayUnitChanged signal if unit is not actually changed (Hennadii Stepanov)
ffbc2fe459 qt, refactor: Remove default cases for scoped enum (Hennadii Stepanov)
152d5bad50 qt, refactor: Remove BitcoinUnits::valid function (Hennadii Stepanov)
aa23960fdf qt, refactor: Make BitcoinUnits::Unit a scoped enum (Hennadii Stepanov)
75832fdc37 qt: Use QVariant instead of int for BitcoinUnit in QSettings (Hennadii Stepanov)
Pull request description:
This is a rebased version of #60
Since Qt 5.5 there are [means](https://doc.qt.io/qt-5/qobject.html#Q_ENUM) to register an enum type with the meta-object system (such enum still lacks an ability to interact with [QSettings::setValue()](https://doc.qt.io/qt-5/qsettings.html#setValue) and [QSettings::value()](https://doc.qt.io/qt-5/qsettings.html#value) without defined stream operators).
In order to reduce global namespace polluting and to force strong type checking, this PR makes BitcoinUnits::Unit a scoped enum (typedef BitcoinUnits::Unit BitcoinUnit;).
No behavior change.
ACKs for top commit:
jonatack:
ACK 0e5dedbc9e, review and debug build of each commit after rebase on current master, lightly tested running the GUI, changing units a few times, and verifying persistence after restarting
promag:
Code review ACK 0e5dedbc9e
Tree-SHA512: 39ec0d7e4f0b9b25be287888121a8db6b282339674e37ec3a3554da63a9e22d6fe079e8310ca289b2a0356a19b3c7e55afa17d09dd34e0f222177f603bb053a3
343f83d088 qt, refactor: Use member initializers in TransactionStatus (w0xlt)
66d58ad7a9 qt, refactor: remove unused field `qint64 TransactionStatus::open_for` (w0xlt)
ad6adedb46 qt, refactor: remove unused parameters in `TransactionDesc::FormatTxStatus()` (w0xlt)
045f8d0310 scripted-diff: rename nDepth -> depth (w0xlt)
b1bc1431db qt, refactor: remove redundant scope in `TransactionDesc::FormatTxStatus()` (w0xlt)
Pull request description:
This PR implements the changes suggested in https://github.com/bitcoin-core/gui/issues/538#issuecomment-1021913294 .
. remove redundant scope, rename `nDepth` -> `depth`, remove unused parameters and add translator comments in `TransactionDesc::FormatTxStatus()`
. Use member initializers and remove unused field `qint64 TransactionStatus::open_for` in `TransactionStatus`.
Closes https://github.com/bitcoin-core/gui/issues/538
ACKs for top commit:
hebasto:
ACK 343f83d088, I have reviewed the code and it looks OK, I agree it can be merged.
jarolrod:
Code Review ACK 343f83d088
Tree-SHA512: cc7333d85b7eb731aa8cdd2d8dfc707341532c93e1b5e3858e8341446cf055ba055b601f9662e8d4602726b1bedf13149c46256a60a0ce1a562f94c9986d945a
88917f93cc RPC: Switch getblockfrompeer back to standard param name blockhash (Luke Dashjr)
Pull request description:
This commit partially reverts 923312fbf6.
Portion of #24294.
ACKs for top commit:
MarcoFalke:
review ACK 88917f93cc
ajtowns:
ACK 88917f93cc
jonatack:
Review-and-grep-only ACK 88917f93cc
Tree-SHA512: e42497ea6162623e449c5e60b83a5abbef568f226edc022aa14bbc1f1921618255d593968cf43f7a6d2c0bfd84cdd4b05fbce5c724759b20035e6eead758d443
4394733331 Add DEBUG_LOCKCONTENTION documentation to the developer notes (Jon Atack)
39a34b6877 Put lock logging behind DEBUG_LOCKCONTENTION preprocessor directive (Jon Atack)
Pull request description:
This is a more minimal, no-frills version of #24734 for backport. The other fixes and improvements in that pull can be done after.
*Copy of the PR 24734 description:*
PRs #22736, #22904 and #23223 changed lock contention logging from a `DEBUG_LOCKCONTENTION` compile-time preprocessor directive to a runtime `lock` log category and improved the logging output. This changed the locking from using `lock()` to `try_lock()`:
- `void Mutex::UniqueLock::lock()` acquires the mutex and blocks until it gains access to it
- `bool Mutex::UniqueLock::try_lock()` doesn't block but instead immediately returns whether it acquired the mutex; it may be used by `lock()` internally as part of the deadlock-avoidance algorithm
In theory the cost of `try_lock` might be essentially the [same](https://www.erisian.com.au/bitcoin-core-dev/log-2022-03-31.html#l-697) relative to `lock`. The test-and-set logic of these calls is purported to be ~ constant time, optimised and light/quick if used carefully (i.e. no mutex convoying), compared to system calls, memory/cache coherency and fences, wait queues, and (particularly) lock contentions. See the discussion around https://github.com/bitcoin/bitcoin/pull/22736#issuecomment-902851054 and after with respect to performance/cost aspects. However, there are reasonable concerns (see [here](https://github.com/bitcoin/bitcoin/pull/22736#discussion_r691277896) and [here](https://www.erisian.com.au/bitcoin-core-dev/log-2022-03-31.html#l-620)) that `Base::try_lock()` may be potentially [costly](https://www.erisian.com.au/bitcoin-core-dev/log-2022-03-31.html#l-700) or [risky](https://github.com/bitcoin/bitcoin/pull/22904#issuecomment-930484001) compared to `Base::lock()` in this very frequently called code.
One alternative to keep the run-time lock logging would be to gate the `try_lock` call behind the logging conditional, for example as proposed in ccd73de1dd and ACKed [here](https://github.com/bitcoin/bitcoin/pull/22736#issuecomment-901980815). However, this would add the [cost](https://github.com/bitcoin/bitcoin/pull/22736#issuecomment-910102353) of `if (LogAcceptCategory(BCLog::LOCK))` to the hotspot, instead of replacing `lock` with `try_lock`, for the most frequent happy path (non-contention).
It turns out we can keep the advantages of the runtime lock contention logging (the ability to turn it on/off at runtime) while out of prudence putting the `try_lock()` call and `lock` logging category behind a `DEBUG_LOCKCONTENTION` compile-time preprocessor directive, and also still retain the lock logging enhancements of the mentioned PRs, as suggested in https://github.com/bitcoin/bitcoin/pull/24734#issuecomment-1085785480 by W. J. van der Laan, in https://github.com/bitcoin/bitcoin/pull/22736#discussion_r691280693, and in the linked IRC discussion.
Proposed here and for backport to v23.
ACKs for top commit:
laanwj:
Code review ACK 4394733331
Tree-SHA512: 89b1271cae1dca0eb251914b1a60fc5b68320aab4a3939c57eec3a33a3c8f01688f05d95dfc31f91d71a6ed80cfe2d67b77ff14742611cc206175e47b2e5d3b1
fff91418ff refactor: Remove deduplication of data in rollingbloom bench (phyBrackets)
Pull request description:
Fixed up #24088.
ACKs for top commit:
vincenzopalazzo:
ACK fff91418ff
Tree-SHA512: 9fef617bceb74a1aec4f4a1e7c4732c4764af3e8ac2fc02b84ce370e8b97431957ca17ee8f44fb96765f7304f8d7e5bfb951440db98ba40f240612f2232d215e
b72925e7ce lint: remove qt SIGNAL/SLOT lint (fanquake)
Pull request description:
I think we are past the point where we need to lint for this, the CPU
can probably be better utilized.
ACKs for top commit:
laanwj:
ACK b72925e7ce
Tree-SHA512: 3da6e4811cdd16ff64c7e26f641f7b24f0405cc86cec36666de58691d447eca8662c924df31c6c60b3523c13590bdc62205a3237b1b1794dd8cdef35519309b3
9d65ad365c Clear vTxHashes when mapTx is cleared (Peter Bushnell)
Pull request description:
vTxHashes is a vector of all entries in mapTx, if you clear one you should clear the other, lest someone try to use the txiter in vTxHashes which would result in a segfault.
ACKs for top commit:
laanwj:
Code review ACK 9d65ad365c
Tree-SHA512: 6832755e43ab7f528b46817aeadcb6ffdc965b97f59ab96bb053dedbb7e68155ba3db52286355dca33b509237f80eda249760b26db493762bc50d8e2cef16d8f
fabdf9f870 Remove gui-only syscalls (MarcoFalke)
fa0c2aa826 init: Disable syscall sandbox in the bitcoin-qt process (MarcoFalke)
Pull request description:
It is basically impossible (and a bit out of scope) for us to maintain a sandbox for the qt library. I am not sure if it is possible to only sandbox a few threads in a process, but I doubt this will add no practical benefit anyway, so I am disabling the sandbox for the whole bitcoin-qt process.
See also https://github.com/bitcoin/bitcoin/pull/24690#issuecomment-1084372400
ACKs for top commit:
laanwj:
Code review ACK fabdf9f870
Tree-SHA512: 944ded03ee25f7dfd0bfeea9c3f97f575f2d470aa03b387b07f3e3bec5cb886e4aaa17e4a9fb359d3e670e6da69adc9111673d13e6561ec55b3161bb67dfe760
cccc4e879a Remove nHeightEnd and nHeight in generateBlocks helper (MarcoFalke)
fa38b1c8bd Remove buggy and confusing IncrementExtraNonce (MarcoFalke)
Pull request description:
IncrementExtraNonce has many issues:
* It is test-only code, but part of bitcoind
* It is using the block height of the tip, as opposed to the block's previous block as reference for the new height. See https://github.com/bitcoin/bitcoin/issues/24730#issuecomment-1085586193
* It has no use case in regtest testing. With a low difficulty the extra nonce won't be incremented. With a high difficulty the test-only functions are clumsy to handle anyway. For example, the generate* RPCs will return an empty array once they reached `maxtries`, as opposed to an error. Also the calls can't be aborted early unless the node shuts down completely. So I think it is fine to just remove the extra nonce functionality and leave it to the outside to implement, if needed. For example, a wrapper script can call the `generate*` RPCs once every second, to use the timestamp as extra nonce.
ACKs for top commit:
ajtowns:
ACK cccc4e879a
Tree-SHA512: d8a3989ad280ebd4b1b574159b3a396b8a42134347e6be3c88445162d86624d221c416456f45ae75aea62ed8c8a1a9bb3a2532924abca2ef7a879cb8e6b15654
54b39cfb34 Add release notes (stickies-v)
f959fc0397 Update /<count>/ endpoints to use a '?count=' query parameter instead (stickies-v)
a09497614e Add GetQueryParameter helper function (stickies-v)
fff771ee86 Handle query string when parsing data format (stickies-v)
c1aad1b3b9 scripted-diff: rename RetFormat to RESTResponseFormat (stickies-v)
9f1c54787c Refactoring: move declarations to rest.h (stickies-v)
Pull request description:
In RESTful APIs, [typically](https://rapidapi.com/blog/api-glossary/parameters/query/) path parameters (e.g. `/some/unique/resource/`) are used to represent resources, and query parameters (e.g. `?sort=asc`) are used to control how these resources are being loaded through e.g. sorting, pagination, filtering, ...
As first [discussed in #17631](https://github.com/bitcoin/bitcoin/pull/17631#discussion_r733031180), the [current REST api](https://github.com/bitcoin/bitcoin/blob/master/doc/REST-interface.md) contains two endpoints `/headers/` and `/blockfilterheaders/` that rather unexpectedly use path parameters to control how many (filter) headers are returned in the response. While this is no critical issue, it is unintuitive and we are still early enough to easily phase this behaviour out and ensure new endpoints (if any) do not have to stick to non-standard behaviour just for internal consistency.
In this PR, a new `HTTPRequest::GetQueryParameter` method is introduced to easily parse query parameters, as well as two new `/headers/` and `/blockfilterheaders/` endpoints that use a count query parameter are introduced. The old path parameter-based endpoints are kept without too much overhead, but the documentation now points to the new query parameter-based endpoints as the default interface to encourage standardness.
## Behaviour change
### New endpoints and default values
`/headers/` and `/blockfilterheaders/` now have 2 new endpoints that contain query parameters (`?count=<count>`) instead of path parameters (`/<count>/`), as described in REST-interface.md. Since query parameters can easily have default values, I have set this at 5 for both endpoints.
**headers**
`GET /rest/headers/<BLOCK-HASH>.<bin|hex|json>?count=<COUNT=5>`
should now be used instead of
`GET /rest/headers/<COUNT>/<BLOCK-HASH>.<bin|hex|json>`
**blockfilterheaders**
`GET /rest/blockfilterheaders/<FILTERTYPE>/<BLOCK-HASH>.<bin|hex|json>?count=<COUNT=5>`
should now be used instead of
`GET /rest/blockfilterheaders/<FILTERTYPE>/<COUNT>/<BLOCK-HASH>.<bin|hex|json>`
### Some previously invalid API calls are now valid
API calls that contained query strings in the URI could not be parsed prior to this PR. This PR changes behaviour in that previously invalid calls (e.g. `GET /rest/headers/5/somehash.json?someunusedparam=foo`) would now become valid, as the query parameters are properly parsed, and discarded if unused.
For example, prior to this PR, adding an irrelevant `someparam` parameter would be illegal:
```
GET /rest/headers/5/0000004c6aad0c89c1c060e8e116dcd849e0554935cd78ff9c6a398abeac6eda.json?someparam=true
->
Invalid hash: 0000004c6aad0c89c1c060e8e116dcd849e0554935cd78ff9c6a398abeac6eda.json?someparam=true
```
**This behaviour change affects all rest endpoints, not just the 2 new ones introduced here.**
*(Note: I'd be open to implementing additional logic to refuse requests containing unrecognized query parameters to minimize behaviour change, but for the endpoints that we currently have I don't really see the point for that added complexity. E.g. I don't see any scenarios where misspelling a parameter could lead to harmful outcomes)*
## Using the REST API
To run the API HTTP server, start a bitcoind instance with the `-rest` flag enabled. To use the
`blockfilterheaders` endpoint, you'll also need to set `-blockfilterindex=1`:
```
./bitcoind -signet -rest -blockfilterindex=1
```
As soon as bitcoind is fully up and running, you should be able to query the API, for example by
using curl on the command line: ```curl "127.0.0.1:38332/rest/chaininfo.json"```.
To more easily parse the JSON output, you can also use tools like 'jq' or `json_pp`, e.g.:
```
curl -s "localhost:38332/rest/blockfilterheaders/basic/0000004c6aad0c89c1c060e8e116dcd849e0554935cd78ff9c6a398abeac6eda.json?count=2" | json_pp .
```
## To do
- [x] update `doc/release-notes`
## Feedback
This is my first PR (hooray!). Please don't hold back on any feedback/comments/nits/... you may have, big or small, whether they are code, process, language, ... related. I welcome private messages too if there's anything you don't want to clutter the PR with. I'm here to learn and am grateful for everyone's input.
ACKs for top commit:
stickies-v:
I've had to push a tiny doc update to `REST-interface.md` (`git range-diff 219d728 9aac438 54b39cf`) since this was not merged for v23, but since there are no significant changes beyond theStack and jnewbery's ACKs I think this PR is now ready to be considered for merging? @MarcoFalke
jnewbery:
ACK 54b39cfb34
theStack:
re-ACK 54b39cfb34
Tree-SHA512: 3b393ffde34f25605ca12c0b1300799a19684b816a1d03aed38b0f5439df47bfe6a589ffbcd7b83fd2def6c9d00a1bae5e45b1d18df4ae998c617c709990f83f
Package validation policy only differs from individual policy in its
evaluation of feerate. Minimize DoS surface; don't validate all over
again if we know the result will be the same.
This avoids "parents pay for children" and "siblings pay for siblings"
behavior, since package feerate is calculated with totals and is
topology-unaware.
It also ensures that package validation never causes us to reject a
transaction that we would have otherwise accepted in single-tx
validation.
In most RESTful APIs, path parameters are used to represent resources, and
query parameters are used to control how these resources are being filtered/sorted/...
The old /<count>/ functionality is kept alive to maintain backwards compatibility,
but new paths with query parameters are introduced and documented as the default
interface so future API methods don't break consistency by using query parameters.
fa9112aac0 Remove utxo db upgrade code (MarcoFalke)
Pull request description:
It is not possible to upgrade Bitcoin Core pre-segwit (pre-0.13.1) to a recent version without a full IBD from scratch after commit 19a56d1519 (released in version 22.0).
Any Bitcoin Core version with the new database format after commit 1088b02f0c (released in version 0.15), can upgrade to any version that is supported as of today.
This leaves the versions 0.13.1-0.14.x. Even though those versions are unsupported, some users with an existing datadir may want to upgrade to a recent version. However, it seems reasonable to simply ask them to `-reindex` to run a full IBD from scratch. This allows us to remove the utxo db upgrade code.
ACKs for top commit:
Sjors:
re-ACK fa9112aac0
laanwj:
Code review ACK fa9112aac0
Tree-SHA512: 4243bb35df9ac4892f9fad30fe486d338745952bcff4160bcb0937c772d57b13b800647da14695e21e3655e85ee0d95fa3dc7789ee309d59ad84f422297fecb8
2da94a4c6f fuzz: add a fuzz target for Miniscript decoding from Script (Antoine Poinsot)
f8369996e7 Miniscript: ops limit and stack size computation (Pieter Wuille)
2e55e88f86 Miniscript: conversion from script (Pieter Wuille)
1ddaa66eae Miniscript: type system, script creation, text notation, tests (Pieter Wuille)
4fe29368c0 script: expose getter for CScriptNum, add a BuildScript helper (Antoine Poinsot)
f4e289f384 script: move CheckMinimalPush from interpreter to script.h (Antoine Poinsot)
31ec6ae92a script: make IsPushdataOp non-static (Antoine Poinsot)
Pull request description:
Miniscript is a language for writing (a subset of) Bitcoin Scripts in a structured way.
Miniscript permits:
- To safely extend the Output Descriptor language to many more scripting features thanks to the typing system (composition).
- Statical analysis of spending conditions, maximum spending cost of each branch, security properties, third-party malleability.
- General satisfaction of any correctly typed ("valid" [0]) Miniscript. The satisfaction itself is also analyzable.
- To extend the possibilities of external signers, because of all of the above and since it carries enough metadata.
Miniscript guarantees:
- That for any statically-analyzed as "safe" [0] Script, a witness can be constructed in the bounds of the consensus and standardness rules (standardness complete).
- That unless the conditions of the Miniscript are met, no witness can be created for the Script (consensus sound).
- Third-party malleability protection for the satisfaction of a sane Miniscript, which is too complex to summarize here.
For more details around Miniscript (including the specifications), please refer to the [website](https://bitcoin.sipa.be/miniscript/).
Miniscript was designed by Pieter Wuille, Andrew Poelstra and Sanket Kanjalkar.
This PR is an updated and rebased version of #16800. See [the commit history of the Miniscript repository](https://github.com/sipa/miniscript/commits/master) for details about the changes made since September 2019 (TL;DR: bugfixes, introduction of timelock conflicts in the type system, `pk()` and `pkh()` aliases, `thresh_m` renamed to `multi`, all recursive algorithms were made non-recursive).
This PR is also the first in a series of 3:
- The first one (here) integrates the backbone of Miniscript.
- The second one (#24148) introduces support for Miniscript in Output Descriptors, allowing for watch-only support of Miniscript Descriptors in the wallet.
- The third one (#24149) implements signing for these Miniscript Descriptors, using Miniscript's satisfaction algorithm.
Note to reviewers:
- Miniscript is currently defined only for P2WSH. No Taproot yet.
- Miniscript is different from the policy language (a high-level logical representation of a spending policy). A policy->Miniscript compiler is not included here.
- The fuzz target included here is more interestingly extended in the 3rd PR to check a script's satisfaction against `VerifyScript`. I think it could be further improved by having custom mutators as we now have for multisig (see https://github.com/bitcoin/bitcoin/issues/23105). A minified corpus of Miniscript Scripts is available at https://github.com/bitcoin-core/qa-assets/pull/85.
[0] We call "valid" any correctly-typed Miniscript. And "safe" any sane Miniscript, ie one whose satisfaction isn't malleable, which requires a key for any spending path, etc..
ACKs for top commit:
jb55:
ACK 2da94a4c6f
laanwj:
Light code review ACK 2da94a4c6f (mostly reviewed the changes to the existing code and build system)
Tree-SHA512: d3ef558436cfcc699a50ad13caf1e776f7d0addddb433ee28ef38f66ea5c3e581382d8c748ccac9b51768e4b95712ed7a6112b0e3281a6551e0f325331de9167
7b00595d33 build: stop overriding user CXXFLAGS (fanquake)
3e2ef23c3e build: stop overriding user LDFLAGS (fanquake)
35c3fd43c3 build: stop overriding user CPPFLAGS (fanquake)
bc7cc57607 doc: explain why we clear CXXFLAGS with enable-debug (fanquake)
Pull request description:
Historically our build system has hijacked `CXXFLAGS` and friends, and this has always been a source of complaints from users and developers. With this PR, we move away from using `CXXFLAGS`, `CPPFLAGS` and `LDFLAGS`, and instead use `CORE_*FLAGS` variables for our flags / options, leaving autoconfs `FLAG` vars to the user.
Note that there are currently two cases where we will at least clear `CXXFLAGS` (if not alreaddy overridden by the user), when doing debugging or when coverage is enabled, to avoid Autoconfs `-g -O2` CXXFLAG default.
ACKs for top commit:
hebasto:
ACK 7b00595d33
Tree-SHA512: bda936a7aa8f98a1bf1552306845cb4bbab54e19a7a0b9ce3210e10fef70db146e9fe42a0cc8c50b2908506771b5b96f39c334e41323b70ec878e4010373096c
e9d277131c lint: Convert lint-logs.sh to Python (Dimitri)
Pull request description:
A port of `/test/lint/lint-logs.sh` to a Python-script as part of the request of #24783 . Checked for output-consistency.
Removed all non-explicit exceptions (i.e. `...`, `LogPrint()`, and `LogPrintf()`) because they weren't needed anymore, except for one single case in a comment in `/src/random.cpp` which I removed because it was quite useless anyway (the comment, not the file).
ACKs for top commit:
laanwj:
Code review ACK e9d277131c
Tree-SHA512: ae4d2a341a13ccd9f40e8fcde35e1f392d9995131be005b809cbf8f283f28a7c34ea3cf9c13d3564d13809ae3f5889260fa5d6302370dc79c3226389974d947c
c71117fcb0 net: remove non-blocking bool from interface (Bushstar)
Pull request description:
SetSocketNonBlocking was added in 0.11 in the PR below with a second argument to toggle non-blocking mode for the socket. That argument has always been set to true in all subsequent releases and I'm not sure why it is present.
https://github.com/bitcoin/bitcoin/pull/4491
ACKs for top commit:
promag:
Code review ACK c71117fcb0.
lsilva01:
Code review ACK c71117fcb0
vasild:
ACK c71117fcb0
Tree-SHA512: feebfcfa75d997460a0ba42ffe1e0c25a7e0bfcad12510ad73ea4942cc1c653f9ad429adbbb00b9288fe319009552906fcb635a14dfd7dcbde3853baab6be065
fa32cc0682 doc: Remove fee delta TODO from txmempool.cpp (MarcoFalke)
Pull request description:
This refactor request was added in commit eb306664e7, though it didn't explain why the refactor is needed and what the goal is. Given that this wasn't touched for more than 5 years, it doesn't seem critical. Generally, non-trivial `TODO`s make more sense as GitHub issues, so that they can be discussed and triaged more easily.
ACKs for top commit:
laanwj:
Code review ACK fa32cc0682
Tree-SHA512: 6629fef543e815136c82c38aa8ba2c4de68a5fe94c6954f2559e468f7e59052e02dd7c221d3b159be0314eaf0dbb18f74814297c58f76e2289c47e8d4f49be4e
a4f4f89815 Replace uint256 specific implementations of base_uint::GetHex() and base_uint::SetHex() with proper ones that don't depend on uint256 and replace template methods instantiations of base_uint with template class instantiation (Samer Afach)
Pull request description:
The current implementations of `SetHex()` and `GetHex()` in `base_uint` use `arith_uint256`'s implementations. Which means, any attempt to create anything other than `arith_uint256` (say `arith_uint512`) and using any of these functions (which is what I needed in my application) will just not work and will cause compilation errors (besides the immediate linking errors due to templates being in source files instantiated only for 256) because there's no viable conversion from `arith_uint256` and any of the other possible types. Besides that these function will yield wrong results even if the conversion is possible depending on the size. This is fixed in this PR.
ACKs for top commit:
laanwj:
re-ACK a4f4f89815
Tree-SHA512: 92a930fb7ddec5a5565deae2386f7d2d84645f9e8532f8d0c0178367ae081019b32eedcb59cc11028bac0cb15d9883228e016a466b1ee8fc3c6377b4df1d4180
0cea7b10f1 print `(none)` if no warnings in -getinfo (/dev/fd0)
Pull request description:
Adds `(none)` in warnings when no warnings returned by -getinfo
Reviewers can test this by making the following change in `/src/warnings.cpp`:
```diff
bilingual_str GetWarnings(bool verbose)
{
bilingual_str warnings_concise;
std::vector<bilingual_str> warnings_verbose;
LOCK(g_warnings_mutex);
// Pre-release build warning
if (!CLIENT_VERSION_IS_RELEASE) {
- warnings_concise = _("This is a pre-release test build - use at your own risk - do not use for mining or merchant applications");;
+ warnings_concise = _("");;
```
Before this pull request:
```
$ bitcoin-cli -getinfo
Chain: regtest
Blocks: 0
Headers: 0
Verification progress: 100.0000%
Difficulty: 4.656542373906925e-10
Network: in 0, out 0, total 0
Version: 239900
Time offset (s): 0
Proxies: n/a
Min tx relay fee rate (BTC/kvB): 0.00001000
Warnings:
```
After this pull request:
```diff
$ bitcoin-cli -getinfo
Chain: regtest
Blocks: 0
Headers: 0
Verification progress: 100.0000%
Difficulty: 4.656542373906925e-10
Network: in 0, out 0, total 0
Version: 239900
Time offset (s): 0
Proxies: n/a
Min tx relay fee rate (BTC/kvB): 0.00001000
Warnings: (none)
```
ACKs for top commit:
jonatack:
ACK 0cea7b10f1
laanwj:
Tested ACK 0cea7b10f1
Tree-SHA512: a12499d11ff84bc954db354f968eb1f5ee4999d8b80581fe0bdf604732b2e2f608cb5c35c4ca8cb5a430f3991954a6207f0758302618662e6b9505044cf2dc95
63125752a9 qt: Update deprecated enum value (Hennadii Stepanov)
c7add881a6 qt: Use `|` instead of `+` for key modifiers (Hennadii Stepanov)
6f1e162fe1 qt: Fix headers (Hennadii Stepanov)
Pull request description:
For Qt 5 all changes in this PR are refactoring. But for [Qt 6](https://github.com/bitcoin/bitcoin/pull/24798) they are real bugfixes :)
As I do not provide anyway way to build `bitcoin-qt` against Qt 6.2.4 fir now, suggesting to reviewers to verify changes for Qt 5 only.
ACKs for top commit:
shaavan:
ACK 63125752a9
jarolrod:
tACK 63125752a9
Tree-SHA512: ceee983192ddf62f09c1305458af3447ff0e3bd90311fa6328b139673bcaed3407dc0ce0b275028d4e0ca251d6b54dad40b48049211aeb251f65cbb4f5330834
d025d7f025 gui, refactor: rename fInvalid to num_test_failures in test_main.cpp (Jon Atack)
2489b6fe9c gui: count test failures in test runner summary (Jon Atack)
ba44aae768 gui: add test runner summary (Jon Atack)
Pull request description:
Append a one-line summary to the output of running `./src/qt/test/test_bitcoin-qt` indicating that all tests passed or showing the number of failing tests. It's currently a bit inconvenient to see this result by eyeballing all of the output.
ACKs for top commit:
shaavan:
ACK d025d7f025
jarolrod:
tACK d025d7f025
Tree-SHA512: 981c5daa13db127d38167bcf78b296b1a7e5b2d12e65f364ec6382b24f1008a223521d3b6c56e920bcd037479da5414e43758794688019d09e9aa696f3964746
51708c4516 gui: peersWidget - ResizeToContents Age and IP/Netmask columns (randymcmillan)
209301a442 gui: add Age column to peers tab (randymcmillan)
127de22c5f gui: add FormatPeerAge() utility helper (Jon Atack)
Pull request description:
This change adds an "Age" column to the peers table view,
which displays the duration of each peer's connection.
ACKs for top commit:
jonatack:
re-ACK 51708c4516
Jamewood:
> re-ACK 51708c4
shaavan:
reACK 51708c4516
hebasto:
ACK 51708c4516, I have reviewed the code and it looks OK, I agree it can be merged.
Tree-SHA512: 27323f7080ec0d3fcdbf1b190fba1cd2d7406840ab6607c221cf8af950db9134e22721cc5a88f4fc4f390d8b05e98bc4b7521661a31fadad9e2c6c6390e71788
404c53062b key: use secp256k1_schnorrsig_sign32 over deprecated secp256k1_schnorrsig_sign (fanquake)
ee30bf7c01 build: remove some no-longer-needed var unexporting from configure (fanquake)
2656629767 build: remove --enable-experimental from libsecp256k1 configure (fanquake)
d960d4fd3a build: fix MSVC build after subtree update (dhruv)
afb7a6fe06 Squashed 'src/secp256k1/' changes from 0559fc6e41..8746600eec (fanquake)
Pull request description:
The motivation for this bump is some small build cleanups, including [dropping the `--enable-experimental`](80cf4eea5f) flag from the libsecp configure invocation, as well as some [now-redundant](https://github.com/bitcoin-core/secp256k1/pull/1090) `pkg-config` variable exporting from our own configure. We also get the benefit of a slightly more efficient libsecp configure due to https://github.com/bitcoin-core/secp256k1/pull/1088.
This also includes a change in our code to migrate from using the [now deprecated](99e6568fc6) `secp256k1_schnorrsig_sign` to `secp256k1_schnorrsig_sign32`.
Guix Build (on x86_64):
```bash
b9f6ad90c75f7edd7c4444c6c3401d8b6ab29a8da22ae22ddaedd94688227b5d guix-build-404c53062bb8/output/aarch64-linux-gnu/SHA256SUMS.part
250d47ae299d8385d5590518fa2adaabde76e2566fd27e12bf36b62663d13e13 guix-build-404c53062bb8/output/aarch64-linux-gnu/bitcoin-404c53062bb8-aarch64-linux-gnu-debug.tar.gz
48d610dc6f5169f925f782571dac2f082695f89008beadad4adef4c1b583a612 guix-build-404c53062bb8/output/aarch64-linux-gnu/bitcoin-404c53062bb8-aarch64-linux-gnu.tar.gz
8f04ee26e4079719e3935bd0e4287cc11a2a16875bf01e2a63d67492a1fa5367 guix-build-404c53062bb8/output/arm-linux-gnueabihf/SHA256SUMS.part
7d7d7fcfb032bda92e53abd8d608257f0ef17b1e3e52a1414260b896786fb2dc guix-build-404c53062bb8/output/arm-linux-gnueabihf/bitcoin-404c53062bb8-arm-linux-gnueabihf-debug.tar.gz
30bae2ff3d044f4e39f992a68f6b296b7be2aea350bca4a0415c739a32c20bd9 guix-build-404c53062bb8/output/arm-linux-gnueabihf/bitcoin-404c53062bb8-arm-linux-gnueabihf.tar.gz
5f550fb0b950250eeffce3480ec6403530b0880570a5860ef6c32a3e92eac92f guix-build-404c53062bb8/output/arm64-apple-darwin/SHA256SUMS.part
c10664d13aeec8c860bf72be833c738973ae18e4d28cdf08b2f9bee960ebff1d guix-build-404c53062bb8/output/arm64-apple-darwin/bitcoin-404c53062bb8-arm64-apple-darwin-unsigned.dmg
becab75b11cf4ca6f559f8eef835f3574629f6eb932ac716ed4f8c044a85831f guix-build-404c53062bb8/output/arm64-apple-darwin/bitcoin-404c53062bb8-arm64-apple-darwin-unsigned.tar.gz
bc86433652fe3552f6a13088191364ae7514c9fe3a244da86a6db096bb4922fc guix-build-404c53062bb8/output/arm64-apple-darwin/bitcoin-404c53062bb8-arm64-apple-darwin.tar.gz
1f585cb9a1356343df4b2726ecfe2598c9903304afb047c047c2cef318555dd3 guix-build-404c53062bb8/output/dist-archive/bitcoin-404c53062bb8.tar.gz
9ede534ba2c6cecb550473eead195627327e826ebb0118e23d60ab482d40e241 guix-build-404c53062bb8/output/powerpc64-linux-gnu/SHA256SUMS.part
77ddb7d7d639b1dd4508468a8ef27e45b35c8b2f8624584a70e6b64798a4ea7a guix-build-404c53062bb8/output/powerpc64-linux-gnu/bitcoin-404c53062bb8-powerpc64-linux-gnu-debug.tar.gz
36178c1f1c12942ff05275daa3570f8b45419ee8d9f391d750afb405219986f0 guix-build-404c53062bb8/output/powerpc64-linux-gnu/bitcoin-404c53062bb8-powerpc64-linux-gnu.tar.gz
8a15a4da7a9a5e00c49d9aeedf3c6fc666c0d230be1369eac7caf4571d5905e0 guix-build-404c53062bb8/output/powerpc64le-linux-gnu/SHA256SUMS.part
400c58113f2d07c87e03c8528b292c6aca808a2bccae4b041cad3a26a05b6aad guix-build-404c53062bb8/output/powerpc64le-linux-gnu/bitcoin-404c53062bb8-powerpc64le-linux-gnu-debug.tar.gz
3b9f9d8614ac3a27416e53354b2b0a64d364f91493e9d0f41583a6f492546824 guix-build-404c53062bb8/output/powerpc64le-linux-gnu/bitcoin-404c53062bb8-powerpc64le-linux-gnu.tar.gz
98506b23ee08ad8af958f816da2e4518d661e88d5c6308de1f5e3b2fc787b86c guix-build-404c53062bb8/output/riscv64-linux-gnu/SHA256SUMS.part
c701a7b77cea4fdc2588b511f1b2c71b89c83bfba19fdb2ac113a5a4b14ac392 guix-build-404c53062bb8/output/riscv64-linux-gnu/bitcoin-404c53062bb8-riscv64-linux-gnu-debug.tar.gz
34d58e6392cd58b3c76e30cd8600c0dbefba7e9c6d5df78c3ef23e81c4e4d26a guix-build-404c53062bb8/output/riscv64-linux-gnu/bitcoin-404c53062bb8-riscv64-linux-gnu.tar.gz
92fa30e9c6d81dd1e1514b65d3e1abe68ded897237cd99f66aa760d445109c04 guix-build-404c53062bb8/output/x86_64-apple-darwin/SHA256SUMS.part
bee180b02f178ae9980ef159f65913a71cbd037c4aff5f2906af5f174a677da3 guix-build-404c53062bb8/output/x86_64-apple-darwin/bitcoin-404c53062bb8-x86_64-apple-darwin-unsigned.dmg
ad7d18d779ab7a7944817d1f368d0a6bdd174bf1211b0f90180c8ccf04ec4062 guix-build-404c53062bb8/output/x86_64-apple-darwin/bitcoin-404c53062bb8-x86_64-apple-darwin-unsigned.tar.gz
7489d1d5d48ad95cf58bb11b5fdeccadac6fa758784fb498529fca2330abe069 guix-build-404c53062bb8/output/x86_64-apple-darwin/bitcoin-404c53062bb8-x86_64-apple-darwin.tar.gz
74660fb0ebce2a08b03980a57bffcad62e078dc967a74d2395660ff51c019640 guix-build-404c53062bb8/output/x86_64-linux-gnu/SHA256SUMS.part
cd377fa6b46276c2f8a32e199e6f9adf6aa67315688656709d6dc0744d54a837 guix-build-404c53062bb8/output/x86_64-linux-gnu/bitcoin-404c53062bb8-x86_64-linux-gnu-debug.tar.gz
919c521950369d8ad46db2d15b00abb488abfb080d157a41b2db429122a428ed guix-build-404c53062bb8/output/x86_64-linux-gnu/bitcoin-404c53062bb8-x86_64-linux-gnu.tar.gz
2debca995d432965a8786b6ff74aed42e9e2f1cb0fecbe2d9fc5b850c192fcff guix-build-404c53062bb8/output/x86_64-w64-mingw32/SHA256SUMS.part
e33169f684fb031ec18ed39812617d3eb263257f6c7564b8f4c974ad05fe672c guix-build-404c53062bb8/output/x86_64-w64-mingw32/bitcoin-404c53062bb8-win64-debug.zip
029d0a4180cb908d517fcf689dcf46d42fbf383e11dc609711617066ae039ab0 guix-build-404c53062bb8/output/x86_64-w64-mingw32/bitcoin-404c53062bb8-win64-setup-unsigned.exe
7e349c688cac66436562c4805f420b0536db5a3b3abf54d0e8c7752f59874a5c guix-build-404c53062bb8/output/x86_64-w64-mingw32/bitcoin-404c53062bb8-win64-unsigned.tar.gz
1bff98e82e95c93d6060227408502f5e2d8597d526b912cb6dc0a90ae3094a8f guix-build-404c53062bb8/output/x86_64-w64-mingw32/bitcoin-404c53062bb8-win64.zip
```
ACKs for top commit:
laanwj:
Code review ACK 404c53062b, I checked the changes to our tree thoroughly but didn't review all upstream secp256k1 changes in detail.
gruve-p:
ACK 404c53062b
real-or-random:
utACK 404c53062b I reviewed the diff to Core, I'm with updating to libsecp256k1 master, but I haven't verified that the libsecp256k1 tree here has been updated correctly
Tree-SHA512: e6a6db93ea60ed500df5065178784a915da94adfa7bd45fdbd7b19d701154987ff38c1df7f318119e6c2cb98e28e1ea2eb725bef93d4088403e14537ebffb032
This change is preparation for Qt 6, and it fixes an experimental build
with Qt 6.2.4.
The `Qt::ItemIsTristate` value has been deprecated since 5.6.0 (see
ae8406d82f541f6d9112bdac192e5e4e114d56aa upstream commit).