nValue is the sum of the intended recipient amounts, so name it that for
clarity.
nValueToSelect is the coin selection target value, so name it
selection_target for clarity.
c7bd5842e4 MOVEONLY: CWallet transaction code out of wallet.cpp/.h (Russell Yanofsky)
Pull request description:
This commit just moves function without making any changes. It can be reviewed with `git log -p -n1 --color-moved=dimmed_zebra`
Motivation for this change is to make `wallet.cpp/h` less monolithic and start to make wallet transaction state tracking comprehensible so bugs in https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Wallet-Transaction-Conflict-Tracking can be fixed safely without introducing new problems.
This moves wallet classes and methods that deal with transactions out of `wallet.cpp/.h` into better organized files:
- `transaction.cpp/.h` - CWalletTx and CMerkleTx class definitions
- `receive.cpp/.h` - functions checking received transactions and computing balances
- `spend.cpp/.h` - functions creating transactions and finding spendable coins
After #20773, when loading is separated from syncing it will also be possible to move more `wallet.cpp/.h` functions to:
- `sync.cpp/.h` - functions handling chain notifications and rescanning
This commit arranges `receive.cpp` and `spend.cpp` functions in dependency order so it's possible to skim `receive.cpp` and get an idea of how computing balances works, and skim `spend.cpp` and get an idea of how transactions are created, without having to jump all over `wallet.cpp` where functions are not in order and there is a lot of unrelated code.
Followup commit "refactor: Detach wallet transaction methods" in https://github.com/bitcoin/bitcoin/pull/21206 follows up this PR and tweaks function names and arguments to reflect new locations. The two commits are split into separate PRs because this commit is more work to maintain and less work to review, while the other commit is less work to maintain and more work to review, so hopefully this commit can be merged earlier.
ACKs for top commit:
Sjors:
re-utACK c7bd5842e4
fjahr:
utACK c7bd5842e4
promag:
Code review ACK c7bd5842e4, verified move only claim.
meshcollider:
Dimmed-zebra-check and functional test run ACK c7bd5842e4
Tree-SHA512: 4981de6911cb1196774db375494355cc9af59b52456129c002d264a77cd9ed6175f8ecbb6b2f492a59a4d5a0def21a39d96fa79c9f4d99be0992985f553be32f
4935ac583b qt: Improve GUI responsiveness (Hennadii Stepanov)
75850106ae qt, macos: Fix GUIUtil::PolishProgressDialog bug (Hennadii Stepanov)
Pull request description:
[`QProgressDialog`](https://doc.qt.io/qt-5/qprogressdialog.html) estimates the time the operation will take (based on time for steps), and only shows itself if that estimate is beyond [`minimumDuration`](https://doc.qt.io/qt-5/qprogressdialog.html#minimumDuration-prop).
The default `minimumDuration` value is [4 seconds](https://doc.qt.io/qt-5/qprogressdialog.html#details), and it could make users think that the GUI is frozen.
This PR sets `minimumDuration` to zero for all progress dialogs, that affects ones in the `WalletControllerActivity` class.
ACKs for top commit:
ryanofsky:
Code review ACK 4935ac583b. I'm not very familiar with this API but all the changes and explanations make sense and are very clear, and this seems like it should be an improvement.
promag:
Code review ACK 4935ac583b.
jarolrod:
ACK 4935ac583b
Tree-SHA512: 2ddd74e7fd87894d341d2439dbaa544d031a350f7f57d4c7e9fbba977dc24080fe60fd7a80a542b1647f1de9091d7fd04a36eab695088d4d75fb836548e99b5f
Introduce the maxuploadtarget option to the example bitcoin.conf file. This adds visibility for this option which is useful to those looking to configure bandwidth usage.
c231254a65 qt: Make TransactionView aware of runtime palette change (Hennadii Stepanov)
2b622d4ace qt: Make CoinControlDialog aware of runtime palette change (Hennadii Stepanov)
97a6b5e06a qt: Make OverviewPage aware of runtime palette change (Hennadii Stepanov)
d05f1b278d qt: Make UnitDisplayStatusBarControl aware of runtime palette change (Hennadii Stepanov)
6b2ce65392 qt: Replace base class of ClickableLabel with ThemedLabel (Hennadii Stepanov)
ff530a2093 qt: Use GUIUtil::ThemedLabel class (Hennadii Stepanov)
d99ef327a8 qt: Add GUIUtil::ThemedLabel class (Hennadii Stepanov)
c054720e08 qt: Make SignVerifyMessageDialog aware of runtime palette change (Hennadii Stepanov)
0dcc3fac43 qt: Make SendCoinsEntry aware of runtime palette change (Hennadii Stepanov)
fa18d28e12 qt: Make RPCConsole aware of runtime palette change (Hennadii Stepanov)
f1083826e3 qt: Make BitcoinGUI aware of runtime palette change (Hennadii Stepanov)
ce17861dc4 qt: Make PlatformStyle aware of runtime palette change (Hennadii Stepanov)
Pull request description:
On macOS switching appearance (Light -> Dark or Dark -> Light) when Bitcoin Core is running makes the GUI pretty unusable.
This bug is especially important when a user chose the "Auto" mode to adjust appearance automatically.
This PR fixes Bitcoin Core behavior.
This is an alternative to #268.
ACKs for top commit:
Sjors:
tACK c231254a65 on macOS 11.4
goums:
ACK c231254a65
promag:
Tested ACK c231254a65 on macOS Big Sur arm64.
jarolrod:
tACK c231254a65
Tree-SHA512: 122dda3e4c9703f68cec60613c536ca59d04c93f2c03398559f2361b8d279ae534800e8e677d94a33e10e769d00be54295a704e98afa2e986a06146b9f164854
`CAddrMan` uses `std::map` internally even though it does not require
that the map's elements are sorted. `std::map`'s access time is
`O(log(map size))`. `std::unordered_map` is more suitable as it has a
`O(1)` access time.
This patch lowers the execution times of `CAddrMan`'s methods as follows
(as per `src/bench/addrman.cpp`):
```
AddrMan::Add(): -3.5%
AddrMan::GetAddr(): -76%
AddrMan::Good(): -0.38%
AddrMan::Select(): -45%
```
7d07192dde Add src/qt/android/.gitignore (Hennadii Stepanov)
Pull request description:
This PR makes `git` ignore files created by `make apk`.
ACKs for top commit:
icota:
ACK 7d07192dde
Tree-SHA512: 4be20bd84830217a10d8ea7634799e71ed50be73f4f60c91c56311a2c95b22ff1f28d3b7bc077f1417318bb75e446e3fc3bdbf9dbc037b4cbc8428f0875f2c77
7e2a9890e5 depends: latest config.sub (2021-04-30) (fanquake)
f16d4cd8c5 depends: latest config.guess (2021-05-24) (fanquake)
Pull request description:
This is split out of #21851. Updating these files should be mechanical, and shouldn't have to wait for that PR. Also, having support in depends for the new `arm-apple-darwin` target (added in [2593751ef276497e312d7c4ce7fd049614c7bf80](https://git.savannah.gnu.org/cgit/config.git/commit/?id=2593751ef276497e312d7c4ce7fd049614c7bf80)) is useful when debugging. i.e #22070.
If you try and compile depends for a `arm-apple-darwin` target using master, on a x86_64 darwin machine, currently you'll get:
```bash
gmake -C depends -j9 HOST=arm64-apple-darwin
Invalid configuration `arm64-apple-darwin': machine `arm64-apple' not recognized
shasum: hosts/.mk: No such file or directory
<omitted>
Makefile:111: hosts/.mk: No such file or directory
gmake: *** No rule to make target 'hosts/.mk'. Stop.
```
ACKs for top commit:
laanwj:
ACK 7e2a9890e5
Tree-SHA512: 8ed99b5d486c6cbca8929a752460338b6ee17f6bf93013c76589605678853c3a01ebd631b4d3f5d6aaeb6e5c21b7bbe39afc4454d3a697fafb27678f6d2c021e
13650fe2e5 [policy] detect unsorted packages (glozow)
9ef643e21b [doc] add release note for package testmempoolaccept (glozow)
c4259f4b7e [test] functional test for packages in RPCs (glozow)
9ede34a6f2 [rpc] allow multiple txns in testmempoolaccept (glozow)
ae8e6df709 [policy] limit package sizes (glozow)
c9e1a26d1f [fuzz] add ProcessNewPackage call in tx_pool fuzzer (glozow)
363e3d916c [test] unit tests for ProcessNewPackage (glozow)
cd9a11ac96 [test] make submit optional in CreateValidMempoolTransaction (glozow)
2ef187941d [validation] package validation for test accepts (glozow)
578148ded6 [validation] explicit Success/Failure ctors for MempoolAcceptResult (glozow)
b88d77aec5 [policy] Define packages (glozow)
249f43f3cc [refactor] add option to disable RBF (glozow)
897e348f59 [coins/mempool] extend CCoinsViewMemPool to track temporary coins (glozow)
42cf8b25df [validation] make CheckSequenceLocks context-free (glozow)
Pull request description:
This PR enables validation dry-runs of packages through the `testmempoolaccept` RPC. The expectation is that the results returned from `testmempoolaccept` are what you'd get from test-then-submitting each transaction individually, in that order (this means the package is expected to be sorted in topological order, for now at least). The validation is also atomic: in the case of failure, it immediately halts and may return "unfinished" `MempoolAcceptResult`s for transactions that weren't fully validated. The API for 1 transaction stays the same.
**Motivation:**
- This allows you to test validity for transaction chains (e.g. with multiple spending paths and where you don't want to broadcast yet); closes#18480.
- It's also a first step towards package validation in a minimally invasive way.
- The RPC commit happens to close#21074 by clarifying the "allowed" key.
There are a few added restrictions on the packages, mostly to simplify the logic for areas that aren't critical to main package use cases:
- No package can have conflicts, i.e. none of them can spend the same inputs, even if it would be a valid BIP125 replacement.
- The package cannot conflict with the mempool, i.e. RBF is disabled.
- The total count of the package cannot exceed 25 (the default descendant count limit), and total size cannot exceed 101KvB (the default descendant size limit).
If you're looking for review comments and github isn't loading them, I have a gist compiling some topics of discussion [here](https://gist.github.com/glozow/c3acaf161c95bba491fce31585b2aaf7)
ACKs for top commit:
laanwj:
Code review re-ACK 13650fe2e5
jnewbery:
Code review ACK 13650fe2e5
ariard:
ACK 13650fe
Tree-SHA512: 8c5cbfa91a6c714e1c8710bb281d5ff1c5af36741872a7c5df6b24874d6272b4a09f816cb8a4c7de33ef8e1c2a2c252c0df5105b7802f70bc6ff821ed7cc1a2f
167fb1fc72 Update Windows code signing certificate (Andrew Chow)
Pull request description:
Updates the Windows code signing certificate to a new one issued by Digicert. This certificate has been issued to Bitcoin Core Code Signing LLC registered in Delaware, US. Note that this is different from the previous Bitcoin Core Code Signing Association registered in Zurich, Switzerland as it was unable to meet the validation requirements in time.
ACKs for top commit:
Sjors:
utACK 167fb1f
laanwj:
ACK 167fb1fc72
Tree-SHA512: 8d5308c710ef94330417955b9bc82c5894d282798cebece82b84b425e3354e566aa6a68693ec359391ea40ddd7e2032d35ce28d104683d75ec3010ddf00be209
Pass in chainman instead of prev_block so that we can enforce the
block.hashPrevBlock refers to prev_block invariant in the function
itself.
We should probably rethink BlockAssembler's API and somehow include
commitment regeneration functionality in there. Something like a variant
of CreateNewBlock that takes in a std::vector<TxRef> and return a CBlock
instead of CBlockTemplate. That could avoid reaching for
LookupBlockIndex at all.
This is not the cleanest change but:
1. It fixes the erroneous use of RPC's Ensure*() in rest.cpp, which
cause crashes in REST contexts.
RPC code wraps all calls in a try/except, REST code does not.
Ensure*(), being part of RPC, expects that its throw's will get
caught by a try/except. But if you use Ensure*() in REST code, since
it doesn't have a try/except wrap, a crash will happen.
2. It is consistent with other functions like GetMemPool.
Someone can probably make this a bit prettier.
8caf60dbbe move-only: Group and re-order CAddrMan members by access type (Hennadii Stepanov)
5cd7f8abe3 refactor: Do not expose CAddrMan members as protected without need (Hennadii Stepanov)
Pull request description:
This PR is split from #19238 as all of its commits are trivial to review.
The last commit is easy to review with `git diff --color-moved=dimmed-zebra`.
Addressed the following comments from #19238:
- 130b82ff35 (r550865131)
> Can you consolidate all the private members and protected members to be next to each other? Multiple private and protected access specifiers make this harder to read than is necessary.
- 130b82ff35 (r557271783)
> Yeah, class declaration is easier to read if there is just one instance of `public:`, `protected:` and `private:` (in that order).
ACKs for top commit:
jnewbery:
ACK 8caf60dbbe
laanwj:
Code review ACK 8caf60dbbe
jarolrod:
ACK 8caf60dbbe
vasild:
ACK 8caf60dbbe
Tree-SHA512: e6127fc658da7876e36f22e2fae162dc19502ed7f8e931fdebc827dabd627e5346c6fbe6f6d0cd27fd3e5c96690ff35022ff6b48f2747b748ebd66a45c851c2b
