aboutsummaryrefslogtreecommitdiff
path: root/src
AgeCommit message (Collapse)Author
2021-07-14Move implementations of non-template fuzz helpersSriram
Moved implementations of `ConsumeTxMemPoolEntry`, `ContainsSpentInput`, `ConsumeNetAddr`, and the methods(open, read, write, seek, close) of FuzzedFileProvider from test/fuzz/util.h to test/fuzz/util.cpp.
2021-07-13refactor: move UpdateTip into CChainStateJames O'Beirne
Makes sense and saves on arguments. Co-authored-by: John Newbery <john@johnnewbery.com>
2021-07-13refactor: no mempool arg to GetCoinsCacheSizeStateJames O'Beirne
Unnecessary argument since we can make use of this->m_mempool Co-authored-by: John Newbery <john@johnnewbery.com>
2021-07-13refactor: move UpdateMempoolForReorg into CChainStateJames O'Beirne
Allows fewer arguments and simplification of call sites. Co-authored-by: John Newbery <john@johnnewbery.com>
2021-07-13validation: make CChainState::m_mempool optionalJames O'Beirne
Since we now have multiple chainstate objects, only one of them is active at any given time. An active chainstate has a mempool, but there's no point to others having one. This change will simplify proposed assumeutxo semantics. See the discussion here: https://github.com/bitcoin/bitcoin/pull/15606#pullrequestreview-692965905 Co-authored-by: Russell Yanofsky <russ@yanofsky.org>
2021-07-13Merge bitcoin/bitcoin#22112: Force port 0 in I2PW. J. van der Laan
4101ec9d2e05a35c35f587a28f1feee6cebcc61b doc: mention that we enforce port=0 in I2P (Vasil Dimov) e0a2b390c144e123e2fc8a289fdff36815476964 addrman: reset I2P ports to 0 when loading from disk (Vasil Dimov) 41cda9d075ebcab1dbb950160ebe9d0ba7b5745e test: ensure I2P ports are handled as expected (Vasil Dimov) 4f432bd738c420512a86a51ab3e00323f396b89e net: do not connect to I2P hosts on port!=0 (Vasil Dimov) 1f096f091ebd88efb18154b8894a38122c39624f net: distinguish default port per network (Vasil Dimov) aeac3bce3ead1f24ca782079ef0defa86fd8cb98 net: change I2P seeds' ports to 0 (Vasil Dimov) 38f900290cc3a839e99bef13474d35e1c02e6b0d net: change assumed I2P port to 0 (Vasil Dimov) Pull request description: _This is an alternative to https://github.com/bitcoin/bitcoin/pull/21514, inspired by https://github.com/bitcoin/bitcoin/pull/21514#issuecomment-815049933. They are mutually exclusive. Just one of them should be merged._ Change assumed ports for I2P to 0 (instead of the default 8333) as this is closer to what actually happens underneath with SAM 3.1 (https://github.com/bitcoin/bitcoin/pull/21514#issuecomment-812632520, https://github.com/bitcoin/bitcoin/pull/21514#issuecomment-816564719). Don't connect to I2P peers with advertised port != 0 (we don't specify a port to our SAM 3.1 proxy and it always connects to port = 0). Note, this change: * Keeps I2P addresses with port != 0 in addrman and relays them to others via P2P gossip. There may be non-bitcoin-core-22.0 peers using SAM 3.2 and for them such addresses may be useful. * Silently refuses to connect to I2P hosts with port != 0. This is ok for automatically chosen peers from addrman. Not so ok for peers provided via `-addnode` or `-connect` - a user who specifies `foo.b32.i2p:1234` (non zero port) may wonder why "nothing is happening". Fixes #21389 ACKs for top commit: laanwj: Code review ACK 4101ec9d2e05a35c35f587a28f1feee6cebcc61b jonatack: re-ACK 4101ec9d2e05a35c35f587a28f1feee6cebcc61b per `git range-diff efff9c3 0b0ee03 4101ec9`, built with DDEBUG_ADDRMAN, did fairly extensive testing on mainnet both with and without a peers.dat / -dnsseeds=0 to test boostrapping. Tree-SHA512: 0e3c019e1dc05e54f559275859d3450e0c735596d179e30b66811aad9d5b5fabe3dcc44571e8f7b99f9fe16453eee393d6e153454dd873b9ff14907d4e6354fe
2021-07-12init: remove straggling boost thread_group codefanquake
boost::thread_group usage was removed in #21016.
2021-07-12Merge bitcoin/bitcoin#22432: doc: fix incorrect testmempoolaccept docfanquake
9169be09f49c82fece034285e92f8ffa41e19ee2 fix incorrect testmempoolaccept doc (glozow) Pull request description: Sorry, I somehow missed this... ACKs for top commit: jnewbery: Tested ACK 9169be09f49c82fece034285e92f8ffa41e19ee2 Tree-SHA512: d44f81655669e338af298b7b5d616eb4ca15cbaac667c49251408cb92cee2fb9f440fcfbbac6a17744f24ceeafaf6cea6b9c49a37a464f7eaeeda6e655a56f7a
2021-07-12fix incorrect testmempoolaccept docglozow
2021-07-12Merge bitcoin/bitcoin#20234: net: don't bind on 0.0.0.0 if binds are ↵W. J. van der Laan
restricted to Tor 2feec3ce3130961f98ceb030951d0e46d3b9096c net: don't bind on 0.0.0.0 if binds are restricted to Tor (Vasil Dimov) Pull request description: The semantic of `-bind` is to restrict the binding only to some address. If not specified, then the user does not care and we bind to `0.0.0.0`. If specified then we should honor the restriction and bind only to the specified address. Before this change, if no `-bind` is given then we would bind to `0.0.0.0:8333` and to `127.0.0.1:8334` (incoming Tor) which is ok - the user does not care to restrict the binding. However, if only `-bind=addr:port=onion` is given (without ordinary `-bind=`) then we would bind to `addr:port` _and_ to `0.0.0.0:8333` in addition. Change the above to not do the additional bind: if only `-bind=addr:port=onion` is given (without ordinary `-bind=`) then bind to `addr:port` (only) and consider incoming connections to that as Tor and do not advertise it. I.e. a Tor-only node. ACKs for top commit: laanwj: Code review ACK 2feec3ce3130961f98ceb030951d0e46d3b9096c jonatack: utACK 2feec3ce3130961f98ceb030951d0e46d3b9096c per `git diff a004833 2feec3c` hebasto: ACK 2feec3ce3130961f98ceb030951d0e46d3b9096c, tested on Linux Mint 20.1 (x86_64): Tree-SHA512: a04483af601706da928958b92dc560f9cfcc78ab0bb9d74414636eed1c6f29ed538ce1fb5a17d41ed82c9c9a45ca94899d0966e7ef93da809c9bcdcdb1d1f040
2021-07-12net, rpc: Enable AddrFetch connections for functional testingMartin Zumsande
Co-authored-by: Amiti Uttarwar <amiti@uttarwar.org>
2021-07-09[style] Clean up BroadcastTransaction()John Newbery
2021-07-09[mempool] Allow rebroadcast for same-txid-different-wtxid transactionsJohn Newbery
This commit fixes some slightly unexpected behaviour when: - there is already transaction in the mempool (the "mempool tx") - BroadcastTransaction() is called for a transaction with the same txid as the mempool transaction but a different witness (the "new tx") Prior to this commit, if BroadcastTransaction() is called with relay=true, then it'll call RelayTransaction() using the txid/wtxid of the new tx, not the txid/wtxid of the mempool tx. For wtxid relay peers, in SendMessages(), the wtxid of the new tx will be taken from setInventoryTxToSend, but will then be filtered out from the vector of wtxids to announce, since m_mempool.info() won't find the transaction (the mempool contains the mempool tx, which has a different wtxid from the new tx). Fix this by calling RelayTransaction() with the wtxid of the mempool transaction in this case.
2021-07-09[mempool] Only add a transaction to the unbroadcast set when it's added to ↵John Newbery
the mempool Currently, if BroadcastTransaction() is called to rebroadcast a transaction (e.g. by ResendWalletTransactions()), then we add the transaction to the unbroadcast set. That transaction has already been broadcast in the past, so peers are unlikely to request it again, meaning RemoveUnbroadcastTx() won't be called and it won't be removed from m_unbroadcast_txids. Net processing will therefore continue to attempt rebroadcast for the transaction every 10-15 minutes. This will most likely continue until the node connects to a new peer which hasn't yet seen the transaction (or perhaps indefinitely). Fix by only adding the transaction to the broadcast set when it's added to the mempool.
2021-07-09Merge bitcoin/bitcoin#22253: validation: distinguish between same tx and ↵W. J. van der Laan
same-nonwitness-data tx in mempool b7a8cd9963e810264d3b45d0ad15af863965c47a [test] submit same txid different wtxid as mempool tx (glozow) fdb48163bfbf34f79dc78ffaa2bbf9e39af96687 [validation] distinguish same txid different wtxid in mempool (glozow) Pull request description: On master, if you submit a transaction with the same txid but different witness to the mempool, it thinks the transactions are the same. Users submitting through `BroadcastTransaction()` (i.e. `sendrawtransaction` or the wallet) don't get notified that there's a different transaction in the mempool, although it doesn't crash. Users submitting through `testmempoolaccept()` will get a "txn-already-in-mempool" error. This PR simply distinguishes between `txn-already-in-mempool` and `txn-same-nonwitness-data-in-mempool`, without handling them differently: `sendrawtransaction` still will not throw, but `testmempoolaccept` will give you a different error. I believe the intention of #19645 is to allow full swaps of transactions that have different witnesses but identical nonwitness data. Returning a different error message + adding a test was suggested: https://github.com/bitcoin/bitcoin/pull/19645#issuecomment-705109193 so this is that PR. ACKs for top commit: naumenkogs: ACK b7a8cd9963e810264d3b45d0ad15af863965c47a jnewbery: Code review ACK b7a8cd9963e810264d3b45d0ad15af863965c47a theStack: Code-review ACK b7a8cd9963e810264d3b45d0ad15af863965c47a darosior: re-utACK b7a8cd9963e810264d3b45d0ad15af863965c47a Tree-SHA512: 9c6591edaf8727ba5b4675977adb8cbdef7288584003b6cd659828032dc92d2ae915800a8ef8b6fdffe112c1b660df72297a3dcf2e2e3e1f959c6cb3678c63ee
2021-07-09addrman: reset I2P ports to 0 when loading from diskVasil Dimov
This is a temporary change to convert I2P addresses that have propagated with port 8333 to ones with port 0. It would cause a problem some day if indeed some bitcoin software is listening on port 8333 only and rejects connections to port 0 and we are still using SAM 3.1 which only supports port 0. In this case we would replace 8333 with 0 and try to connect to such nodes. This commit should be included in 22.0 and be reverted before 23.0 is released.
2021-07-09net: do not connect to I2P hosts on port!=0Vasil Dimov
When connecting to an I2P host we don't specify destination port and it is being forced to 0 by the SAM 3.1 proxy, so if we connect to the same host on two different ports, that would be actually two connections to the same service (listening on port 0). Fixes https://github.com/bitcoin/bitcoin/issues/21389
2021-07-09net: distinguish default port per networkVasil Dimov
Change `CChainParams::GetDefaultPort()` to return 0 if the network is I2P.
2021-07-09net: change I2P seeds' ports to 0Vasil Dimov
2021-07-09net: change assumed I2P port to 0Vasil Dimov
* When accepting an I2P connection, assume the peer has port 0 instead of the default 8333 (for mainnet). It is not being sent to us, so we must assume something. * When deriving our own I2P listen CService use port 0 instead of the default 8333 (for mainnet). So that we later advertise it to peers with port 0. In the I2P protocol SAM 3.1 and older (we use 3.1) ports are not used, so they are irrelevant. However in SAM 3.2 and newer ports are used and from the point of view of SAM 3.2, a peer using SAM 3.1 seems to have specified port=0.
2021-07-09Merge bitcoin/bitcoin#22176: test: Correct outstanding -Werror=sign-compare ↵fanquake
errors 4e44f5bac4481d49ac53c458dcc5ca48e8b28414 test: Correct outstanding -Werror=sign-compare errors (Ben Woosley) Pull request description: I'm unclear on why these aren't failing on CI, but they failed for me locally, e.g.: ``` In file included from /usr/local/include/boost/test/test_tools.hpp:46: /usr/local/include/boost/test/tools/old/impl.hpp:107:17: error: comparison of integers of different signs: 'const unsigned int' and 'const int' [-Werror,-Wsign-compare] return left == right; ~~~~ ^ ~~~~~ /usr/local/include/boost/test/tools/old/impl.hpp:130:16: note: in instantiation of function template specialization 'boost::test_tools::tt_detail::equal_impl<unsigned int, int>' requested here return equal_impl( left, right ); ^ /usr/local/include/boost/test/tools/old/impl.hpp:145:16: note: in instantiation of function template specialization 'boost::test_tools::tt_detail::equal_impl_frwd::call_impl<unsigned int, int>' requested here return call_impl( left, right, left_is_array() ); ^ /usr/local/include/boost/test/tools/old/impl.hpp:92:50: note: in instantiation of function template specialization 'boost::test_tools::tt_detail::equal_impl_frwd::operator()<unsigned int, int>' requested here BOOST_PP_REPEAT( BOOST_TEST_MAX_PREDICATE_ARITY, IMPL_FRWD, _ ) ^ /usr/local/include/boost/preprocessor/repetition/repeat.hpp:30:26: note: expanded from macro 'BOOST_PP_REPEAT' ^ /usr/local/include/boost/preprocessor/cat.hpp:22:32: note: expanded from macro 'BOOST_PP_CAT' ^ /usr/local/include/boost/preprocessor/cat.hpp:29:34: note: expanded from macro 'BOOST_PP_CAT_I' ^ <scratch space>:153:1: note: expanded from here BOOST_PP_REPEAT_1 ^ test/streams_tests.cpp:122:5: note: in instantiation of function template specialization 'boost::test_tools::tt_detail::check_frwd<boost::test_tools::tt_detail::equal_impl_frwd, unsigned int, int>' requested here BOOST_CHECK_EQUAL(varint, 54321); ^ /usr/local/include/boost/test/tools/old/impl.hpp:107:17: error: comparison of integers of different signs: 'const unsigned long long' and 'const long' [-Werror,-Wsign-compare] return left == right; ~~~~ ^ ~~~~~ /usr/local/include/boost/test/tools/old/impl.hpp:130:16: note: in instantiation of function template specialization 'boost::test_tools::tt_detail::equal_impl<unsigned long long, long>' requested here return equal_impl( left, right ); ^ /usr/local/include/boost/test/tools/old/impl.hpp:145:16: note: in instantiation of function template specialization 'boost::test_tools::tt_detail::equal_impl_frwd::call_impl<unsigned long long, long>' requested here return call_impl( left, right, left_is_array() ); ^ /usr/local/include/boost/test/tools/old/impl.hpp:92:50: note: in instantiation of function template specialization 'boost::test_tools::tt_detail::equal_impl_frwd::operator()<unsigned long long, long>' requested here BOOST_PP_REPEAT( BOOST_TEST_MAX_PREDICATE_ARITY, IMPL_FRWD, _ ) ^ /usr/local/include/boost/preprocessor/repetition/repeat.hpp:30:26: note: expanded from macro 'BOOST_PP_REPEAT' ^ /usr/local/include/boost/preprocessor/cat.hpp:22:32: note: expanded from macro 'BOOST_PP_CAT' ^ /usr/local/include/boost/preprocessor/cat.hpp:29:34: note: expanded from macro 'BOOST_PP_CAT_I' ^ <scratch space>:161:1: note: expanded from here BOOST_PP_REPEAT_1 ^ test/serfloat_tests.cpp:41:5: note: in instantiation of function template specialization 'boost::test_tools::tt_detail::check_frwd<boost::test_tools::tt_detail::equal_impl_frwd, unsigned long long, long>' requested here BOOST_CHECK_EQUAL(TestDouble(std::numeric_limits<double>::infinity()), 0x7ff0000000000000); ^ ACKs for top commit: theStack: ACK 4e44f5bac4481d49ac53c458dcc5ca48e8b28414 Tree-SHA512: 8d9e5245676c61207ceacdf78c78a78ccc9fd2a2551d4d8df023513795591334aa2f5e1f4a2a8ed2bfeb381f1e226b6ba84c07e0de29a1f3f00da71f3a257bc1
2021-07-09Merge bitcoin/bitcoin#22381: guix: Test security-check sanity before ↵fanquake
performing them (with macOS) 5b4703c6a70db2fa72fcace56a15db07d4b0acf1 guix: Test security-check sanity before performing them (Carl Dong) 6cf3345297d371b4785d80d54e802b52ff09e8c2 scripts: adjust test-symbol-check for guix release environment (fanquake) 1946b5f77cb5a6bb37500252079c3582cac4a6c9 scripts: more robustly test macOS symbol checks (fanquake) a8127b34bce3597b8091e14057c926197966a234 build: Use and test PE binutils with --reloc-section (Carl Dong) 678348db515c770c4dddfac512cdd97be11d407d guix: Patch binutils to add security-related disable flags (Carl Dong) 9fdc8afe117b7b1ea845f8acae9e831922b8f92b devtools: Improve *-check.py tool detection (Carl Dong) bda62eab38c5dd74e222eddedbca19ace9df6daa ci: skip running the Linux test-security-check target for now (fanquake) d6ef3543ae16847d5a91fa9271acee9bd2164b32 lint: Run mypy with --show-error-codes (Carl Dong) Pull request description: This is #20980 rebased (to include the Boost Process fix), and with an additional commit (892d6897f1e613084aa0517a660eab2412308e6e) to fix running the `test-security-check` target for the macOS build. It should pass inside Guix, as well as when cross-compiling on Ubuntu, or building natively on macOS. Note that the `test-security-check` may output some warnings (similar too): ```bash ld: warning: passed two min versions (10.14, 11.4) for platform macOS. Using 11.4. ld: warning: passed two min versions (10.14, 11.4) for platform macOS. Using 11.4. ld: warning: passed two min versions (10.14, 10.14) for platform macOS. Using 10.14. ``` but those can be ignored, and come about due to us passing `-platform_version` when `-mmacosx-version-min` is already part of `CC`. Guix builds: ```bash 71ed0c7a13a4726300779ffc87f7d271086a2744c36896fe6dc51fe3dc33df2e guix-build-5b4703c6a70d/output/aarch64-linux-gnu/SHA256SUMS.part 9273980a17052c8ec45b77579781c14ab5d189fa25aa29907d5115513dd302b1 guix-build-5b4703c6a70d/output/aarch64-linux-gnu/bitcoin-5b4703c6a70d-aarch64-linux-gnu-debug.tar.gz 9c042179af43c8896eb95a34294df15d4910308dcdba40b2010cd36e192938b8 guix-build-5b4703c6a70d/output/aarch64-linux-gnu/bitcoin-5b4703c6a70d-aarch64-linux-gnu.tar.gz 1ceddecac113f50a952ba6a201cdcdb722e3dc804e663f219bfac8268ce42bf0 guix-build-5b4703c6a70d/output/arm-linux-gnueabihf/SHA256SUMS.part 759597c4e925e75db4a2381c06cda9b9f4e4674c23436148676b31c9be05c7aa guix-build-5b4703c6a70d/output/arm-linux-gnueabihf/bitcoin-5b4703c6a70d-arm-linux-gnueabihf-debug.tar.gz 34e3b6beabaf8c95d7c2ca0d2c3ac4411766694ef43e00bd9783badbbaf045a7 guix-build-5b4703c6a70d/output/arm-linux-gnueabihf/bitcoin-5b4703c6a70d-arm-linux-gnueabihf.tar.gz e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 guix-build-5b4703c6a70d/output/dist-archive/SKIPATTEST.TAG 3664f6ceee7898caa374281fd877a7597fe491fa2e9f0c174c28d889d60b559c guix-build-5b4703c6a70d/output/dist-archive/bitcoin-5b4703c6a70d.tar.gz d6bc35ba0750c1440bb32831b8c12cddee62f6dce10fec2650897444c2bf4748 guix-build-5b4703c6a70d/output/powerpc64-linux-gnu/SHA256SUMS.part a836edf6474ba0c16c19bb217549bac7936c1b44306ed512df58f607ee5568f2 guix-build-5b4703c6a70d/output/powerpc64-linux-gnu/bitcoin-5b4703c6a70d-powerpc64-linux-gnu-debug.tar.gz 7cc91c6805d5069ca3bd1771e77d95f83eb184b137198cbf84d1d11d0a5c5afe guix-build-5b4703c6a70d/output/powerpc64-linux-gnu/bitcoin-5b4703c6a70d-powerpc64-linux-gnu.tar.gz 93b4cb7b83c4975120ad5de5a92f050f5760a2a3f2c37c204c647f5a581c924a guix-build-5b4703c6a70d/output/powerpc64le-linux-gnu/SHA256SUMS.part 2266e2c5d0dafa28c6c057ccfc1c439baeab1d714d8c3f64a83015d2827116d2 guix-build-5b4703c6a70d/output/powerpc64le-linux-gnu/bitcoin-5b4703c6a70d-powerpc64le-linux-gnu-debug.tar.gz 85f41f42c319b83d049d6fd2e2278c07b40a1e28a2eac596427822c0eef9dc3f guix-build-5b4703c6a70d/output/powerpc64le-linux-gnu/bitcoin-5b4703c6a70d-powerpc64le-linux-gnu.tar.gz 1499ca9119926083d8c3714ca10d8d4c8d864cbeee8848fd8445b7a1d081222d guix-build-5b4703c6a70d/output/riscv64-linux-gnu/SHA256SUMS.part 1995fc1a2e45c49d4b0718aff5dcdac931917e8ae9e762fd23f1126abcecc248 guix-build-5b4703c6a70d/output/riscv64-linux-gnu/bitcoin-5b4703c6a70d-riscv64-linux-gnu-debug.tar.gz 266889eb58429a470f0fd7bb123f2ae09b0aef86c47b0390938b3634a8f748a9 guix-build-5b4703c6a70d/output/riscv64-linux-gnu/bitcoin-5b4703c6a70d-riscv64-linux-gnu.tar.gz cdc3a0dcf80b110443dac5ddf8bc951001a776a651c898c5ea49bb2d487bfe29 guix-build-5b4703c6a70d/output/x86_64-apple-darwin18/SHA256SUMS.part 8538d1eab96c97866b24546c453d95822f24cf9c6638b42ba523eb7aa441cb26 guix-build-5b4703c6a70d/output/x86_64-apple-darwin18/bitcoin-5b4703c6a70d-osx-unsigned.dmg d1b73133f1da68586b07292a8425f7f851e93f599c016376f23728c041cf39cc guix-build-5b4703c6a70d/output/x86_64-apple-darwin18/bitcoin-5b4703c6a70d-osx-unsigned.tar.gz 5ad94c5f8a5f29405955ff3ab35d137de1acc04398d6c8298fb187b57a6e316a guix-build-5b4703c6a70d/output/x86_64-apple-darwin18/bitcoin-5b4703c6a70d-osx64.tar.gz 8c6d7b3f847faa7b4d16ceecf228f26f146ea982615c1d7a00c57f9230a0c484 guix-build-5b4703c6a70d/output/x86_64-linux-gnu/SHA256SUMS.part d0a8c99750319ad8046cfa132a54e5c13a08351f94439ae9af0f8e5486c2c2ea guix-build-5b4703c6a70d/output/x86_64-linux-gnu/bitcoin-5b4703c6a70d-x86_64-linux-gnu-debug.tar.gz d816bb26dd4b0e309f2f576b1cccc6d78743fb2f357daad2da09bb1177330971 guix-build-5b4703c6a70d/output/x86_64-linux-gnu/bitcoin-5b4703c6a70d-x86_64-linux-gnu.tar.gz 65caaa7f648c7eab1eb82c3331a2ca25b8cd4fe41439de55604501e02571de55 guix-build-5b4703c6a70d/output/x86_64-w64-mingw32/SHA256SUMS.part 5bf6f7328cbceb0db22a2d7babb07b60cb6dcc19a6db84a1698589b7f5173a06 guix-build-5b4703c6a70d/output/x86_64-w64-mingw32/bitcoin-5b4703c6a70d-win-unsigned.tar.gz 7aabcb56115decef78d3797840b6e49dbc9b202d56f892490e92616fb06fec9e guix-build-5b4703c6a70d/output/x86_64-w64-mingw32/bitcoin-5b4703c6a70d-win64-debug.zip 2f369694648ff9dc5ca1261a1e5874b1c7408ccf2802f9caef56c1334e8a5b7c guix-build-5b4703c6a70d/output/x86_64-w64-mingw32/bitcoin-5b4703c6a70d-win64-setup-unsigned.exe 1c1f92513c4aad38419ff49a7b80bf10e6b1eca01ee8c5e3b2acd1768cf1e3d5 guix-build-5b4703c6a70d/output/x86_64-w64-mingw32/bitcoin-5b4703c6a70d-win64.zip ``` ACKs for top commit: hebasto: Approach ACK 5b4703c6a70db2fa72fcace56a15db07d4b0acf1. Tree-SHA512: 2cd92a245ea64ef7176cf402a1fa5348a9421c30a4d30d01c950c48f6dcc15cf22ce69ffe1657be97e5fccc14bd933d64683c4439b695528ce3dc34d72dda927
2021-07-08Merge bitcoin/bitcoin#22179: Torv2 removal followupsW. J. van der Laan
00b875ba9414463d0041da6924fd9b54d6a06dee addrman: remove invalid addresses when unserializing (Vasil Dimov) bdb62096f0109b2ec76849d33d6cf7187dea299f fuzz: reduce possible networks check (Vasil Dimov) a164cd3ba694ffeba03b2887a411b7f82f6c087e net: simplify CNetAddr::IsRoutable() (Vasil Dimov) Pull request description: * Simplify some code, now that we know `CNetAddr::IsRFC4193()` and `CNetAddr::IsTor()` cannot be `true` at the same time. * Drop Tor v2 addresses when loading addrman from `peers.dat` - they would have been loaded as dummy-all-zeros IPv6 addresses and linger in addrman, wasting space. ACKs for top commit: sipa: ACK 00b875ba9414463d0041da6924fd9b54d6a06dee. Reviewed the code, and tested with -DDEBUG_ADDRMAN (unit tests + mainnet run with peers.dat that contained v2 onions). laanwj: Code review and lightly tested ACK 00b875ba9414463d0041da6924fd9b54d6a06dee jonatack: ACK 00b875ba9414463d0041da6924fd9b54d6a06dee reviewed, debug-built with -DEBUG_ADDRMAN rebased to current master, restarted node on mainnet/signet/testnet and verified that on each chain -addrinfo shows no change in address counts (as expected). Added some sanity check asserts, rebuilt/re-ran test. Checked that the new test fails on master with "test/addrman_tests.cpp(824): error: in "addrman_tests/remove_invalid": check addrman.size() == 2 has failed [4 != 2]" jarolrod: ACK 00b875ba9414463d0041da6924fd9b54d6a06dee Tree-SHA512: 6ed8e6745134b1b94fffaba28482de909ea39483b46b7f57bda61cdbae7a51251d15cb674de3631772fbeabe153d77a19269f96e62a89102a2d5c01e48f0ba06
2021-07-08p2p: earlier continuation when no remaining eviction candidatesVasil Dimov
in ProtectEvictionCandidatesByRatio(). With this change, `if (n.count == 0) continue;` will be true if a network had candidates protected in the first iterations and has no candidates remaining to be protected in later iterations. Co-authored-by: Jon Atack <jon@atack.com>
2021-07-08p2p: process more candidates per protection iterationJon Atack
for the usual case when some of the protected networks don't have eviction candidates, to reduce the number of iterations in ProtectEvictionCandidatesByRatio(). Picks up an idea in ef411cd2 that I had dropped.
2021-07-08p2p: iterate eviction protection only on networks having candidatesJon Atack
in ProtectEvictionCandidatesByRatio(). Thank you to Vasil Dimov, whose suggestions during a post-merge discussion about PR 21261 reminded me that I had done this in earlier versions of the PR, e.g. commits like ef411cd2. Co-authored-by: Vasil Dimov <vd@FreeBSD.org>
2021-07-08bench: add peer eviction protection benchmarksJon Atack
Co-authored-by: Vasil Dimov <vd@FreeBSD.org>
2021-07-08[validation] distinguish same txid different wtxid in mempoolglozow
Changes behavior.
2021-07-07net: don't bind on 0.0.0.0 if binds are restricted to TorVasil Dimov
The semantic of `-bind` is to restrict the binding only to some address. If not specified, then the user does not care and we bind to `0.0.0.0`. If specified then we should honor the restriction and bind only to the specified address. Before this change, if no `-bind` is given then we would bind to `0.0.0.0:8333` and to `127.0.0.1:8334` (incoming Tor) which is ok - the user does not care to restrict the binding. However, if only `-bind=addr:port=onion` is given (without ordinary `-bind=`) then we would bind to `addr:port` _and_ to `0.0.0.0:8333` in addition. Change the above to not do the additional bind: if only `-bind=addr:port=onion` is given (without ordinary `-bind=`) then bind to `addr:port` (only) and consider incoming connections to that as Tor and do not advertise it. I.e. a Tor-only node.
2021-07-07devtools: Improve *-check.py tool detectionCarl Dong
This is important to make sure that we're not testing tools different from the one we're building with. Introduce determine_wellknown_cmd, which encapsulates how we should handle well-known tools specification (IFS splitting, env override, etc.).
2021-07-07Merge bitcoin/bitcoin#22405: build: remove --enable-glibc-back-compat from ↵fanquake
Guix build 797b3ed9090030f32fade81803b580562d4a90a3 script: remove gitian reference from symbol-check.py (fanquake) 15fc9a0299091bfeb3370f993ad95ff638f6ba8c guix: add additional documentation to patches (fanquake) 4516e5ec9223486fe2eba7f4320d786d074a58fd lint: exclude Guix patches from spell-checking (fanquake) de6ca41a52d2646598daae5f4620bbe766757e21 guix: no-longer pass --enable-glibc-back-compat to Guix (fanquake) 84dd81fb5bf7308b8070b53520266854fb6efad3 build: remove glibc backcompat requirement for Linux symbol checks (fanquake) Pull request description: Now that our Guix toolchains are based on glibc 2.24 and 2.27 (RISCV), we don't need to use the `--enable-glibc-back-compat` option to produce binaries that don't use any symbols from glibc 2.17 and 2.27 or later. This also adds additional documentation to some Guix patches (pointed out in #22365) and removes Guix patches from the spelling linter, because that isn't our spelling. Symbol usage: https://gist.github.com/fanquake/d15604fc580718444c5aa4b3c3c75fdc. Guix Builds: ```bash bash-5.1# find guix-build-$(git rev-parse --short=12 HEAD)/output/ -type f -print0 | env LC_ALL=C sort -z | xargs -r0 sha256sum ed54e6a6cf4fab328557c0c72eb08c73f2a58c6c70959544cf4b1882e75ea69e guix-build-797b3ed90900/output/aarch64-linux-gnu/SHA256SUMS.part 83bd9dadc59f89f848d143fa4fc3964f16fe0b4bdf35e5093b577ff2c4bd1f43 guix-build-797b3ed90900/output/aarch64-linux-gnu/bitcoin-797b3ed90900-aarch64-linux-gnu-debug.tar.gz 94cb8c35281f12dec6ea5b390b66cad5e27ac8c45a30c42c8d38c438695d54c0 guix-build-797b3ed90900/output/aarch64-linux-gnu/bitcoin-797b3ed90900-aarch64-linux-gnu.tar.gz 7318b63d65c0aa52d2446de8e1f40658d2e47ab8fb0268820c3b7585d140fb23 guix-build-797b3ed90900/output/arm-linux-gnueabihf/SHA256SUMS.part 95e1ffb372964b73f539653ca703b70cf0c018801a9c4c0ffc46a0b63539253c guix-build-797b3ed90900/output/arm-linux-gnueabihf/bitcoin-797b3ed90900-arm-linux-gnueabihf-debug.tar.gz 039d3842e6499626cf955ae0a7590dd6b3d0935cdc217c98aaf9d156b0ebd3b4 guix-build-797b3ed90900/output/arm-linux-gnueabihf/bitcoin-797b3ed90900-arm-linux-gnueabihf.tar.gz e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 guix-build-797b3ed90900/output/dist-archive/SKIPATTEST.TAG 2c4e7b6e7aff63ba811e5bf59362d16866c3a358f8844fba8739a61192870622 guix-build-797b3ed90900/output/dist-archive/bitcoin-797b3ed90900.tar.gz 955029b949c368eabd517dd33040d2f01e2ac6a55e7b4f9107907a7c6e0c6060 guix-build-797b3ed90900/output/powerpc64-linux-gnu/SHA256SUMS.part fd6d6b137f8efedf58a879d11205b1d4649e1f97d7f91e193239ef206fcc285d guix-build-797b3ed90900/output/powerpc64-linux-gnu/bitcoin-797b3ed90900-powerpc64-linux-gnu-debug.tar.gz 51736ac8e77737999f1b5bd4c381b0016f19a8d5e40e786fe941ff04e84c11c9 guix-build-797b3ed90900/output/powerpc64-linux-gnu/bitcoin-797b3ed90900-powerpc64-linux-gnu.tar.gz 8c244c16bfa46c1efdb120e1d91fdd14d3f14eefee8d7e1fbb0a9b4664a5c315 guix-build-797b3ed90900/output/powerpc64le-linux-gnu/SHA256SUMS.part 704ee593251a1b1c65a5bebeef93b23f266af4e8cbf8ae556150c3b2e8f06a6c guix-build-797b3ed90900/output/powerpc64le-linux-gnu/bitcoin-797b3ed90900-powerpc64le-linux-gnu-debug.tar.gz 0ec06ae7d344de20d61e3965d8b383747ef20b0e9d93a3165733ea23bdf2ead8 guix-build-797b3ed90900/output/powerpc64le-linux-gnu/bitcoin-797b3ed90900-powerpc64le-linux-gnu.tar.gz 2dd6c6ecc67b0ea40ca9c43f92efca81ccd054b8db8c197ad84ad9674d510a25 guix-build-797b3ed90900/output/riscv64-linux-gnu/SHA256SUMS.part 5ebb27a855a677f7a188d83995be6b2a3ea8606be152abb7fc7832713fb0677a guix-build-797b3ed90900/output/riscv64-linux-gnu/bitcoin-797b3ed90900-riscv64-linux-gnu-debug.tar.gz bdaf1783f5e1861597afa37c1880364e118d9a7a7af8017302d82202791019f6 guix-build-797b3ed90900/output/riscv64-linux-gnu/bitcoin-797b3ed90900-riscv64-linux-gnu.tar.gz 726c9092b60ac2e7d7e14b2c24467fcf276a6f89170a871ddab9dce6ac230699 guix-build-797b3ed90900/output/x86_64-apple-darwin18/SHA256SUMS.part 2af4d709b44952654f3c08c86593bf2ccc9a44ed422783a1b95b8a199a894db2 guix-build-797b3ed90900/output/x86_64-apple-darwin18/bitcoin-797b3ed90900-osx-unsigned.dmg fd49ba445aa6cf3d8c47019a05e9e5740cb0f53349344dd80671297127f49f1a guix-build-797b3ed90900/output/x86_64-apple-darwin18/bitcoin-797b3ed90900-osx-unsigned.tar.gz 3f51cbf8cf18420d4be70e656aa993675cf5e828a255c2030047ae2e059ed5b7 guix-build-797b3ed90900/output/x86_64-apple-darwin18/bitcoin-797b3ed90900-osx64.tar.gz afd1edee1447bb88d81e972abfae4c4e065b5b1827769f033cff9472084c7c1b guix-build-797b3ed90900/output/x86_64-linux-gnu/SHA256SUMS.part ec468ef886d25e685f4f7a18b4f7d497dedf757495e0d5beb72c23cc32ab69b5 guix-build-797b3ed90900/output/x86_64-linux-gnu/bitcoin-797b3ed90900-x86_64-linux-gnu-debug.tar.gz 1934d7294f0c9e083d38a3f68d4a61cd679defa79ce0a89f77386978692b9b18 guix-build-797b3ed90900/output/x86_64-linux-gnu/bitcoin-797b3ed90900-x86_64-linux-gnu.tar.gz 94c11c328a628052eb6f50e9816aa768f87ea7acfbbbafdab60f6928da766811 guix-build-797b3ed90900/output/x86_64-w64-mingw32/SHA256SUMS.part fd371922ba93d81bd4a2b711d617af6756f9f0494db6d83aa0e5f491a24168ef guix-build-797b3ed90900/output/x86_64-w64-mingw32/bitcoin-797b3ed90900-win-unsigned.tar.gz 4e4ad976bc029bbbf9596ad8493accaaba8b0d5c598dd342f8da330609bbdf21 guix-build-797b3ed90900/output/x86_64-w64-mingw32/bitcoin-797b3ed90900-win64-debug.zip 3a89a16b9101e9a17d98efb9234b5bdd264c0bba2c6326511017730e1a08311f guix-build-797b3ed90900/output/x86_64-w64-mingw32/bitcoin-797b3ed90900-win64-setup-unsigned.exe e285ab737e3c843fd3f1c26c2f053e421a3c39b33995747ce48281884d3f28d1 guix-build-797b3ed90900/output/x86_64-w64-mingw32/bitcoin-797b3ed90900-win64.zip ``` ACKs for top commit: sipa: utACK 797b3ed9090030f32fade81803b580562d4a90a3 hebasto: ACK 797b3ed9090030f32fade81803b580562d4a90a3 Tree-SHA512: 3a569702d8832c155c5ce8d2f6d823f7f12603885576078bc5192bc9038a48261ecb541800f79d1e9bc86d71fa640265c5b8b89df9d8bb680b3bb05d9d78a666
2021-07-07Merge bitcoin/bitcoin#22399: fuzz: Rework CTxDestination fuzzingMarcoFalke
fabf17056c1046c6ac7fa5d140125050b7a2b0e0 fuzz: Move CTxDestination fuzzing to script fuzz target (MarcoFalke) fa42800a51919bb50a1000ac4f58847e6a7092a3 fuzz: Simplify CTxDestination fuzzing in the script target (MarcoFalke) fab99865c0e62468a1b55d7e467398cc2343121b fuzz: Improve ConsumeTxDestination (MarcoFalke) fa40c0964b751683774b79da4b72d330a9ff87e2 fuzz: Move ConsumeTxDestination to cpp file (MarcoFalke) Pull request description: ACKs for top commit: practicalswift: cr ACK fabf17056c1046c6ac7fa5d140125050b7a2b0e0 Tree-SHA512: afd2cf384d04a810c0c462c6d80849bd0fefd017d7acac877f64f2bffae3fc8d687701bc479e67a727a05f43431a17cb4ccaf09c6b3c68106562c94b7ed19250
2021-07-06refactor: move GetRandomNodeEvictionCandidates() to test utilitiesJon Atack
Co-authored-by: Vasil Dimov <vd@FreeBSD.org>
2021-07-06build: remove glibc backcompat requirement for Linux symbol checksfanquake
2021-07-06Merge bitcoin-core/gui#375: Emit dataChanged signal to dynamically re-sort ↵Hennadii Stepanov
Peers table 986bf78d7e8fd9b69841ecb0decaff840efe9cff qt: Emit dataChanged signal to dynamically re-sort Peers table (Hennadii Stepanov) Pull request description: [By default](https://doc.qt.io/qt-5/qsortfilterproxymodel.html#details), the `PeerTableSortProxy` > dynamically re-sorts ... data whenever the original model changes. That is not the case on master (8cdf91735f2bdc55577d84a9915f5920ce23b00a) as in ecbd91153875c8cdd5b92b840afc116f65e457fb (#164) no signals are emitted to notify about model changes. This PR uses a dedicated [`dataChanged`](https://doc.qt.io/qt-5/qabstractitemmodel.html#dataChanged) signal. Fixes #367. An alternative to #374. ACKs for top commit: jarolrod: ACK 986bf78d7e8fd9b69841ecb0decaff840efe9cff Tree-SHA512: dcb92c2f9a2c632880429e9528007db426d2ad938c64dfa1f1538c03e4b62620df52ad7daf33b582976c67b472ff76bc0dae707049f4bbbd4941232cee9ce3d4
2021-07-05Merge bitcoin-core/gui#365: Draw "eye" sign at the beginning of watch-only ↵Hennadii Stepanov
addresses cd46c11577a05f3dc9eac94f27a6985f6ba0509e qt: Draw "eye" sign at the beginning of watch-only addresses (Hennadii Stepanov) 9ea1da6fc91e17bdaa722001b97aadf576f07f65 qt: Do not extend recent transaction width to address/label string (Hennadii Stepanov) Pull request description: This PR guaranties that the "eye" sign won't be hidden for very long addresses/labels. No longer need to extend `TransactionOverviewWidget` widget width to make "eye" signs shown: ![Screenshot from 2021-06-15 00-21-05](https://user-images.githubusercontent.com/32963518/121961807-9123b600-cd70-11eb-8cdd-8b2b0d1bf44f.png) Fixes https://github.com/bitcoin-core/gui/issues/373 ACKs for top commit: jarolrod: ACK cd46c11577a05f3dc9eac94f27a6985f6ba0509e Tree-SHA512: 0602b5bb65d53c5b18e86260750006bba03adbae181917b5a2b7f89b17290bd1f57b4f80adaba32f42cc6fb468598a888b12c0b6b09005d2f2c07bd4d1ad334a
2021-07-05Use C++17 [[fallthrough]] attribute, and drop -Wno-implicit-fallthroughHennadii Stepanov
2021-07-05Merge bitcoin/bitcoin#22292: bench, doc: benchmarking updates and fixupsfanquake
d8513fe41102dcbfc05235f3b95e33eb1878f880 doc: update doc/benchmarking.md (Jon Atack) 84e2d5b78181d08b258c77f9c9c4e1bb7fdaa451 bench: bench_bitcoin.cpp help fixups (Jon Atack) 10f4ce20783cbbcb0c0997c605452d9e60827e6d bench: bench.h fixes and improvements (Jon Atack) Pull request description: Fixups and updates I noticed while writing benchmarks for #22284. ACKs for top commit: za-kk: ACK d8513fe41102dcbfc05235f3b95e33eb1878f880 theStack: ACK d8513fe41102dcbfc05235f3b95e33eb1878f880 🚤 Tree-SHA512: d494956b5d6a3329e98e8b6f4405a10613b8fce51a04bbf4493d8b3497b8d5b177c1a9a3eeb828796eb4edb92b0ace769595151e223671c0dc8f09bcf631ebb5
2021-07-04fuzz: Move CTxDestination fuzzing to script fuzz targetMarcoFalke
No need to split it over several targets
2021-07-04fuzz: Simplify CTxDestination fuzzing in the script targetMarcoFalke
The WitnessUnknown operators == and < are already called indirectly by the corresponding CTxDestination operators.
2021-07-04fuzz: Improve ConsumeTxDestinationMarcoFalke
* Assert when a type is missing * Add missing WitnessV1Taproot * Limit WitnessUnknown to version [2, 16], to avoid abiguity * Limit WitnessUnknown to size [2, 40], to avoid invalid sizes
2021-07-04fuzz: Move ConsumeTxDestination to cpp fileMarcoFalke
Moving the implementation out of the header will reduce compile time
2021-07-01Use DeploymentEnabled to hide VB deploymentsMarcoFalke
The helper was previously unused. This commit changes it to be more meaningful and puts it to use. See previous discussion at https://github.com/bitcoin/bitcoin/pull/19438/files#r650687320
2021-07-01doc: Move buried deployment doc to the enum that enumerates themMarcoFalke
This is more visible than a comment hidden in an RPC helper function.
2021-07-01Merge bitcoin/bitcoin#19438: Introduce deploymentstatusMarcoFalke
e48826ad87b4f92261f7433e84f48dac9bd9e5c3 tests: remove ComputeBlockVersion shortcut from versionbits tests (Anthony Towns) c5f36725e877d8eb492383844f8ef7535466b366 [refactor] Move ComputeBlockVersion into VersionBitsCache (Anthony Towns) 4a69b4dbe0d7f504811b67c399da7e6d11e4f805 [move-only] Move ComputeBlockVersion from validation to versionbits (Anthony Towns) 0cfd6c6a8f929d5567ac41f95c21548f115efee5 [refactor] versionbits: make VersionBitsCache a full class (Anthony Towns) 8ee3e0bed5bf2cd3c7a68ca6ba6c65f7b9a72cca [refactor] rpc/blockchain.cpp: SoftForkPushBack (Anthony Towns) 92f48f360da5f425428b761219301f509826bec4 deploymentinfo: Add DeploymentName() (Anthony Towns) ea68b3a5729f5d240e968388c4f88acffeb27228 [move-only] Rename versionbitsinfo to deploymentinfo (Anthony Towns) c64b2c6a0f79369624ae96b2e3d579d50aae4de6 scripted-diff: rename versionbitscache (Anthony Towns) de55304f6e7a8b607e6b3fc7436de50910747b0c [refactor] Add versionbits deployments to deploymentstatus.h (Anthony Towns) 2b0d291da8f479739ff394dd92801da8c40b9f8e [refactor] Add deploymentstatus.h (Anthony Towns) eccd736f3dc231ac0306ca763c3b72cf8247230a versionbits: Use dedicated lock instead of cs_main (Anthony Towns) 36a4ba0aaaa9b35185d7178994e36bc02cca9887 versionbits: correct doxygen comments (Anthony Towns) Pull request description: Introduces helper functions to make it easy to bury future deployments, along the lines of the suggestion from [11398](https://github.com/bitcoin/bitcoin/pull/11398#issuecomment-335599326) "I would prefer it if a buried deployment wouldn't require all code paths that check the BIP9 status to require changing". This provides three functions: `DeploymentEnabled()` which tests if a deployment can ever be active, `DeploymentActiveAt()` which checks if a deployment should be enforced in the given block, and `DeploymentActiveAfter()` which checks if a deployment should be enforced in the block following the given block, and overloads all three to work both with buried deployments and versionbits deployments. This adds a dedicated lock for the versionbits cache, which is acquired internally by the versionbits functions, rather than relying on `cs_main`. It also moves moves versionbitscache into deploymentstatus to avoid a circular dependency with validation. ACKs for top commit: jnewbery: ACK e48826ad87b4f92261f7433e84f48dac9bd9e5c3 gruve-p: ACK https://github.com/bitcoin/bitcoin/pull/19438/commits/e48826ad87b4f92261f7433e84f48dac9bd9e5c3 MarcoFalke: re-ACK e48826ad87b4f92261f7433e84f48dac9bd9e5c3 🥈 Tree-SHA512: c846ba64436d36f8180046ad551d8b0d9e20509b9bc185aa2639055fc28803dd8ec2d6771ab337e80da0b40009ad959590d5772f84a0bf6199b65190d4155bed
2021-07-01Translations updateHennadii Stepanov
Translation string freeze, see Release schedule for 22.0.
2021-07-01Merge bitcoin/bitcoin#22348: build: Fix cross build for Windows with Boost ↵fanquake
Process 67669ab425b52a2b6be3d2f3b3b7e3939b676a2c build: Fix Boost Process compatibility with mingw-w64 compiler (Hennadii Stepanov) Pull request description: On master (9c3751a0c940228c46461c4191f1a57153cb9037) the cross build for Win64 is broken if configured with `--enable-external-signer`: ``` ... CXX crypto/libbitcoin_crypto_base_a-chacha_poly_aead.o In file included from /home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include/boost/process/detail/windows/handles.hpp:11, from /home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include/boost/process/detail/used_handles.hpp:17, from /home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include/boost/process/detail/windows/async_in.hpp:20, from /home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include/boost/process/async.hpp:49, from /home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include/boost/process.hpp:23, from util/system.cpp:9: /home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include/boost/process/detail/windows/handle_workaround.hpp:208:51: error: expected ‘)’ before ‘*’ token 208 | typedef ::boost::winapi::NTSTATUS_ (__kernel_entry *nt_system_query_information_p )( | ~ ^~ | ) /home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include/boost/process/detail/windows/handle_workaround.hpp:223:51: error: expected ‘)’ before ‘*’ token 223 | typedef ::boost::winapi::NTSTATUS_ (__kernel_entry *nt_query_object_p )( | ~ ^~ | ) /home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include/boost/process/detail/windows/handle_workaround.hpp: In function ‘boost::winapi::NTSTATUS_ boost::process::detail::windows::workaround::nt_system_query_information(boost::process::detail::windows::workaround::SYSTEM_INFORMATION_CLASS_, void*, boost::winapi::ULONG_, boost::winapi::PULONG_)’: /home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include/boost/process/detail/windows/handle_workaround.hpp:239:12: error: ‘nt_system_query_information_p’ does not name a type; did you mean ‘nt_system_query_information’? 239 | static nt_system_query_information_p f = reinterpret_cast<nt_system_query_information_p>(::boost::winapi::get_proc_address(h, "NtQuerySystemInformation")); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | nt_system_query_information In file included from /home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include/boost/process/detail/windows/handles.hpp:11, from /home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include/boost/process/detail/used_handles.hpp:17, from /home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include/boost/process/detail/windows/async_in.hpp:20, from /home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include/boost/process/async.hpp:49, from /home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include/boost/process.hpp:23, from util/system.cpp:9: /home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include/boost/process/detail/windows/handle_workaround.hpp:241:14: error: ‘f’ was not declared in this scope 241 | return (*f)(SystemInformationClass, SystemInformation, SystemInformationLength, ReturnLength); | ^ /home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include/boost/process/detail/windows/handle_workaround.hpp: In function ‘boost::winapi::BOOL_ boost::process::detail::windows::workaround::nt_query_object(boost::winapi::HANDLE_, boost::process::detail::windows::workaround::OBJECT_INFORMATION_CLASS_, void*, boost::winapi::ULONG_, boost::winapi::PULONG_)’: /home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include/boost/process/detail/windows/handle_workaround.hpp:253:12: error: ‘nt_query_object_p’ does not name a type; did you mean ‘nt_query_object’? 253 | static nt_query_object_p f = reinterpret_cast<nt_query_object_p>(::boost::winapi::get_proc_address(h, "NtQueryObject")); | ^~~~~~~~~~~~~~~~~ | nt_query_object /home/hebasto/GitHub/bitcoin/depends/x86_64-w64-mingw32/include/boost/process/detail/windows/handle_workaround.hpp:255:14: error: ‘f’ was not declared in this scope 255 | return (*f)(Handle, ObjectInformationClass, ObjectInformation, ObjectInformationLength, ReturnLength); | ^ make[2]: *** [Makefile:9906: util/libbitcoin_util_a-system.o] Error 1 make[2]: *** Waiting for unfinished jobs.... CXX crypto/libbitcoin_crypto_base_a-chacha20.o make[2]: Leaving directory '/home/hebasto/GitHub/bitcoin/src' make[1]: *** [Makefile:16141: all-recursive] Error 1 make[1]: Leaving directory '/home/hebasto/GitHub/bitcoin/src' make: *** [Makefile:820: all-recursive] Error 1 ``` The upstream bug: https://github.com/boostorg/process/issues/96 Also see: https://stackoverflow.com/a/59338759 https://github.com/bitcoin/bitcoin/pull/22348#issuecomment-871061160: > [This commit](https://github.com/boostorg/process/commit/7fc41b2815822b632d524d5c17897abbdf0c4653), containing the `__kernel_entry` [SAL annotations](https://docs.microsoft.com/en-us/cpp/code-quality/using-sal-annotations-to-reduce-c-cpp-code-defects?view=msvc-160) was included in Boost Process as part of the `1.71.0` release, which broke support for compiling with mingw-w64 because it doesn't define the `__kernel_entry` SAL annotation (but it does define some others, i.e see [`sal.h`](https://github.com/mirror/mingw-w64/blob/master/mingw-w64-headers/include/sal.h)). > > A [commit was made](https://github.com/boostorg/process/pull/171/commits/d7a721ee0d6859847947f60911259e2c34b0d066) to remove the annotations, however, it hasn't made it into either of the two Boost releases that have happened since (1.75.0 & 1.76.0). Meaning that this is currently needed for all versions of Boost process from 1.71.0 onwards. ACKs for top commit: fanquake: ACK 67669ab425b52a2b6be3d2f3b3b7e3939b676a2c - thanks for updating this. Tree-SHA512: 5931ca1fb77ce38c042cf5a7556add024ea2386c208bf26c792a8ca4a771d97fac9802c32fa8aa2e3de1ad35f3362d8c066f0a83ee675859d226c602fd0bcf93
2021-07-01Merge bitcoin/bitcoin#22334: wallet: do not spam about non-existent spk managersfanquake
6084d2caed9b2c70c0f19898c33ecb141fe603c8 wallet: do not spam about non-existent spk managers (S3RK) Pull request description: Avoid spam in logs during `loadwallet`, `listdescriptors` and probably other commands as well. **`loadwallet` Before:** ``` 2021-06-24T06:31:45Z init message: Loading wallet… 2021-06-24T06:31:45Z [desc] Wallet File Version = 169900 2021-06-24T06:31:45Z [desc] Keys: 0 plaintext, 0 encrypted, 0 w/ metadata, 0 total. Unknown wallet records: 0 2021-06-24T06:31:45Z [desc] External scriptPubKey Manager for output type 0 does not exist 2021-06-24T06:31:45Z [desc] External scriptPubKey Manager for output type 1 does not exist 2021-06-24T06:31:45Z [desc] External scriptPubKey Manager for output type 2 does not exist 2021-06-24T06:31:45Z [desc] Internal scriptPubKey Manager for output type 0 does not exist 2021-06-24T06:31:45Z [desc] Internal scriptPubKey Manager for output type 1 does not exist 2021-06-24T06:31:45Z [desc] Internal scriptPubKey Manager for output type 2 does not exist 2021-06-24T06:31:45Z [desc] Wallet completed loading in 197ms 2021-06-24T06:31:45Z [desc] External scriptPubKey Manager for output type 0 does not exist 2021-06-24T06:31:45Z [desc] External scriptPubKey Manager for output type 1 does not exist 2021-06-24T06:31:45Z [desc] External scriptPubKey Manager for output type 2 does not exist 2021-06-24T06:31:45Z [desc] Internal scriptPubKey Manager for output type 0 does not exist 2021-06-24T06:31:45Z [desc] Internal scriptPubKey Manager for output type 1 does not exist 2021-06-24T06:31:45Z [desc] Internal scriptPubKey Manager for output type 2 does not exist 2021-06-24T06:31:45Z [desc] External scriptPubKey Manager for output type 0 does not exist 2021-06-24T06:31:45Z [desc] External scriptPubKey Manager for output type 1 does not exist 2021-06-24T06:31:45Z [desc] External scriptPubKey Manager for output type 2 does not exist 2021-06-24T06:31:45Z [desc] Internal scriptPubKey Manager for output type 0 does not exist 2021-06-24T06:31:45Z [desc] Internal scriptPubKey Manager for output type 1 does not exist 2021-06-24T06:31:45Z [desc] Internal scriptPubKey Manager for output type 2 does not exist 2021-06-24T06:31:45Z [desc] setKeyPool.size() = 0 2021-06-24T06:31:45Z [desc] mapWallet.size() = 0 2021-06-24T06:31:45Z [desc] m_address_book.size() = 0 2021-06-24T06:31:45Z [desc] External scriptPubKey Manager for output type 0 does not exist 2021-06-24T06:31:45Z [desc] External scriptPubKey Manager for output type 1 does not exist 2021-06-24T06:31:45Z [desc] External scriptPubKey Manager for output type 2 does not exist 2021-06-24T06:31:45Z [desc] Internal scriptPubKey Manager for output type 0 does not exist 2021-06-24T06:31:45Z [desc] Internal scriptPubKey Manager for output type 1 does not exist 2021-06-24T06:31:45Z [desc] Internal scriptPubKey Manager for output type 2 does not exist { "name": "desc", "warning": "" } ``` **After:** ``` 2021-06-24T06:26:58Z init message: Loading wallet… 2021-06-24T06:26:58Z [desc] Wallet File Version = 169900 2021-06-24T06:26:58Z [desc] Keys: 0 plaintext, 0 encrypted, 0 w/ metadata, 0 total. Unknown wallet records: 0 2021-06-24T06:26:58Z [desc] Wallet completed loading in 158ms 2021-06-24T06:26:58Z [desc] setKeyPool.size() = 0 2021-06-24T06:26:58Z [desc] mapWallet.size() = 0 2021-06-24T06:26:58Z [desc] m_address_book.size() = 0 { "name": "desc", "warning": "" } ``` ACKs for top commit: achow101: ACK 6084d2caed9b2c70c0f19898c33ecb141fe603c8 Tree-SHA512: c7d7345c3182a575db088fd731b7f6e428c42e4f3f2e10d5adb50bf74a2defe88768e65ebb91a08590be48cf766a5697e36fafa73f68ffe45e76a60600f072e2
2021-07-01Merge bitcoin/bitcoin#22379: wallet: erase spkmans rather than setting to ↵fanquake
nullptr b945a31afac63010fce782b8fbca96dee6b458c5 wallet: erase spkmans rather than setting to nullptr (Andrew Chow) Pull request description: In many places in ScriptPubKeyMan managing code, we assume that the ScriptPubKeyMan being retrieved actually exists and is not a nullptr. Thus removing a ScriptPubKeyMan requires erasing the object from the map rather than setting it to a nullptr. This fixes a segmentation fault that can be reached with `test/functional/wallet_descriptors.py --descriptors` ACKs for top commit: S3RK: ACK b945a31 Tree-SHA512: 344a4cf9b1c168428750c751dcd24c52032506f20c81977fe93c4b5307ea209de72bb62a9c5284820f225b03acdc9573fceb734833d29b82f49d5a799ddcaea7
2021-07-01build: Fix Boost Process compatibility with mingw-w64 compilerHennadii Stepanov
Boost 1.71 has a broken compatibility with mingw-w64 compiler due to the added __kernel_entry SAL annotations.
generated by cgit v1.2.3 (git 2.26.2) at 2024-07-19 20:36:44 +0000