💬 glozow commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1424169715)
Taken

💬 glozow commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1424176890)
I don't think we should do that; we'd want to look at the impact on all related transaction's descendant scores. This transaction's modified fee might be negative, but it could have high-feerate descendants.

💬 Sjors commented on pull request "Stratum v2 Template Provider (take 2)":
(https://github.com/bitcoin/bitcoin/pull/28983#issuecomment-1852266713)
Pleased clang-tidy. Fixed memory issue by disabling a broken test, added `Assume` to `noise.cpp` to check the message size. Added a (possibly overkill) destructor to `Sv2Template`.

💬 achow101 commented on pull request "wallet: skip BnB when SFFO is enabled":
(https://github.com/bitcoin/bitcoin/pull/28994#issuecomment-1852286863)
ACK 576bee88fd36e207b7288077626947a1fce0fc33

💬 fanquake commented on pull request "depends: fix libmultiprocess build on aarch64":
(https://github.com/bitcoin/bitcoin/pull/28846#issuecomment-1852300861)
Guix build (aarch64):
```bash
1415d765a10d1686e0a37f550aaf83fadad17d2d94c17688ae298ececcca17e2 guix-build-bde8d63b1763/output/aarch64-linux-gnu/SHA256SUMS.part
7e6f42f033469d23300b93c3541babae3d60a7e21615ea3ba08f243131339e5c guix-build-bde8d63b1763/output/aarch64-linux-gnu/bitcoin-bde8d63b1763-aarch64-linux-gnu-debug.tar.gz
3eba206402f4a6f7bcbe73c53f1b95f01944e35b7c3a94cf0cb1daf2db08afc8 guix-build-bde8d63b1763/output/aarch64-linux-gnu/bitcoin-bde8d63b1763-aarch64-linux-gnu.tar.gz
571ba0
...

👍 TheCharlatan approved a pull request: "refactor: Print verbose serialize compiler error messages"
(https://github.com/bitcoin/bitcoin/pull/29056#pullrequestreview-1777851574)
Re-ACK fa45567e030272d34845e6b563a6b626b9eda739

🚀 achow101 merged a pull request: "wallet: skip BnB when SFFO is enabled"
(https://github.com/bitcoin/bitcoin/pull/28994)

💬 glozow commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1424215142)
I've nested this part of the function inside `!ancestors.empty()` to make this clearer (and safer imo).

💬 glozow commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#discussion_r1424216465)
Pulled into a helper function and reused :+1:

💬 glozow commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1852315761)
Fixed the fuzzer crashes in https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1828351782 and https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1835850051 (thanks)

💬 fanquake commented on pull request "wallet: skip BnB when SFFO is enabled":
(https://github.com/bitcoin/bitcoin/pull/28994#issuecomment-1852336494)
Added this to #29011 for backporting to 26.x.

💬 mzumsande commented on pull request "net, cli: use v2transport for manual/addrfetch connections, add to -netinfo":
(https://github.com/bitcoin/bitcoin/pull/29058#discussion_r1424240319)
thanks, removed the comment.

💬 mzumsande commented on pull request "net, cli: use v2transport for manual/addrfetch connections, add to -netinfo":
(https://github.com/bitcoin/bitcoin/pull/29058#issuecomment-1852356884)
> Playing devil's advocate: could there be any noticeable drawbacks of always trying with v2 first? I'm thinking of destination nodes behind firewalls with deep packet inspection which block ips from further connections if they don't follow the protocol (i.e. for bitcoin v1 connections, initiating with a version message). If that's the case, the user would only have the option to disable v2transport in general, or use the `addnode` RPC instead. Not sure how realistic that "i want to connect via
...

💬 theuni commented on pull request "Replace non-standard CLZ builtins with c++20's bit_width":
(https://github.com/bitcoin/bitcoin/pull/29057#issuecomment-1852375970)
Thanks @theStack and @hebasto for the quick review.

@fanquake sounds good, will push a commit to do the switch once we see some benchmarks.

⚠️ hebasto opened an issue: "build: GCC 10.5 fails to compile `test_bitcoin` using Boost.Test 1.71"
(https://github.com/bitcoin/bitcoin/issues/29063)
On fresh Ubuntu 20.04, with dependencies installed via `apt`:
```
$ ./configure CC=gcc-10 CXX=g++-10
$ make -C src test/test_bitcoin
make: Entering directory '/bitcoin/src'
CXX test/test_bitcoin-main.o
In file included from /usr/include/boost/test/included/unit_test.hpp:29,
from test/main.cpp:10:
/usr/include/boost/test/impl/test_tools.ipp: In member function 'void boost::test_tools::tt_detail::print_log_value<const wchar_t*>::operator()(std::ostream&, const wchar
...

💬 hebasto commented on issue "build: GCC 10.5 fails to compile `test_bitcoin` using Boost.Test 1.71":
(https://github.com/bitcoin/bitcoin/issues/29063#issuecomment-1852404642)
Quick googling shows:
- upstream bug -- https://github.com/boostorg/test/issues/249
- upstream fix -- https://github.com/boostorg/test/pull/252

Should we update the minimum support Boost version then?

📝 achow101 converted_to_draft a pull request: "wallet: reenable sethdseed for descriptor wallets"
(https://github.com/bitcoin/bitcoin/pull/29054)
Enable `sethdseed` for descriptor wallets. To be able to use `createwalletdescriptor` with the other address types, we need a way to change the wallet extended key, and so `sethdseed` has been updated and enabled for descriptor wallets. As with legacy wallets, when called without parameters, it will generate a new random master key for the wallet. It can also take a xprv and set that as the master key. It still takes a BIP 32 seed as WIF or as hex as we do for legacy wallets. The seed will be tr
...

💬 maflcko commented on issue "build: GCC 10.5 fails to compile `test_bitcoin` using Boost.Test 1.71":
(https://github.com/bitcoin/bitcoin/issues/29063#issuecomment-1852417369)
> Should we update the minimum support Boost version then?

Sounds good. I don't see an alternative.

💬 hebasto commented on issue "build: GCC 10.5 fails to compile `test_bitcoin` using Boost.Test 1.71":
(https://github.com/bitcoin/bitcoin/issues/29063#issuecomment-1852420355)
> > Should we update the minimum support Boost version then?
>
> Sounds good. I don't see an alternative.

Going to do more thorough tests before submitting a PR.

💬 1ma commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1852422627)
> > The original Satoshi client didn't allow embedding data onchain, this has always been an exploit.
>
> Bitcoin was released with no standardness rules at all. You absolutely could embed data onchain. You could even publish arbitrary data to the UTXO set easily.

That was poor wording, but was precisely my point.

Satoshi introduced OP_RETURN as a mechanism to prove that some sats were provably unspendable. Then it turned out that the Bitcoin interpreter was too lax and OP_RETURN could
...