Commit Graph

24725 Commits

Author SHA1 Message Date
MarcoFalke
48016a3fba
Merge #19914: refactor: Do not pass chain params to CheckForStaleTipAndEvictPeers twice
fa7e407b504bc60c77341f02636ed9d6a4b53d79 Do not pass chain params to CheckForStaleTipAndEvictPeers twice (MarcoFalke)

Pull request description:

  `PeerManager` already keeps a reference to the chain params as a member variable. No need to pass it in once again as a function parameter.

ACKs for top commit:
  naumenkogs:
    utACK fa7e407b504bc60c77341f02636ed9d6a4b53d79
  jnewbery:
    code review ACK fa7e407b504bc60c77341f02636ed9d6a4b53d79
  epson121:
    Code review ACK fa7e407b504bc60c77341f02636ed9d6a4b53d79

Tree-SHA512: 640c2d8adf9f1d54d0bfbdf81989064be2f5ba4b534d07d42258b372dc130f7b9c3fd087c7d28f0439678d124127f5d6f82f3139b1766f59f5ed661e7ac2a923
2024-01-22 19:47:12 -06:00
Samuel Dobson
5492191904
Merge #19738: wallet: Avoid multiple BerkeleyBatch in DelAddressBook
abac4367607d8d2b628e4db6a9663c960bacdacc wallet: Avoid multiple BerkeleyBatch in DelAddressBook (João Barbosa)

Pull request description:

ACKs for top commit:
  achow101:
    ACK abac4367607d8d2b628e4db6a9663c960bacdacc
  jonatack:
    ACK abac4367607d8d2b628e4db6a9663c960bacdacc
  meshcollider:
    re-utACK abac4367607d8d2b628e4db6a9663c960bacdacc

Tree-SHA512: 92309fb74c48694160807326c0fe9793044a75cd77ed19400cceab54a7eefeb54ffc9334535e6021b3af7b9a364dbbeda3a9173540fff8144dfd437e96d76b5c
2024-01-22 19:47:12 -06:00
fanquake
7fbcba4503
Merge #19765: doc: Fix getmempoolancestors RPC result doc
333329dbda423b00098ec9f8702d75d24468c56e doc: Fix getmempoolancestor RPC result doc (MarcoFalke)

Pull request description:

ACKs for top commit:
  laanwj:
    ACK 333329dbda423b00098ec9f8702d75d24468c56e

Tree-SHA512: 30a7568ec15d1af0c484b4d479e14ec3609a01b76f17f8285688b0c5e5b0480926bbf6f651da91193b66fd752e83e9707e4b08c52b69f8c670c430da84713359
2024-01-22 19:47:11 -06:00
Konstantin Akimov
8085729789
chore: dashification: drop DOCKER_NAME_TAG
We have only one docker image for all functional test and this option is confusing
2024-01-22 19:47:11 -06:00
MarcoFalke
f8e425b437
Merge #19267: ci: Upgrade most ci configs to focal
fa05f44893d228f672f39436d0cb6b3376f81ac2 ci: Upgrade most ci configs to focal (MarcoFalke)
fad67208914e5a74b64f4cc018368902ef3a2e9b doc: move doc to ci readme (MarcoFalke)
fa880773b425fcd292ed7669d237ee3151a15bc6 ci: Have one config run in xenial to test against python3.5 (MarcoFalke)
fa6ddb2fa167df52f59cb9eaabed48315ddcdb2e travis: Always run multiprocess build (MarcoFalke)

Pull request description:

  Generally developers compile with recent compilers, so bumping the ci configs to a recent OS should be uncontroversial. Older OSes (especially with compiler sanitizers) need workarounds that can be dropped by running on a more recent OS.

  This pull changes the asan sanitizer and the experimental multiprocess build to use focal.
  Also, it runs the no_wallet config on xenial to test against python 3.5, according to `doc/dependencies.md`.

  Finally, all configs that mimic gitian (win and mac) will stay at bionic.

ACKs for top commit:
  Sjors:
    ACK fa05f44893d228f672f39436d0cb6b3376f81ac2, assuming Travis passes
  hebasto:
    ACK fa05f44893d228f672f39436d0cb6b3376f81ac2

Tree-SHA512: 55ec56c71ba2280d27c1a8856a1e6c310b1fbf469d5a8a1dde228063e3892e1dd1e51408ecff7a3d77ac2ae018daa9e9bbbb60598cdeaab8c32a146b11b3e7c4
2024-01-22 19:47:11 -06:00
MarcoFalke
6d90ac115b
Merge #20279: doc: release process updates/fixups
BACKPORT NOTICE
There's some extra changes that has been forgotten due to skipped bitcoin#17002 (which is DNM)
-------------
e5f3e95a8e277acc54bc377a6b116d60d8c4eb5c doc: fix getchaintxstats fields in release-process.md (Jon Atack)

Pull request description:

  ISTM the getchaintxstats fields should be `window_final_block_hash` rather than `window_last_block_hash`. While here, replace getblockchaininfo with getblockheader (and getblockhash) instead of getblockchaininfo for updating the nMinimumChainWork and defaultAssumeValid consensus params, update the example PR, and improve a link with a named anchor tag.

  Markdown rendering here: https://github.com/jonatack/bitcoin/blob/release-process-getchaintxstats-fix/doc/release-process.md

ACKs for top commit:
  theStack:
    re-ACK e5f3e95a8e277acc54bc377a6b116d60d8c4eb5c

Tree-SHA512: 48c9c65f10d65e461da8d4935af56b6c67e6faca94e4593237f754d8c48f03bef2b9b4a71e5d1009b215a415ba7c4c4218aca6dce97238101ca1c81f5d098bdb
2024-01-22 19:47:11 -06:00
fanquake
35d972f83c
Merge #17002: chainparams: Bump assumed chain params
fa3a7331160d1a460b1c15fca1810e98070d629c chainparams: Bump assumed chain params (MarcoFalke)

Pull request description:

  As every year, reviewers get extra point when their node is running:
  * `assumevalid=0`
  * `checkpoints=0`
  * on non-x86_64 hardware

  See https://github.com/bitcoin/bitcoin/blob/master/doc/release-process.md#before-every-major-and-minor-release for the process.

ACKs for top commit:
  laanwj:
    ACK fa3a7331160d1a460b1c15fca1810e98070d629c
  Sjors:
    ACK fa3a7331160d1a460b1c15fca1810e98070d629c for mainnet on macOS 10.14.6.
  jamesob:
    ACK fa3a733116
  fanquake:
    ACK fa3a7331160d1a460b1c15fca1810e98070d629c - checked the mainnet values. I have notes on reviewing `assumevalid` updates in [core-review](https://github.com/fanquake/core-review/blob/master/update-assumevalid.md).

Tree-SHA512: fc545ba0a7056908040b47076b393d028c1c022967c25a2074752f76f0386ef099a64445da6125117a04418bd7eb0655121bfc94e6f60b7bc2666947491b5228
2024-01-22 19:47:10 -06:00
MarcoFalke
7127f8bb2b
Merge bitcoin-core/gui#43: bugfix: Call setWalletActionsEnabled(true) only for the first wallet
20c9e035543892e322c7134e89eb33115678bb30 gui: Call setWalletActionsEnabled(true) only for the first wallet (Hennadii Stepanov)

Pull request description:

  On master (a78742830aa35bf57bcb0a4730977a1e5a1876bc) there is a bug:
  - open an encrypted wallet; please note that the "Encrypt Wallet..." menu item is disabled that is expected:
  ![Screenshot from 2020-08-03 12-38-37](https://user-images.githubusercontent.com/32963518/89169084-70060c80-d586-11ea-86b9-05ef38d08f41.png)
  - then open any other wallet; note that the "Encrypt Wallet..." menu item gets enabled that is wrong:
  ![Screenshot from 2020-08-03 12-42-36](https://user-images.githubusercontent.com/32963518/89169385-d68b2a80-d586-11ea-9813-a533a847e098.png)

  This PR fixes this bug.

ACKs for top commit:
  jonasschnelli:
    Tested ACK 20c9e035543892e322c7134e89eb33115678bb30 - I could reproduce the issue on master and have verify that this PR fixes it.
  achow101:
    ACK 20c9e035543892e322c7134e89eb33115678bb30

Tree-SHA512: 2c9ab94bde8c4f413b0a95c05bf3a1a29f5910e0f99d6639a11dd77758c78af25b060b3fecd78117066ef15b113feb79870bc1347cc04289da915c00623e5787
2024-01-22 19:47:10 -06:00
MarcoFalke
c5eb8a557a
Merge bitcoin-core/gui#97: Relax GUI freezes during IBD (when using wallets)
0d9d2a1f7c26dc9c7b233ea8c3182fe1f8936bca Only update the updateSmartFeeLabel once in sync (Jonas Schnelli)

Pull request description:

  Calling `updateSmartFeeLabel` and therefore `estimateSmartFee` is pointless during IBD.

  GUI freezes appear because `estimateSmartFee` competes with `processBlock` for the `m_cs_fee_estimator` lock leading to multiple seconds of blocking the GUI thread in `updateSmartFeeLabel`.

ACKs for top commit:
  ryanofsky:
    Code review ACK 0d9d2a1f7c26dc9c7b233ea8c3182fe1f8936bca. Clever fix. Didn't test but I remember I could reproduce the startup issue easily before by putting a sleep in estimateSmartFee.
  promag:
    Code review ACK 0d9d2a1f7c26dc9c7b233ea8c3182fe1f8936bca.
  hebasto:
    ACK 0d9d2a1f7c26dc9c7b233ea8c3182fe1f8936bca, tested on Linux Mint 20 (x86_64) with `QT_FATAL_WARNINGS=1` and `-debug=qt`.

Tree-SHA512: 85ec2266f06ddd7b523e24d2a462f10ed965d5b4d479005263056f81b7fe49996e1568dafb84658af406e9202ed3bfa846d59c10bb951e0f97cee230e30fafd5
2024-01-22 19:47:10 -06:00
PastaPastaPasta
be750ef0b0
Merge pull request #5828 from knst/bp-v21-p13
backport: bitcoin#18044, #18244, #19569, #19670, #19710, #19730, #19818
2024-01-22 19:44:59 -06:00
Wladimir J. van der Laan
6317a2951f
Merge #19818: p2p: change CInv::type from int to uint32_t, fix UBSan warning
7984c39be11ca04460883365e1ae2a496aaa6c0e test framework: serialize/deserialize inv type as unsigned int (Jon Atack)
407175e0c2bc797599ebd9c0a1f2ec89ad7af136 p2p: change CInv::type from int to uint32_t (Jon Atack)

Pull request description:

  Fixes UBSan implicit-integer-sign-change issue per https://github.com/bitcoin/bitcoin/pull/19610#issuecomment-680686460.

  Credit to Crypt-iQ for finding and reporting the issue and to vasild for the original review suggestion in https://github.com/bitcoin/bitcoin/pull/19590#pullrequestreview-455788826.

  Closes #19678.

ACKs for top commit:
  laanwj:
    ACK 7984c39be11ca04460883365e1ae2a496aaa6c0e
  MarcoFalke:
    ACK 7984c39be11ca04460883365e1ae2a496aaa6c0e 🌻
  vasild:
    ACK 7984c39be

Tree-SHA512: 59f3a75f40ce066ca6f0bb1927197254238302b4073af1574bdbfe6ed580876437be804be4e47d51467d604f0d9e3a5875159f7f2edbb2351fdb2bb9465100b5
2024-01-22 19:44:37 -06:00
Wladimir J. van der Laan
56545f2cfd
Merge #19670: Protect localhost and block-relay-only peers from eviction
752e6ad5336d5af0db9fe16d24c0c6aa25b74a3f Protect localhost and block-relay-only peers from eviction (Suhas Daftuar)

Pull request description:

  Onion peers are disadvantaged under our eviction criteria, so prevent eventual
  eviction of them in the presence of contention for inbound slots by reserving
  some slots for localhost peers (sorted by longest uptime).

  Block-relay-only connections exist as a protection against eclipse attacks, by
  creating a path for block propagation that may be unknown to adversaries.
  Protect against inbound peer connection slot attacks from disconnecting such
  peers by attempting to protect up to 8 peers that are not relaying transactions
  but have provided us with blocks.

  Thanks to gmaxwell for suggesting these strategies.

ACKs for top commit:
  laanwj:
    Code review ACK 752e6ad5336d5af0db9fe16d24c0c6aa25b74a3f

Tree-SHA512: dbf089c77c1f747aa1dbbbc2e9c2799c628028b0918d0c336d8d0e5338acedd573b530eb3b689c7f603a17221e557268a9f5c3f585f204bfb12e5d2e76de39a3
2024-01-22 19:44:37 -06:00
Samuel Dobson
76d30c9607
Merge #18244: rpc: fundrawtransaction and walletcreatefundedpsbt also lock manually selected coins
6d1f51343cf11b07cd401fbd0c5bc3603e185a0e [rpc] fundrawtransaction, walletcreatefundedpsbt lock manually selected coins (Sjors Provoost)

Pull request description:

  When using `fundrawtransaction` and `walletcreatefundedpsbt` with `lockUnspents`, it would only lock automatically selected coins, not manually selected coins. That doesn't make much sense to me if the goal is to prevent accidentally double-spending yourself before you broadcast a transaction.

  Note that when  creating a transaction, manually selected coins are automatic "unlocked" (or more accurately: the lock is ignored). Earlier versions of this PR introduced an error when a locked coin is manually selected, but this idea was abandoned after some discussion. An application that uses this RPC should either rely on automatic coin selection (with `lockUnspents`) or handle lock concurrency itself with manual coin selection. In particular it needs to make sure to avoid/pause calls with automatic coin selection between calling `lockunspent` and the subsequent spending RPC.

  See #7518 for historical background.

ACKs for top commit:
  meshcollider:
    Code review ACK 6d1f51343cf11b07cd401fbd0c5bc3603e185a0e
  fjahr:
    Code review ACK 6d1f51343cf11b07cd401fbd0c5bc3603e185a0e

Tree-SHA512: 8773c788d92f2656952e1beac147ba9956b8c5132d474e0880e4c89ff53642928b4cbfcd1cb3d17798b9284f02618a8830c93a9f7a4733e5bded96adff1d5d4d
2024-01-22 19:44:36 -06:00
MarcoFalke
14b46f90fe
Merge #19710: bench: Prevent thread oversubscription and decreases the variance of result values
3edc4e34fe2f92e7066c1455f5e42af2fdb43b99 bench: Prevent thread oversubscription (Hennadii Stepanov)
ce3e6a7cb21d1aa455513970846e1f70c01472a4 bench: Allow skip benchmark (Hennadii Stepanov)

Pull request description:

  Split out from #18710.

  Some results (borrowed from #18710):
  ![89121718-a3329800-d4c1-11ea-8bd1-66da20619696](https://user-images.githubusercontent.com/32963518/90146614-ecb89800-dd89-11ea-80fe-bac0e46e735e.png)

ACKs for top commit:
  fjahr:
    Code review ACK 3edc4e34fe2f92e7066c1455f5e42af2fdb43b99

Tree-SHA512: df7413ec9ea326564a8e8de54752c9d1444ff7de34edb03e1e0c2120fc333e4640767fdbe3e87eab6a7b389a4863c02e22ad2ae0dbf139fad6a9b85e00f563b4
2024-01-22 19:44:36 -06:00
MarcoFalke
261d2a0ded
Merge #19730: ci: Set increased --timeout-factor by default
fa330ec2fe5f5ba68a8d43fff0b19584c0b1ff39 test: Remove confusing and broken use of wait_until global (MarcoFalke)
fa6583c30bf7d82cf7ffdae995f8f16524ad2c0d ci: Set increased --timeout-factor by default (MarcoFalke)

Pull request description:

  Assuming that tests don't have a logic error or race, setting a high timeout should not cause any issues. The tests will still pass just as fast in the fastest case, but it allows for some buffer in case of slow disks or otherwise starved ci machines.

  Fixes #19729

ACKs for top commit:
  hebasto:
    ACK fa330ec2fe5f5ba68a8d43fff0b19584c0b1ff39, I have reviewed the code, and it looks OK, I agree it can be merged.

Tree-SHA512: 3da80ee008c7b08bab5fdaf7804d57c79d6fed49a7d37b9c54fc89756659fcb9981fd10afc4d07bd90d93c1699fd410a0110a3cd34d016873759d114ce3cd82d
2024-01-22 19:44:36 -06:00
fanquake
0a27a2af73
Merge #19569: Enable fetching of orphan parents from wtxid peers
10b7a6d532148f880568c529e61a6d7edc7c91a9 refactor: make txmempool interface use GenTxid (Pieter Wuille)
5c124e17407a5b5824fec062b73a03a1030fa28c refactor: make FindTxForGetData use GenTxid (Pieter Wuille)
a2bfac893549e2d62708d8cda7071b4fe9750a2d refactor: use GenTxid in tx request functions (Pieter Wuille)
e65d115b725640eefb3bfa09786447816f7ca9cc test: request parents of orphan from wtxid relay peer (Anthony Towns)
900d7f6c075fd78e63503f31d267dbc16b3983d9 p2p: enable fetching of orphans from wtxid peers (Pieter Wuille)
9efd86a908cf09d9ddbadd3195f202635117d505 refactor: add GenTxid (=txid or wtxid) type and use it for tx request logic (Pieter Wuille)
d362f19355b36531a4a82094e0259f7f3db500a7 doc: list support for BIP 339 in doc/bips.md (Pieter Wuille)

Pull request description:

  This is based on https://github.com/bitcoin/bitcoin/pull/18044#discussion_r450687076.

  A new type `GenTxid` is added to protocol.h, which represents a tagged txid-or-wtxid. The tx request logic is updated to use these instead of uint256s, permitting per-announcement distinguishing of txid/wtxid (instead of assuming that everything we want to request from a wtxid peer is wtx). Then the restriction of orphan-parent requesting to non-wtxid peers is lifted.

  Also document BIP339 in doc/bips.md.

ACKs for top commit:
  jnewbery:
    Code review ACK 10b7a6d532148f880568c529e61a6d7edc7c91a9
  jonatack:
    ACK 10b7a6d532148f880568c529e61a6d7edc7c91a9
  ajtowns:
    ACK 10b7a6d532148f880568c529e61a6d7edc7c91a9 -- code review. Using gtxid to replace the is_txid_or_wtxid flag for the mempool functions is nice.
  naumenkogs:
    utACK 10b7a6d

Tree-SHA512: d518d13ffd71f8d2b3c175dc905362a7259689e6022a97a0b4f14f1f9fdd87475cf5af70cb12338d1e5d31b52c12e4faaea436114056a2ae9669cb506240758b
2024-01-22 19:44:36 -06:00
Konstantin Akimov
9b3d2e0c17
Merge bitcoin#18044: Use wtxid for transaction relay
This backport is marked as full, not partial, but it has only refactorings
and non-witness related changes.

Included commits are:
 - test: Update test framework p2p protocol version to 70016
 - Rename AddInventoryKnown() to AddKnownTx()
 - Add support for tx-relay via wtxid

    This adds a field to CNodeState that tracks whether to relay transactions with
    that peer via wtxid, instead of txid. As of this commit the field will always
    be false, but in a later commit we will add a way to negotiate turning this on
    via p2p messages exchanged with the peer.

 - Just pass a hash to AddInventoryKnown

    Since it's only used for transactions, there's no need to pass in an inv type.

 - Add wtxid to mempool unbroadcast tracking
2024-01-22 19:44:33 -06:00
Konstantin Akimov
d17665307b
feat: new rpc getrawtransactionmulti (#5839)
## Issue being fixed or feature implemented
For platform needs `getrawtransactionmulti` will help to reduce amount
of rpc calls for sake of performance improvement.

## What was done?
Implemented new RPC, basic functional test, release note.

## How Has This Been Tested?
On testnet:
```
> getrawtransactionmulti '{"000000abbe61a4d9b9356cb1d7deb1132d0b444a62869e71c2f3aa8ce2361359":["6e3ef19a3f955ac75a1f84dae60d42bbe11548ef54e37033ff2d91b3c4a09e9c", "415d5fafd5ee24ada8b99c36df339785a3066170c0dca6bb1aa6a5b96cf51e35"], "0":["ec7090f01c0e9b6e29d3be8810b12c780d2fb34372a53b231ce18bb7d2f1e8b0"]}'
> getrawtransactionmulti '{"000000abbe61a4d9b9356cb1d7deb1132d0b444a62869e71c2f3aa8ce2361359":["6e3ef19a3f955ac75a1f84dae60d42bbe11548ef54e37033ff2d91b3c4a09e9c", "415d5fafd5ee24ada8b99c36df339785a3066170c0dca6bb1aa6a5b96cf51e35"], "0":["ec7090f01c0e9b6e29d3be8810b12c780d2fb34372a53b231ce18bb7d2f1e8b0"]}'  true
```

## Breaking Changes
N/A

## 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
- [x] I have assigned this pull request to a milestone

---------

Co-authored-by: pasta <pasta@dashboost.org>
2024-01-22 19:33:24 -06:00
PastaPastaPasta
3d9dc207cf
Merge pull request #5833 from knst/bp-v21-p14
backport: bitcoin#19552, #19674, #19752, #19760 (functional tests)
2024-01-21 18:39:11 -06:00
MarcoFalke
4c8e77a48d
Merge #19752: test: Update wait_until usage in tests not to use the one from utils
d841301010914203fb5ef02627c76fad99cb11f1 test: Add docstring to wait_until() in util.py to warn about its usage (Seleme Topuz)
1343c86c7cc1fc896696b3ed87c12039e4ef3a0c test: Update wait_until usage in tests not to use the one from utils (Seleme Topuz)

Pull request description:

  Replace global (from [test_framework/util.py](https://github.com/bitcoin/bitcoin/blob/master/test/functional/test_framework/util.py#L228)) `wait_until()` usages with the ones provided by `BitcoinTestFramework` and `P2PInterface` classes.

  The motivation behind this change is that the `util.wait_until()` expects a timeout, timeout_factor and lock and it is not aware of the context of the test framework. `BitcoinTestFramework` offers a `wait_until()` which has an understandable amount of default `timeout` and a shared `timeout_factor`. Moreover, on top of these, `mininode.wait_until()` also has a shared lock.

  closes #19080

ACKs for top commit:
  MarcoFalke:
    ACK d841301010914203fb5ef02627c76fad99cb11f1 🦆
  kallewoof:
    utACK d841301010914203fb5ef02627c76fad99cb11f1

Tree-SHA512: 81604f4cfa87fed98071a80e4afe940b3897fe65cf680a69619a93e97d45f25b313c12227de7040e19517fa9c003291b232f1b40b2567aba0148f22c23c47a88
2024-01-20 00:07:11 +07:00
MarcoFalke
4171afe54e
Merge #19552: test: fix intermittent failure in p2p_ibd_txrelay
12410b1feb80189061eb4a2b43421e53cbb758a8 test: fix intermittent p2p_ibd_txrelay race, add test_framework.py#wait_until (Jon Atack)

Pull request description:

  To fix these intermittent failures in Travis CI.
  ```
  162/163 - p2p_ibd_txrelay.py failed, Duration: 2 s

  stdout:
  2020-07-19T05:44:17.213000Z TestFramework (INFO):
      Check that nodes set minfilter to MAX_MONEY while still in IBD
  2020-07-19T05:44:17.216000Z TestFramework (ERROR): Assertion failed
  Traceback (most recent call last):
    File "/Users/travis/build/bitcoin/bitcoin/ci/scratch/build/bitcoin-x86_64-apple-darwin16/test/functional/test_framework/test_framework.py", line 117, in main
      self.run_test()
    File "/Users/travis/build/bitcoin/bitcoin/ci/scratch/build/bitcoin-x86_64-apple-darwin16/test/functional/p2p_ibd_txrelay.py", line 30, in run_test
      assert_equal(conn_info['minfeefilter'], MAX_FEE_FILTER)
    File "/Users/travis/build/bitcoin/bitcoin/ci/scratch/build/bitcoin-x86_64-apple-darwin16/test/functional/test_framework/util.py", line 49, in assert_equal
      raise AssertionError("not(%s)" % " == ".join(str(arg) for arg in (thing1, thing2) + args))

  AssertionError: not(0E-8 == 0.09170997)
  2020-07-19T05:44:17.293000Z TestFramework (INFO): Stopping nodes
  ```

  At Marco's suggestion, cherry-picked part of #19134 to nicely simplify using `wait_until`.

ACKs for top commit:
  vasild:
    ACK 12410b1fe

Tree-SHA512: 615f509883682fd693e578b259cba35a9fa0bc519f1394e88c857e8b0650bfec5397bfa856cfa9e6d5ef81d0ee6ad02e4ad2b0eb0bd530b4c281cbe3e663790b
2024-01-20 00:07:11 +07:00
Konstantin Akimov
f34889dcf4
Merge #19760: test: Remove confusing mininode terminology
d5800da5199527a366024bc80cad7fcca17d5c4a [test] Remove final references to mininode (John Newbery)
5e8df3312e47a73e747ee892face55ed9ababeea test: resort imports (John Newbery)
85165d4332b0f72d30e0c584b476249b542338e6 scripted-diff: Rename mininode to p2p (John Newbery)
9e2897d020b114a10c860f90c5405be029afddba scripted-diff: Rename mininode_lock to p2p_lock (John Newbery)

Pull request description:

  New contributors are often confused by the terminology in the test framework, and what the difference between a _node_ and a _peer_ is. To summarize:

  - a 'node' is a bitcoind instance. This is the thing whose behavior is being tested. Each bitcoind node is managed by a python `TestNode` object which is used to start/stop the node, manage the node's data directory, read state about the node (eg process status, log file), and interact with the node over different interfaces.
  - one of the interfaces that we can use to interact with the node is the p2p interface. Each connection to a node using this interface is managed by a python `P2PInterface` or derived object (which is owned by the `TestNode` object). We can open zero, one or many p2p connections to each bitcoind node. The node sees these connections as 'peers'.

  For historic reasons, the word 'mininode' has been used to refer to those p2p interface objects that we use to connect to the bitcoind node (the code was originally taken from the 'mini-node' branch of https://github.com/jgarzik/pynode/tree/mini-node). However that name has proved to be confusing for new contributors, so rename the remaining references.

ACKs for top commit:
  amitiuttarwar:
    ACK d5800da519
  MarcoFalke:
    ACK d5800da5199527a366024bc80cad7fcca17d5c4a 🚞
Tree-SHA512: 2c46c2ac3c4278b6e3c647cfd8108428a41e80788fc4f0e386e5b0c47675bc687d94779496c09a3e5ea1319617295be10c422adeeff2d2bd68378e00e0eeb5de
2024-01-20 00:07:10 +07:00
fanquake
9d33b30a87
Merge #19674: refactor: test: use throwaway _ variable for unused loop counters
dac7a111bdd3b0233d94cf68dae7a8bfc6ac9c64 refactor: test: use _ variable for unused loop counters (Sebastian Falbesoner)

Pull request description:

  This tiny PR substitutes Python loops in the form of `for x in range(N): ...` by `for _ in range(N): ...` where applicable. The idea is indicating to the reader that a block (or statement, in list comprehensions) is just repeated N times, and that the loop counter is not used in the body, hence using the throwaway variable. This is already done quite often in the current tests (see e.g. `$ git grep "for _ in range("`). Another alternative would be using `itertools.repeat` (according to Python core developer Raymond Hettinger it's [even faster](https://twitter.com/raymondh/status/1144527183341375488)), but that doesn't seem to be widespread in use and I'm not sure about a readability increase.

  The only drawback I see is that whenever one wants to debug loop iterations, one would need to introduce a loop variable again. Reviewing this is basically a no-brainer, since tests would fail immediately if a a substitution has taken place on a loop where the variable is used.

  Instances to replace were found by `$ git grep "for.*in range("` and manually checked.

ACKs for top commit:
  darosior:
    ACK dac7a111bdd3b0233d94cf68dae7a8bfc6ac9c64
  instagibbs:
    manual inspection ACK dac7a111bd
  practicalswift:
    ACK dac7a111bdd3b0233d94cf68dae7a8bfc6ac9c64 -- the updated code is easier to reason about since the throwaway nature of a variable is expressed explicitly (using the Pythonic `_` idiom) instead of implicitly. Explicit is better than implicit was we all know by now :)

Tree-SHA512: 5f43ded9ce14e5e00b3876ec445b90acda1842f813149ae7bafa93f3ac3d510bb778e2c701187fd2c73585e6b87797bb2d2987139bd1a9ba7d58775a59392406
2024-01-20 00:07:09 +07:00
PastaPastaPasta
87f0554d9d
Merge pull request #5830 from PastaPastaPasta/develop-trivial-2024-01-17
backport: trivial 2024 01 17
2024-01-19 11:02:49 -06:00
fanquake
b57482b510
Merge bitcoin/bitcoin#25303: refactor: Remove redundant addrman time checks
8888bd43c100f9f0ca1122fcc896fb7b999d61c6 Remove redundant nLastTry check (MarcoFalke)
00001e57fe74c061aa9cbc72b07252335cb566e0 Remove redundant nTime checks (MarcoFalke)

Pull request description:

  Split out from https://github.com/bitcoin/bitcoin/pull/24697 because it makes sense on its own.

ACKs for top commit:
  dergoegge:
    re-ACK 8888bd43c100f9f0ca1122fcc896fb7b999d61c6
  naumenkogs:
    utACK 8888bd43c100f9f0ca1122fcc896fb7b999d61c6

Tree-SHA512: 32c6cde1c71e943c76b7991c2c24caf29ae467ab4ea2d758483a0cee64625190d1a833b468e8eab1f834beeb2c365af96552c14b05270f08cf63790e0707581d
2024-01-19 11:02:23 -06:00
fanquake
7c723d88c6
Merge bitcoin/bitcoin#25096: [net] Minor improvements to addr caching
292828cd7744ec7eadede4ad54aa2117087c5435 [test] Test addr cache for multiple onion binds (dergoegge)
3382905befd23364989d941038bf7b1530fea0dc [net] Seed addr cache randomizer with port from binding address (dergoegge)
f10e80b6e4fbc151abbf1c20fbdcc3581d3688f0 [net] Use ConnectedThroughNetwork() instead of GetNetwork() to seed addr cache randomizer (dergoegge)

Pull request description:

  The addr cache id randomizer is currently supposed to be seeded with the network of the inbound connection and the local socket (only the address is used not the port):  a8098f2cef/src/net.cpp (L2800-L2804)

  For inbound onion connections `CNode::addr.GetNetwork()` returns `NET_UNROUTABLE` and `CNode::addrBind` is set to `127.0.0.1:<onion bind port>`. This results in the same addr cache for all inbound connections on 127.0.0.1 binds.

  To avoid the same addr cache across all onion and other 127.0.0.1 binds, we should seed the addr cache randomizer with the correct network for inbound onion connections (using `CNode::ConnectedThroughNetwork()`) as well as the port of `CNode::addrBind`.

ACKs for top commit:
  sipa:
    utACK 292828cd7744ec7eadede4ad54aa2117087c5435
  mzumsande:
    Code Review ACK 292828cd7744ec7eadede4ad54aa2117087c5435
  naumenkogs:
    utACK 292828cd7744ec7eadede4ad54aa2117087c5435

Tree-SHA512: d0be13bab6bc121c2926d4b168687f6c2ed4ce0c9dd19be71eb4886adeba8afc3daacdc4e232a0ba3b03a89d69b618abc5595b69abd1ad0c476d825bc6ea1f9f
2024-01-19 11:02:23 -06:00
laanwj
e556af3ef8
Merge bitcoin/bitcoin#24416: doc: Avoid ADL for function calls
52a797bfe5ced4329f2272be417c35730ec8839f doc: Avoid ADL for function calls (Hennadii Stepanov)

Pull request description:

  It happened two times recently, when [ADL](https://en.cppreference.com/w/cpp/language/adl) popped up unexpectedly and brought some confusion:
  - https://github.com/bitcoin/bitcoin/pull/24338/files#r805989994
  > Any idea why this even compiles?
  - https://www.erisian.com.au/bitcoin-core-dev/log-2022-02-18.html#l-51:
  > 2022-02-18T03:24:14  \<dongcarl\> Does anyone know why this compiles? 6d3d2caa37
  > 2022-02-18T03:24:14  \<dongcarl\> GetUTXOStatsWithHasher and MakeUTXOHasher are both in the `kernel::` namespace and I never added a `using` declaration on top...
  > 2022-02-18T03:25:53  \<sipa\> https://en.cppreference.com/w/cpp/language/adl ?

  Let's document our intention to avoid similar cases in the future.

ACKs for top commit:
  laanwj:
    Anyhow, ACK 52a797bfe5ced4329f2272be417c35730ec8839f, there is no need to hold merge up on this, documenting it is a step forward.

Tree-SHA512: f52688b5d8f6130302185206ec6ea4731b099a75294ea2d477901a52d6d58473e3427e658aea408c140c2824c37a0399ec7376aded2a91197895ea52d51f0018
2024-01-19 11:02:23 -06:00
MacroFake
4d56397d96
Merge bitcoin/bitcoin#25253: test: add coverage for non-hex value to -minimumchainwork
ebfc308ea4b8851118e8194d837556bf443c329c test: add coverage for non-hex value to -minimumchainwork (brunoerg)

Pull request description:

  This PR adds test coverage for the following init error:
  b9ef5a10e2/src/init.cpp (L917-L919)

  Passing a non-hex value to -minimumchainwork should throw an initial error.

ACKs for top commit:
  laanwj:
    Code review ACK ebfc308ea4b8851118e8194d837556bf443c329c
  kristapsk:
    re-ACK ebfc308ea4b8851118e8194d837556bf443c329c

Tree-SHA512: c665903757ae3b8b2480df97bb888e60ba4387b009fcb8031041822e87a155a0e4950ebe79873c1034f0826504521d82b1fdfdb5e8378b227d14ca545b8d4e11
2024-01-19 11:02:23 -06:00
Hennadii Stepanov
a4d8a8c235
Merge bitcoin-core/gui#609: wallet, refactor: Drop unused WalletModel::PaymentRequestExpired
151009cf76f3f1adc17630d5370bf019be127373 qt, wallet, refactor: Drop unused `WalletModel::PaymentRequestExpired` (Hennadii Stepanov)

Pull request description:

  The `PaymentRequestExpired` value in the `WalletModel::StatusCode` enumeration has been unused since bitcoin/bitcoin#17165.

ACKs for top commit:
  furszy:
    ACK 151009cf, no usage for it.
  kristapsk:
    cr ACK 151009cf76f3f1adc17630d5370bf019be127373, checked that `PaymentRequestExpired` is not referenced anywhere else.

Tree-SHA512: c2ea3443af5d369ca294d79559869f688aaa806b91ffe0090f3b34638a8377ec2f11d6f5c09cc2d11ab55035850237e60e992acba671097a6642c6bb9e709273
2024-01-19 11:02:22 -06:00
fanquake
282a981749
Merge bitcoin/bitcoin#25224: Get time less often in AddrManImpl::ResolveCollisions_()
fa27ee88edbf696b7eef2efbfcf1446ec522fd85 Get time less often in AddrManImpl::ResolveCollisions_() (MarcoFalke)

Pull request description:

  First commit split out from https://github.com/bitcoin/bitcoin/pull/24697

ACKs for top commit:
  sipa:
    utACK fa27ee88edbf696b7eef2efbfcf1446ec522fd85
  fanquake:
    ACK fa27ee88edbf696b7eef2efbfcf1446ec522fd85

Tree-SHA512: 40c8594d2a5ce02a392ac5f9f120c24c6bcd495b0bcc901fd6064dde9f6123cd109504cee7b612a9555b70cfd7759cbd6cd496d007bb374c27610d01b464191c
2024-01-19 11:02:22 -06:00
MacroFake
e38db57b92
Merge bitcoin/bitcoin#24934: refactor, miner: Delete call to UpdatePackagesForAdded at beginning of addPackageTxs
7036cf52aa080d2a63993c2298555252d507dd2f Delete UpdatePackagesForAdded at beginning of addPackageTxs. (KevinMusgrave)

Pull request description:

  In `CreateNewBlock` (in miner.cpp), `inBlock` is cleared before `addPackageTxs`, so `inBlock` will be empty in the first call to `UpdatePackagesForAdded`. I saw this brought up in these [PR review club logs](https://bitcoincore.reviews/24538) and there didn't seem to be a definitive answer for why the call is necessary. There's also an [old PR](https://github.com/bitcoin/bitcoin/pull/10200) where this change was going to be applied, but it got closed.

  If `addPackageTxs` can be called when `inBlock` is not empty, then maybe a test should be added for that case. All the tests seem to pass with this deletion.

ACKs for top commit:
  glozow:
    utACK 7036cf52aa080d2a63993c2298555252d507dd2f

Tree-SHA512: 9e757b71b9035f68a0c6fef229b8cd83f1bdbe23f05bb02cc1bab8c3c177805b388bceb2bb1f0bce354791ccb29f351a6c51979b96ffe4d9fc6c978f83e36afc
2024-01-19 11:02:22 -06:00
fanquake
b8d3a682fb
Merge bitcoin/bitcoin#24392: build: Fix configuring depends with cmake
ff4a38a32766942ce5c4be6d6510f800a9f8e0d9 build: Fix configuring depends with cmake (Hennadii Stepanov)

Pull request description:

  This PR fixes bitcoin/bitcoin#24389.

  On master (28aa0e3ca0a6cfeb5b2b63929d4bc58de6ee6f02) configuring of the `libmultiprocess` package for the `x86_64-w64-mingw32` target fails:
  ```
  $ cd depends
  $ make libmultiprocess_configured MULTIPROCESS=1 HOST=x86_64-w64-mingw32
  Configuring libmultiprocess...
  CMake Warning:
    No source or binary directory provided.  Both will be assumed to be the
    same as the current working directory, but note that this warning will
    become a fatal error in future CMake releases.

  -- The CXX compiler identification is GNU 9.3.0
  -- Check for working CXX compiler: /usr/bin/x86_64-w64-mingw32-g++-posix
  -- Check for working CXX compiler: /usr/bin/x86_64-w64-mingw32-g++-posix -- broken
  CMake Error at /usr/share/cmake-3.16/Modules/CMakeTestCXXCompiler.cmake:53 (message):
    The C++ compiler

      "/usr/bin/x86_64-w64-mingw32-g++-posix"

    is not able to compile a simple test program.

    It fails with the following output:

      Change Dir: /home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/CMakeFiles/CMakeTmp

      Run Build Command(s):/usr/bin/make cmTC_93273/fast && make[1]: Entering directory '/home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/CMakeFiles/CMakeTmp'
      /usr/bin/make -f CMakeFiles/cmTC_93273.dir/build.make CMakeFiles/cmTC_93273.dir/build
      make[2]: Entering directory '/home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/CMakeFiles/CMakeTmp'
      Building CXX object CMakeFiles/cmTC_93273.dir/testCXXCompiler.cxx.o
      /usr/bin/x86_64-w64-mingw32-g++-posix    -I/home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include     -pipe -O2    -o CMakeFiles/cmTC_93273.dir/testCXXCompiler.cxx.o -c /home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/CMakeFiles/CMakeTmp/testCXXCompiler.cxx
      Linking CXX executable cmTC_93273
      /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_93273.dir/link.txt --verbose=1
      /usr/bin/x86_64-w64-mingw32-g++-posix  -I/home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include     -pipe -O2   -L/home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/lib  -rdynamic CMakeFiles/cmTC_93273.dir/testCXXCompiler.cxx.o  -o cmTC_93273
      x86_64-w64-mingw32-g++-posix: error: unrecognized command line option ‘-rdynamic’
      make[2]: *** [CMakeFiles/cmTC_93273.dir/build.make:87: cmTC_93273] Error 1
      make[2]: Leaving directory '/home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/CMakeFiles/CMakeTmp'
      make[1]: *** [Makefile:121: cmTC_93273/fast] Error 2
      make[1]: Leaving directory '/home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/CMakeFiles/CMakeTmp'

    CMake will not be able to correctly generate this project.
  Call Stack (most recent call first):
    CMakeLists.txt:6 (project)

  -- Configuring incomplete, errors occurred!
  See also "/home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/CMakeFiles/CMakeOutput.log".
  See also "/home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/CMakeFiles/CMakeError.log".
  make: *** [funcs.mk:283: /home/hebasto/GitHub/bitcoin/depends/work/build/x86_64-w64-mingw32/libmultiprocess/d576d975debdc9090bd2582f83f49c76c0061698-f496b1e64cb/./.stamp_configured] Error 1

  ```

  The reason of that failure is the unset `-DCMAKE_SYSTEM_NAME` flag:
  ```
  $ make print-libmultiprocess_cmake MULTIPROCESS=1 HOST=x86_64-w64-mingw32
  libmultiprocess_cmake=env CC="x86_64-w64-mingw32-gcc" CFLAGS="  -I/home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include     -pipe -O2    " CXX="x86_64-w64-mingw32-g++-posix" CXXFLAGS="  -I/home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include     -pipe -O2    " LDFLAGS="  -L/home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/lib    " cmake -DCMAKE_INSTALL_PREFIX:PATH="/home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32" -DCMAKE_SYSTEM_NAME= -DCMAKE_C_COMPILER_TARGET=x86_64-w64-mingw32 -DCMAKE_CXX_COMPILER_TARGET=x86_64-w64-mingw32
  ```

  This PR fixes this error:
  ```
  $ make libmultiprocess_configured MULTIPROCESS=1 HOST=x86_64-w64-mingw32
  $ # no errors
  ```

ACKs for top commit:
  fanquake:
    ACK ff4a38a32766942ce5c4be6d6510f800a9f8e0d9 - going to merge this now, and we can follow up with more cmake improvements.

Tree-SHA512: bd8d8b2f4eedcc8c46cf995b9c39493ea4d0b13c224f77ef62985304ebd392f05119043a06f1401c64f962007a8faa4bb53715d99a408ee6c33bb49a2dd650ba
2024-01-19 11:02:22 -06:00
fanquake
07b9ebccf9
Merge bitcoin/bitcoin#24871: refactor: Simplify GetTime
0000a63689036dc4368d04c0648a55fdf507932f Simplify GetTime (MarcoFalke)

Pull request description:

  The implementation of `GetTime` is confusing:
  * The value returned by `GetTime` is assumed to be equal to `GetTime<std::chrono::seconds>()`. Both are mockable and the only difference is return type, the value itself is equal. However, the implementation does not support this assumption.
  * On some systems, `time_t` might be a signed 32-bit integer (https://en.cppreference.com/w/c/chrono/time), thus breaking in the year 2038, whereas `GetTime<std::chrono::seconds>` does not. Also, `time_t` might be `-1` "on error", where "error" is unspecified.
  * `GetTime<std::chrono::seconds>` calls `GetTimeMicros`, which calls `GetSystemTime`, which calls `std::chrono::system_clock::now`, which doesn't have the above issues. See https://en.cppreference.com/w/cpp/chrono/system_clock/now
  * `GetTimeMicros` and the internal-only `GetSystemTime` will likely be renamed (to clarify they are the non-mockable non-monotonic system time) or removed in the future to be replaced by appropriate `std::chrono::time_point<Clock>` getters.

  Fix all issues by:
  * making `GetTime()` an alias for `GetTime<std::chrono::seconds>().count()`.
  * inlining the needed parts of `GetSystemTime` directly instead of needlessly increasing the function call stack with functions that are likely to be removed in the future.

ACKs for top commit:
  martinus:
    Code review, untested ACK 0000a63689036dc4368d04c0648a55fdf507932f. By the way strictly speaking `std::chrono::system_clock` is only guaranteed to be based on the unix epoch starting with C++20: https://en.cppreference.com/w/cpp/chrono/system_clock
  theStack:
    Code-review ACK 0000a63689036dc4368d04c0648a55fdf507932f

Tree-SHA512: f751ba740e0da65537be800e9414dd02282d9f04c0b0fb986a36546f257d0b888d8688653cdda5d355ec832c0e09d866922d9161b1ccd33485c1c92c5d1e802f
2024-01-19 11:02:21 -06:00
fanquake
0a383e019d
Merge bitcoin/bitcoin#24240: depends: fix capnp's descriptor for make download
01e121d29087db047e4bc01bd64d054f83cfc5df depends: fix capnp's descriptor for make download (Cory Fields)

Pull request description:

  The non-native capnp was trying to fetch the wrong file.
  Without this, "make -C depends MULTIPROCESS=1 download" is broken.

  Presumably it breaks with the download target because the dependency graph is flattened. It manages to work if native_capnp is encountered first because it will then be found in the cache.

ACKs for top commit:
  gruve-p:
    tACK 01e121d290
  hebasto:
    ACK 01e121d29087db047e4bc01bd64d054f83cfc5df, tested on Linux Mint 20.2 (x86_64).

Tree-SHA512: 2605d895f3799be5a311f6f7d36a5c13cdb715dc148915ad818f4afc7d5de92cd6b8ecd34ff2b21cef6743b090819bba1e3353096cfb5659c55f76113ce5adf3
2024-01-19 11:02:21 -06:00
MarcoFalke
adff1fc13b
Merge bitcoin/bitcoin#22102: Remove Warning: from warning message printed for unknown new rules
6d7e46ce23217da53ff52f535879c393c02fa2b2 Remove `Warning:` (Prayank)

Pull request description:

  Reason: I noticed that `Warning` is printed 2 times in `-getinfo` while reviewing https://github.com/bitcoin/bitcoin/pull/21832#issuecomment-851004943

  Same string is used for GUI, log and stderr. If we need to add `Warning:` in GUI or other place we can always prepend to this string.

  CLI:

  ```
  Warnings: Unknown new rules activated (versionbit 28)

  ```

  GUI:

  ![image](https://user-images.githubusercontent.com/13405205/120110401-e36ab180-c18a-11eb-8031-4d52287dc263.png)

ACKs for top commit:
  MarcoFalke:
    review ACK 6d7e46ce23217da53ff52f535879c393c02fa2b2

Tree-SHA512: 25760cf6d850f6c2216d651fa46574d2d21a9d58f4577ecb58f9566ea8cd07bfcd6679bb8a1f53575e441b02d295306f492c0c99a48c909e60e5d977ec1861f6
2024-01-19 11:02:21 -06:00
fanquake
701f785686
Merge #21403: build: set --build when configuring packages in depends
735610940c0cac72343ca247eb3062b2e09512a0 build: set --build when configuring packages in depends (fanquake)

Pull request description:

  After reading [#Specifying-Target-Triplets](https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/autoconf.html#Specifying-Target-Triplets) in the autoconf manuel, my understanding is that this change should mostly be a no-op, as `--build` defaults to the output of [`config.guess`](https://github.com/bitcoin/bitcoin/blob/master/depends/config.guess), however, this may be slightly more correct

  >  For historical reasons, whenever you specify --host, be sure to specify --build too; this will be fixed in the future.

  and will quell some warnings in depends (#16354), i.e:
  > configure: WARNING: If you wanted to set the --build type, don't use --host.
      If a cross compiler is detected then cross compile mode will be used.

  If anything, this also explicitly enables cross-compilation mode when `--host` differs from `--build`. As for "fixed in the future", this is the case for Autoconf 2.70+.

  If we don't make this change, I think we should consider closing #16354. We've now got a good handle on our depends configure flags, and we can just leave the last few warnings as they are. It's also unlikely that we are going to add the `xorg-macros` package to depends.

  Guix builds at 735610940c0cac72343ca247eb3062b2e09512a0:
  ```bash
  bash-5.1# find output -type f -name *$(git rev-parse --short HEAD)*.* -print0 | env LC_ALL=C sort -z | xargs -r0 sha256sum
  afabf99650d57abd3df2c7e6253a3281f9814ada77d01c28ffb57c740b14fd8e  output/bitcoin-735610940c0c-aarch64-linux-gnu-debug.tar.gz
  6e9dedced61489f7734c5387ee05823db68eb4b890fa05f11541c1b966576446  output/bitcoin-735610940c0c-aarch64-linux-gnu.tar.gz
  5333a3c5978a61966251e56fedab8e059d9d8a1a7231a0908095bb373204a81f  output/bitcoin-735610940c0c-arm-linux-gnueabihf-debug.tar.gz
  d28e1c166b96e58cf40b3f9801c3050c2785b25eeb261d44eeb31a32a75e134c  output/bitcoin-735610940c0c-arm-linux-gnueabihf.tar.gz
  e00b0149c52e9207be1cfb56ec3b715b55f41691401095f7a7038ac124f08d80  output/bitcoin-735610940c0c-osx-unsigned.dmg
  ae5052ad1a05916bc6656b034c169097471fd9bdba16b606e2bcb592c9395544  output/bitcoin-735610940c0c-osx-unsigned.tar.gz
  8586a9b8b82a8832397fcd0756aa9649adc3e61ae579fb370b99fe406298199f  output/bitcoin-735610940c0c-osx64.tar.gz
  d560a8781bae856b6593e9b731fa99de0a4ad7bd3e03084166dc98904ece9e7b  output/bitcoin-735610940c0c-powerpc64-linux-gnu-debug.tar.gz
  a24cf28b7efd5ebdc892e7e8809a05b3405bb4222f7d2eaa32de265214c78f28  output/bitcoin-735610940c0c-powerpc64-linux-gnu.tar.gz
  ad29421842dbbe96526eb597a7ff2970f0acae8c3e75dc6c2100716a2ba20606  output/bitcoin-735610940c0c-powerpc64le-linux-gnu-debug.tar.gz
  ee7a8ccfd68cc2297bb96eaaacf7b3eb939a5e39cecc3c710dbe828518f1bfbd  output/bitcoin-735610940c0c-powerpc64le-linux-gnu.tar.gz
  185bf4ea3b35072a8dd54aedbafc0892ec1e486c8ebd311f05f0fb47a19058cf  output/bitcoin-735610940c0c-riscv64-linux-gnu-debug.tar.gz
  803078b15a9bbaa567176827639895e762edbe80844b80400f8a9581e5311d32  output/bitcoin-735610940c0c-riscv64-linux-gnu.tar.gz
  d920327a32a42a5abadd247f0d3f3ee0ab0488a28892c11838d99bede6456723  output/bitcoin-735610940c0c-win-unsigned.tar.gz
  9f1741a37e294af153d57ad4a6dad3e5f1cdf75f1588c86cb467abf0c177ae27  output/bitcoin-735610940c0c-win64-debug.zip
  2d1a91552c0dd7bb400ce6c71d2e98de702743a97afe5f4b0945865f251f3aea  output/bitcoin-735610940c0c-win64-setup-unsigned.exe
  8a70020bb0cb68516acf4b2cc89832d72373f31611bd075826a30a817a071cd2  output/bitcoin-735610940c0c-win64.zip
  93b03837679474905538e96c44ba81ee5653795ad333dc00569b92c82dc6ea31  output/bitcoin-735610940c0c-x86_64-linux-gnu-debug.tar.gz
  6ccd046a83ef5089667ad426875319beb83e2b2a5fb4d4459d5c5ce8d75f1a31  output/bitcoin-735610940c0c-x86_64-linux-gnu.tar.gz
  12771acb17de84cda8e81c59704c00b1d4725ff51fa84c9067dc61a8dc795bdc  output/src/bitcoin-735610940c0c.tar.gz
  ```

  Gitian builds:
  ```bash
  # macOS:
  7d087749f610e5e3eca91c730d41afd4d404808e276242d05cedb89403de247f  bitcoin-735610940c0c-osx-unsigned.dmg
  96d68b4f0042dc40f5e8e362fa84dcf8e122dcb566889feb48ad8a982847dd8b  bitcoin-735610940c0c-osx-unsigned.tar.gz
  2dea72cbe5c3e228babd88b516a6f43b0e040e9510ea95b62f07fc0815bf8d22  bitcoin-735610940c0c-osx64.tar.gz
  12771acb17de84cda8e81c59704c00b1d4725ff51fa84c9067dc61a8dc795bdc  src/bitcoin-735610940c0c.tar.gz
  478dbda9d551a8bed985c61c625df3f543afab26989a52bc44d5a4745715af81  bitcoin-core-osx-22-res.yml

  # Windows:
  c31a5118dfa21259b9868e2c4858c635becb786c2ee8af92302da7811a1efe9b  bitcoin-735610940c0c-win-unsigned.tar.gz
  5c171ec3aee830abc8ae843d674d5fe7a57420e782ee765b6992914ae5b7671a  bitcoin-735610940c0c-win64-debug.zip
  ca010ced982f75d111e01f3759b961deb83e7bf511b1ee9c9041f4830570f2a0  bitcoin-735610940c0c-win64-setup-unsigned.exe
  62514b01281f81af6057fb12cc5e3813c1d8f6532d0d8ac8f6f2909a595aa1dd  bitcoin-735610940c0c-win64.zip
  12771acb17de84cda8e81c59704c00b1d4725ff51fa84c9067dc61a8dc795bdc  src/bitcoin-735610940c0c.tar.gz
  e26b55d8302a419f594396db6ff441aaeb5e275e02fde7b1b4eb092270f902e7  bitcoin-core-win-22-res.yml

  # Linux:
  e5be4deb91cb372de484468c0575a04f907f982e35a9841659bb213540f770d0  bitcoin-735610940c0c-aarch64-linux-gnu-debug.tar.gz
  6169e822679ece2bb6af7027362a6f373eb939eef9d89edc58c21190b4083c7d  bitcoin-735610940c0c-aarch64-linux-gnu.tar.gz
  aee5308767c5c930853a80ab94325b2a4ab3dbe9a7a20c7a9d60d57af2b5383f  bitcoin-735610940c0c-arm-linux-gnueabihf-debug.tar.gz
  a9cf6e56d859fffd5a2b5f1e6360515bc6b06b048776b93cc08954859457a251  bitcoin-735610940c0c-arm-linux-gnueabihf.tar.gz
  7617d85c358e6614fd40026a8d346f9edba5b5139e3daade2ec2aec72aed3a1f  bitcoin-735610940c0c-powerpc64-linux-gnu-debug.tar.gz
  f76e46a8b130812541ebcaaba173b4cbe2ec1781e348579b44f96e9244cc2475  bitcoin-735610940c0c-powerpc64-linux-gnu.tar.gz
  19ada7abb801422bd7772d7ee559004cab11a46141a747aabd27085e8c3d200d  bitcoin-735610940c0c-powerpc64le-linux-gnu-debug.tar.gz
  f3a6bbefe9f47b3960e3b9eeb3f740ecddf8773ae76961ced6a3cdf82503e37f  bitcoin-735610940c0c-powerpc64le-linux-gnu.tar.gz
  42ca333e8f82b4ec0b2354efc7c4f1c27ed32d60c35b88e33d26833419f19e69  bitcoin-735610940c0c-riscv64-linux-gnu-debug.tar.gz
  dde930d9134fb5be1374014db3f6f503b614ae801a1d77f6f4b82a5f11eb2518  bitcoin-735610940c0c-riscv64-linux-gnu.tar.gz
  82e1b4cc8aac309a99458cc27fd0285215a8af53780094c4990303ce8948cf0c  bitcoin-735610940c0c-x86_64-linux-gnu-debug.tar.gz
  ee8caad2ccddd8eaf8aa2d19040d859130168183355b09a2a0f77a59a97fcaee  bitcoin-735610940c0c-x86_64-linux-gnu.tar.gz
  12771acb17de84cda8e81c59704c00b1d4725ff51fa84c9067dc61a8dc795bdc  src/bitcoin-735610940c0c.tar.gz
  d90545b13226a338c994d9e538f468a6fafd694273bf71e14614feeaf5727ad4  bitcoin-core-linux-22-res.yml
  ```

ACKs for top commit:
  dongcarl:
    Code Review ACK 735610940c0cac72343ca247eb3062b2e09512a0
  hebasto:
    ACK 735610940c0cac72343ca247eb3062b2e09512a0, tested on Linux Mint 20.1 (x86_64).

Tree-SHA512: 13ce05269309a12d03b81a539ba5585003785f7b1bb7894a9353385a6e9c709f920cc4f79322f28d7a256809754f201e70be6b917915c7b14e1461530075781d
2024-01-19 11:02:19 -06:00
Konstantin Akimov
1bde13c185
fix: qt's way to do stretching columns after bitcoin-core/gui#204 (#5831)
## Issue being fixed or feature implemented
After bitcoin-core/gui#204 is wrong column is stretched as mentioned in
#5829

It's not the last column that must be stretched, it's the one before it.
The size of "Address / Label" column should also be adjusted accordingly
on window resize. gui#204 broke this behaviour.

## What was done?
This PR uses QT internal features to aim same behaviour as before
gui-204


## How Has This Been Tested?
Run, resize window - seems as proper column changing size.

## 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

---------

Co-authored-by: UdjinM6 <UdjinM6@users.noreply.github.com>
2024-01-19 10:37:44 -06:00
PastaPastaPasta
1c04053855
Merge pull request #5827 from knst/bp-v21-p12
backport: bitcoin#19585, #19590, #19605, #19613, #19620, #19655, #19660, #27629, bitcoin-core/gui#14, #34
2024-01-19 10:35:36 -06:00
Wladimir J. van der Laan
bfc5f4bcc5
Merge #19655: rpc: Catch listsinceblock target_confirmations exceeding block count
c133cdcdc3397a734d57e05494682bf9bf6f4c15 Cap listsinceblock target_confirmations param (Adam Stein)

Pull request description:

  This addresses an issue brought up in #19587.

  Currently, the `target_confirmations` parameter to `listsinceblock` is not checked for being too large. When `target_confirmations` is greater than one more than the current number of blocks, `listsinceblock` fails with error code -1. In comparison, when `target_confirmations` is less than 1,  a -8 "Invalid parameter" error code is thrown.

  This PR fixes the issue by returning a -8 "Invalid parameter" error if the `target_confirmations` value corresponds to a block with more confirmations than the genesis block. This happens if `target_confirmations` exceeds one more than the number of blocks.

ACKs for top commit:
  laanwj:
    Code review ACK c133cdcdc3397a734d57e05494682bf9bf6f4c15
  ryanofsky:
    Code review ACK c133cdcdc3397a734d57e05494682bf9bf6f4c15. Just suggested changes since last review. Thanks!

Tree-SHA512: 02680f4cb937d2c24d5019abd0ebfa188b8a50679a1e64e9c26bfe5c17eef6aea906832e6e2d492ba8a2ea160041bf185d66795ee691e340f6793db03c21b89a
2024-01-19 10:34:33 -06:00
fanquake
649eaa44a1
Merge #19605: doc: set CC_FOR_BUILD when building on OpenBSD
01cd24c22606408d5c0ac74c9a2c5d85eff77846 doc: set CC_FOR_BUILD when building on OpenBSD (fanquake)

Pull request description:

  Closes: #19559

  While #19559 has been fixed upstream, it makes sense to not only
  recommend using `CC_FOR_BUILD`here  until the fix is pulled in as
  part of our next libsecp update, but after discussing with Cory,
  he suggested we should be setting this on OpenBSD (which still has
  the an ancient GCC) regardless.

ACKs for top commit:
  real-or-random:
    ACK 01cd24c22606408d5c0ac74c9a2c5d85eff77846 I looked at the diff (but can't test the instructions on OpenBSD)
  laanwj:
    Code review ACK 01cd24c22606408d5c0ac74c9a2c5d85eff77846

Tree-SHA512: 322802b9303771f1be2ad9628f268dfa71dc7ee77948fa2a34f21eceb19b2d8efdd8876c8f0778adbfcde48fa0f88cd4e698ae425428159abca38e8c7980da1d
2024-01-19 10:34:33 -06:00
Wladimir J. van der Laan
a728478afb
Merge #19660: refactor: Make HexStr take a span
0a8aa626dd69a357e1b798b07b64cf4177a464a3 refactor: Make HexStr take a span (Wladimir J. van der Laan)

Pull request description:

  Make `HexSt`r take a span of bytes, instead of an awkward pair of templated iterators. This simplifies most of the uses.

ACKs for top commit:
  elichai:
    Code review ACK 0a8aa626dd69a357e1b798b07b64cf4177a464a3
  hebasto:
    re-ACK 0a8aa626dd69a357e1b798b07b64cf4177a464a3
  jonatack:
    re-ACK 0a8aa626dd69a357e1b798b07b64cf4177a464a3

Tree-SHA512: 6e178ece5cbac62119c857a10299b1e85422938084c3f03063e17119a5129e0c28016e05a6fabaa4c271a7e0a37c7cd89fa47c435ee19b38a5acfe80d00de992
2024-01-19 10:34:32 -06:00
fanquake
8ef196d9b8
Merge #19620: Add txids with non-standard inputs to reject filter
9f88ded82b2898ca63d44c08072f1ba52f0e18d7 test addition of unknown segwit spends to txid reject filter (Gregory Sanders)
7989901c7eb62ca28b3d1e5d5831041a7267e495 Add txids with non-standard inputs to reject filter (Suhas Daftuar)

Pull request description:

  Our policy checks for non-standard inputs depend only on the non-witness
  portion of a transaction: we look up the scriptPubKey of the input being
  spent from our UTXO set (which is covered by the input txid), and the p2sh
  checks only rely on the scriptSig portion of the input.

  Consequently it's safe to add txids of transactions that fail these checks to
  the reject filter, as the witness is irrelevant to the failure. This is helpful
  for any situation where we might request the transaction again via txid (either
  from txid-relay peers, or if we might fetch the transaction via txid due to
  parent-fetching of orphans).

  Further, in preparation for future witness versions being deployed on the
  network, ensure that WITNESS_UNKNOWN transactions are rejected in
  AreInputsStandard(), so that transactions spending v1 (or greater) witness
  outputs will fall into this category of having their txid added to the reject
  filter.

ACKs for top commit:
  ajtowns:
    ACK 9f88ded82b2898ca63d44c08072f1ba52f0e18d7 - code review
  jnewbery:
    Code review ACK 9f88ded82b2898ca63d44c08072f1ba52f0e18d7
  ariard:
    Code Review/Tested ACK 9f88ded
  naumenkogs:
    utACK 9f88ded82b2898ca63d44c08072f1ba52f0e18d7
  jonatack:
    ACK 9f88ded82b2

Tree-SHA512: 1e93c0a5b68cb432524780ffc0093db893911fdfed9e2ed17f888e59114cc75d2a07062aefad4e5ce2e87c9270886117a8abb3c78fb889c9b9f31967f1777148
2024-01-19 10:34:32 -06:00
Konstantin Akimov
0b0cc82819
docs: adds bips.md clarification 2024-01-19 10:34:32 -06:00
Andrew Chow
a888d336cd
Merge bitcoin/bitcoin#27629: doc: remove version number from bips.md
308caf326db5619141f0c224fa48410293d59330 doc: remove version number from bips.md (fanquake)

Pull request description:

  This always just needs "bumping" (see previous rc type pulls), and the version number is already whichever version of the code you acquired bips.md with.

ACKs for top commit:
  MarcoFalke:
    lgtm ACK 308caf326db5619141f0c224fa48410293d59330
  achow101:
    ACK 308caf326db5619141f0c224fa48410293d59330
  theStack:
    ACK 308caf326db5619141f0c224fa48410293d59330
  hebasto:
    ACK 308caf326db5619141f0c224fa48410293d59330

Tree-SHA512: fcb98e7cdc0c1f8960bfba86be09c2badb36b613060fae394a56e1561c69d28f433434f573c8b1ae1d71ae326277dea2a4841d5c08ad39f8e8848300743146e7
2024-01-19 10:34:32 -06:00
MarcoFalke
bd1e2b0003
Merge #19585: rpc: RPCResult Type of MempoolEntryDescription should be OBJ.
ae4958be95a1158de9992a8e43ce032d87c74f13 rpc: RPCResult Type of MempoolEntryDescription should be OBJ. If multiple entries are possible, wrapping Type should be OBJ_DYN. fixes #19579 (Chris L)

Pull request description:

  If multiple entries are possible, wrapping Type should be OBJ_DYN.

  fixes #19579

Top commit has no ACKs.

Tree-SHA512: 59cf9f6e9729a69a867e924d8306e0cd6b70a3d702fc5a4111345874bb1224ee51ac3f70cea61b25cfe6bde7f65cb02528d52acc20dda4eda692eddf34f217e8
2024-01-19 10:34:31 -06:00
Wladimir J. van der Laan
09f98c5880
Merge #19590: p2p, refactor: add CInv transaction message helpers; use in net processing
c251d710a4c2981c6d52362a9a89db84da3d4a67 p2p, refactoring: use CInv helpers in net_processing.cpp (Jon Atack)
4254cd9f8f2437a916b06db4d925ce4eff8c94b9 p2p: add CInv transaction message helper methods (Jon Atack)

Pull request description:

  Following the merge of wtxid relay in #18044, this is the first of three refactoring PRs (this one, #19610, and #19611) with no change in behavior, tightly scoped to ease review, to simplify the net processing code and improve encapsulation:

  - add `CInv` transaction message helper methods, defined in the class

  - use the new helpers in `net_processing.cpp` to simplify the code and improve encapsulation

  Test coverage is provided by the functional p2p tests, notably (from seeing which tests failed when breaking things to test coverage) `p2p_segwit`, `p2p_tx_download`, `p2p_feefilter`, and `p2p_permissions`.

ACKs for top commit:
  fjahr:
    Code review ACK c251d710a4c2981c6d52362a9a89db84da3d4a67
  laanwj:
    Code review ACK c251d710a4c2981c6d52362a9a89db84da3d4a67
  vasild:
    ACK c251d71
  theStack:
    Code-Review ACK c251d710a4c2981c6d52362a9a89db84da3d4a67
  hebasto:
    ACK c251d710a4c2981c6d52362a9a89db84da3d4a67, I have reviewed the code and it looks OK, I agree it can be merged.

Tree-SHA512: ead034b3c9e438909b4c5010c570d7930e69063c114290b051b7cebfd9bd5b19f573218bebe8a521256d32e830797f997adad3d85b4539c64ac5762b698e656d
2024-01-19 10:34:31 -06:00
MarcoFalke
ab65f64c8f
Merge #19613: travis: Re-enable s390x
fae656144e9ec25a0b610cd5278c1b7c42880097 travis: Re-enable s390x (MarcoFalke)

Pull request description:

  According to travis, the issue has been solved. Quote

  > I would like to confirm that we have resolved this issue and most of our users are reported that this issue has been resolved on their end as well. Could you please re-check and see if that still exists for you?

ACKs for top commit:
  theStack:
    ACK fae656144e

Tree-SHA512: cf42f96d25474a9dcf0817a049e30e29714731d708f73c40a3042b0c70a71ff08f07dd96a89f0dcd5a50a63a355cf30b3511172a32b8af7d5a2e13ad222a4b49
2024-01-19 10:34:31 -06:00
Konstantin Akimov
4b8dc1e435
Merge bitcoin-core/gui#14: scripted-diff: rename movie folder to animation
80968cf scripted-diff: rename movie folder to animation (Peter Bushnell)

Pull request description:

  Rename the movies directory and RES_MOVIES make variable to animation and RES_ANIMATION respectively. Movies is a bit of an unexpected term to be found.

ACKs for top commit:
  MarcoFalke:
    ACK 80968cf
  hebasto:
    ACK 80968cf, tested on Linux Mint 20 (Qt 5.12.8).

Tree-SHA512: 6bd31ce36e821f6a1bef8a7972086a2387d6258c48fc9df12d3ffdae07d0237036afbc2dec673384b78d9567b91d6e12eafa59fa2305aa79153dfd9b7c3a8655
2024-01-19 10:34:31 -06:00
MarcoFalke
4a9f382f01
Merge bitcoin-core/gui#34: Show permissions instead of whitelisted
784ef8be41c7e5130a6b063b359031ee1ce75aff gui: Show permissions instead of whitelisted (Wladimir J. van der Laan)

Pull request description:

  Show detailed permissions instead of legacy "whitelisted" flag in the peer list details.
  These are formatted with `&` in between just like services flags. It reuses the "N/A" translation message if there are no special permissions.
  This removes the one-but-last use of `legacyWhitelisted`.

Top commit has no ACKs.

Tree-SHA512: 11982da4b9d408c74bc56bb3c540c0eb22506be6353aa4d4d6c64461d140f0587be194e2daad1612fddaa2618025a856b33928ad89041558f418f721f6abd407
2024-01-19 10:34:30 -06:00
Konstantin Akimov
d5c5a266f5
fix: make llmq_test_instantsend great again (#5832)
## Issue being fixed or feature implemented
Running 3 nodes on RegTest as platform does uses do not let to create
`llmq_test_instantsend` quorum:

```
1. switch to `llmq_test_instantsend`:
+        self.extra_args = [["-llmqtestinstantsenddip0024=llmq_test_instantsend"]] * 5

2. removed cycle-quorum related code:

-        self.move_to_next_cycle()
-        self.log.info("Cycle H height:" + str(self.nodes[0].getblockcount()))
-        self.move_to_next_cycle()
-        self.log.info("Cycle H+C height:" + str(self.nodes[0].getblockcount()))
-        self.move_to_next_cycle()
-        self.log.info("Cycle H+2C height:" + str(self.nodes[0].getblockcount()))
-
-        self.mine_cycle_quorum(llmq_type_name='llmq_test_dip0024', llmq_type=103)

3. added new quorum:

+        self.mine_quorum(llmq_type_name='llmq_test_instantsend', llmq_type=104)

and eventually it stucked, no quorum happens

2024-01-13T19:18:49.317000Z TestFramework (INFO): Expected quorum_0 at:984
2024-01-13T19:18:49.317000Z TestFramework (INFO): Expected quorum_0 hash:6788e18f0235a5c85f3d3c6233fe132a80e74a2912256db3ad876a8ebf026048
2024-01-13T19:18:49.317000Z TestFramework (INFO): quorumIndex 0: Waiting for phase 1 (init)
<frozen>
```

## What was done?
Updated condition to enable "llmq_test_instantsend":
 - it is RegTest and DIP0024 is not active
- it is RegTest, DIP0024 is active, and specified as
`llmqTypeDIP0024InstantSend`

## How Has This Been Tested?
Run unit and functional tests.
Beside that functional test feature_asset_locks.py now uses this quorum
for instant send and that's an arrow that hit 2 birds: we have test for
command line option `-llmqtestinstantsenddip0024` and code of
feature_asset_locks.py is simplified.


## Breaking Changes
yes, that's a bugfix that fix quorum `llmq_test_instantsend` absentance
on regtest after dip-0024 activation.

## 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
- [ ] 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)_
2024-01-19 09:14:04 -06:00