Sync with the main repo #9

- remove unneeded strprintf - consistent punctuation (no EOL periods) - sort helps by order they are printed (alphabetical order)

Support for riscv64 in glibc landed in 2.27 so it's unavoidable that we use 2.27. Running a Bitcoin build with toolchains based on 2.24 for platforms other than riscv64 seem to produce binaries which do not have 2.17 symbols. So use 2.24 since it's more recent and maintained by Debian Stretch.

Our 'bitcoin-linux-g++' definition better integrates with our depends system than the stock linux-g++-64 definition. This fixes a bug whereby Guix builds on x86_64 for x86_64 did not produce a QMinimalIntegrationPlugin and led to bitcoin-qt not being built.

Moving the implementation out of the header will reduce compile time

* 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

The WitnessUnknown operators == and < are already called indirectly by the corresponding CTxDestination operators.

No need to split it over several targets

Now that our Guix builds are performed on glibc 2.24 and 2.27 (RISCV), we no-longer need to pass the --enable-glibc-back-compat option. Replace it with --disable-threadlocal, to prevent the usage of symbols from glibc 2.18. None of the binaries produced required symbols later than 2.17, and 2.27 (RISCV).

Co-authored-by: Carl Dong <contact@carldong.me>

Reduce the condition `IsRFC4193() && !IsTor()` to `IsRFC4193()`. We know that if `IsRFC4193()` is `true` then, for sure, the address is not Tor, so `!IsTor()` is also `true`.

If an address classifies as `IsRFC4193()`, then it cannot be `NET_ONION` (Tor v3), thus remove that condition from the assert.

The Tor v2 addresses, left over from when Tor v2 was supported will be unserialized as a dummy, invalid `::` (all zeros) IPv6 address. Remove them so that they do not take up space in addrman.

This reject reason is triggered for non-coinbase transactions with a coinbase-like outpoint, i.e. hash=0, n=0xffffffff. Note that the invalid tx templates are currently used in the functional tests feature_block.py and p2p_invalid_tx.py.

When using mypy ignore directives, the error code needs to be specified. Somehow mypy doesn't print it by default...

The CI environment is a moving target, and these tests are somewhat fragile, so for now, disable them.

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.).

We use these flags in our test-security-check make target, but they are only available because debian patches them in. We can patch them in for our Guix builds so that we can check the sanity of our security/symbol checking suite before running them.

Also fix test-security-check.py to account for new PE PIE failure indication.

Now that our release binaries are build in a glibc 2.24 and 2.27 environment, we can't use a symbol from glibc 2.28 to test our checks. Replace renameat2() with nextup(), which was introduced in 2.24. Note that this also means re-disabling the test for RISC-V, however RISC-V is built in a glibc 2.27 environment, and our minimum required glibc for that binary is 2.27.

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); ^

Changes behavior.

Co-authored-by: Antoine Riard <ariard@student.42.fr> Co-authored-by: Antoine Riard <antoine.riard@gmail.com>

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.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Sync with the main repo #9

Sync with the main repo #9

Commits on Jul 12, 2021