📝 sipa opened a pull request: "[DONTMERGE] See if just constexpr->consteval for _mst works"
(https://github.com/bitcoin/bitcoin/pull/29167)

💬 sipa commented on pull request "miniscript: make operator""_mst consteval":
(https://github.com/bitcoin/bitcoin/pull/28657#issuecomment-1874247244)
@fanquake See #29167

💬 achow101 commented on pull request "fuzz: set `m_fallback_fee` and `m_fee_mode` in `wallet_fees` target":
(https://github.com/bitcoin/bitcoin/pull/29076#issuecomment-1874248910)
ACK e03d6f7ed534f423f58236866f8e83beee1871e1

💬 dergoegge commented on pull request "Nuke adjusted time (attempt 2)":
(https://github.com/bitcoin/bitcoin/pull/28956#issuecomment-1874258028)
Only rebased for now

🚀 achow101 merged a pull request: "fuzz: set `m_fallback_fee` and `m_fee_mode` in `wallet_fees` target"
(https://github.com/bitcoin/bitcoin/pull/29076)

✅ sipa closed a pull request: "[DONTMERGE] See if just constexpr->consteval for _mst works"
(https://github.com/bitcoin/bitcoin/pull/29167)

💬 LarryRuane commented on pull request "bitcoin-cli help detail to show full help for all RPCs":
(https://github.com/bitcoin/bitcoin/pull/29163#issuecomment-1874278059)
Force pushed to add release note (not sure if this is important enough to have a release note for, but just in case), and also updated the `help help` text to document the `detail` argument:
```
$ bitcoin-cli help help
help ( "command" )

List all commands, or get help for a specified command.

Arguments:
1. command (string, optional, default=all commands) The command to get help on, or "detail" for full help on all commands

Result:
"str" (string) The help text
```

💬 glozow commented on pull request "Change Luke Dashjr seed to dashjr-list-of-p2p-nodes-maybe-malware.us":
(https://github.com/bitcoin/bitcoin/pull/29145#issuecomment-1874280212)
> I've chosen a domain name that is explicitly verbose about its purpose

Er, how is "maybe malware" the purpose of the seeder? It seems like this would just confuse/alarm users, maybe choose something else instead. I don't think adding a log filter makes sense either.

💬 stratospher commented on pull request "test/BIP324: functional tests for v2 P2P encryption":
(https://github.com/bitcoin/bitcoin/pull/24748#discussion_r1439634994)
nice! done.

💬 stratospher commented on pull request "test/BIP324: functional tests for v2 P2P encryption":
(https://github.com/bitcoin/bitcoin/pull/24748#discussion_r1439635162)
added a [description](https://github.com/bitcoin/bitcoin/blob/42203f84bba7e4ba206c9f951c3f4b6922a44f81/test/functional/test_framework/v2_p2p.py#L260-L265) and also an [extra assert](https://github.com/bitcoin/bitcoin/blob/42203f84bba7e4ba206c9f951c3f4b6922a44f81/test/functional/test_framework/p2p.py#L326) to make sure we don't receive b"" as an application layer message.

💬 dergoegge commented on pull request "PoC: fuzz chainstate and block managers":
(https://github.com/bitcoin/bitcoin/pull/29158#issuecomment-1874318288)
Thanks for working on this!

One alternative that I have considered before (for chainstate fuzzing) is to abstract and further modularize `BlockManager`, which would allow us to have an `InMemoryBlockManager` for tests (especially useful for fuzzing but also nice in unit tests).

This would require a bunch of work:
* Breaking up the friendship between `BlockManager`, `Chainstate` & `ChainstateManager`
* Abstracting `BlockManager`'s interface away from being file based
* Hiding access to
...

💬 brunoerg commented on pull request "p2p: Allow whitelisting outgoing connections":
(https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1439666464)
Same reason: https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1437020771

💬 petertodd commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1874336752)
@darosior

> > The largest lightning channels out there are about 5BTC. Even if you were willing to bump fees, all the way to spending the entire 5BTC towards fees, you'd need just 68 different fee variants to go all the way from 1sat/vbyte to spending the full 5BTC on fees, with a 25% increase for each each fee variant.
>
> So you'd potentially hand to your supposedly untrusted channel partner a signature for a transaction burning your whole 4.95BTC balance to fees? This trivially opens a
...

💬 brunoerg commented on pull request "p2p: Allow whitelisting outgoing connections":
(https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1439677728)
I'll leave it as is for now.

💬 sipa commented on pull request "fuzz: rule-out too deep derivation paths in descriptor parsing targets":
(https://github.com/bitcoin/bitcoin/pull/28832#issuecomment-1874377138)
utACK a44808fb437864878c2d9696b8a96193091446ee

💬 brunoerg commented on pull request "p2p: Allow whitelisting outgoing connections":
(https://github.com/bitcoin/bitcoin/pull/27114#issuecomment-1874398255)
Force-pushed addressing https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1411359535

💬 petertodd commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1874400590)
> > Now, as for the choosing a feerate in advance problem, I explained fully in my article, showing how it's quite easy to pre-sign every conceivable feerate because there just aren't that many of them. In fact, you could easily pre-sign feerates all the way to making the channel uneconomical to close, because you've spent every cent towards fees. This is not a problem.
>
> That proposal ignores important drawbacks on the lightning side. I'm actually quite surprised that you don't even mentio
...

🤔 sipa reviewed a pull request: "Wallet: don't underestimate the fees when spending a Taproot output"
(https://github.com/bitcoin/bitcoin/pull/26573#pullrequestreview-1800853604)
Concept ACK

💬 sipa commented on pull request "Wallet: don't underestimate the fees when spending a Taproot output":
(https://github.com/bitcoin/bitcoin/pull/26573#discussion_r1439716924)
Same here.

💬 sipa commented on pull request "Wallet: don't underestimate the fees when spending a Taproot output":
(https://github.com/bitcoin/bitcoin/pull/26573#discussion_r1439721581)
Seems better to use `GetSizeOfCompactSize` here.