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

💬 sipa commented on pull request "Wallet: don't underestimate the fees when spending a Taproot output":
(https://github.com/bitcoin/bitcoin/pull/26573#discussion_r1439722015)
Nit: leave -> leaf

💬 petertodd commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1874428462)
> Responding to https://petertodd.org/2023/v3-transactions-review
>
> In general, I agree that RBF is a great fee-bumping mechanism. The entire point of v3 and EA is to make RBF more useful and less prone to pinning, and to enable us to use it in conjunction with CPFP while eliminating some of the inefficiency.
>
> We seem to have entirely different perspectives about what RBF's limitations are today. Pointing out limitations in RBF is not intended as a personal attack. There is no intenti
...

💬 instagibbs commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1874445551)
moving to delving thread as we're essentially debating an LN spec at this point: https://delvingbitcoin.org/t/v3-transaction-policy-for-anti-pinning/340/3

💬 petertodd commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1874451089)
> moving to delving thread as we're essentially debating an LN spec at this point: https://delvingbitcoin.org/t/v3-transaction-policy-for-anti-pinning/340/3

We are not debating the LN spec.

The LN spec doesn't use V3 transactions, and as of anchor channels, is not vulnerable to the problems V3 transactions aims to solve. As I mentioned in my post, package relay would be helpful to anchor channels. But of course, package relay does not depend on V3.

This discussion is not about general B
...

💬 mzumsande commented on pull request "Nuke adjusted time (attempt 2)":
(https://github.com/bitcoin/bitcoin/pull/28956#discussion_r1439748605)
I think the the addition should be done before the division to handle rounding effects better, like it's done in `timedata`. If the two relevant offsets are, for example, 3 and 5, the median with this code would be 3.

💬 instagibbs commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1874472046)
As noted in delving, pinning is not solved for anchor channels: If an adversary splits the view of which commitment transaction is broadcasted, the remote copy can become the pin since the defender is unable to propagate their spend of the remote commit tx anchor.

💬 stickies-v commented on pull request "Nuke adjusted time (attempt 2)":
(https://github.com/bitcoin/bitcoin/pull/28956#discussion_r1439769121)
The current approach addresses overflow concerns as per https://github.com/bitcoin/bitcoin/pull/28956#discussion_r1411821098

💬 instagibbs commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1874485977)
> This discussion is not about general Bitcoin protocol design. The question is if V3 transactions actually solves a real problem in a real protocol, thus making it a worthwhile addition to Bitcoin Core.

V3 is useful for any transactions where you don't want to be RBF-pinned for sending to arbitrary addresses. For example in splicing, rather than requiring each address being sent to including a `1 OP_CSV` clause over each spending condition, it can now be arbitrary scriptPubKeys. More general
...

💬 mzumsande commented on pull request "Nuke adjusted time (attempt 2)":
(https://github.com/bitcoin/bitcoin/pull/28956#discussion_r1439781598)
ok, I see. Still, having a function that returns 3 as the medium of {3,5} and 5 as the medium of {4,6} seems inconsistent, couldn't we explicitly check and handle overflows instead?

💬 darosior commented on pull request "v3 transaction policy for anti-pinning":
(https://github.com/bitcoin/bitcoin/pull/28948#issuecomment-1874508653)
> You've misunderstood how Lightning works. While simplified explanations often talk about [...]

I see how a superficial understanding of Lightning and pinning issues could lead you to think that. However your hot fix to your proposal does not patch all its flaws.

> In the context of RBF using channels — while there may be special circumstances requiring a different allocation — the most obvious way to allocate fees is to take the fees from the balance on each respective side. So if Alice
...

💬 darosior commented on pull request "PoC: fuzz chainstate and block managers":
(https://github.com/bitcoin/bitcoin/pull/29158#discussion_r1439796296)
I haven't. Can we use a ramdisk at oss-fuzz?

💬 hebasto commented on pull request "build: Bump clang minimum supported version to 15":
(https://github.com/bitcoin/bitcoin/pull/29165#discussion_r1439881726)
> Looks like the macOS CI now fails for unrelated reasons. If someone created a separate pull request to bump xcode in the macOS CI, that'd be great.

The underlying issue is that Apple Clang 15 does not support `-Xclang -internal-isystem` anymore. Therefore, supporting for the `--enable-suppress-external-warnings` option on `x86_64` macOS becomes a non-trivial task.

💬 achow101 commented on pull request "wallet: Implement independent BDB parser":
(https://github.com/bitcoin/bitcoin/pull/26606#discussion_r1439887042)
Indeed, fixed.

💬 achow101 commented on pull request "wallet: Fix migration of wallets with txs that have both spendable and watchonly outputs":
(https://github.com/bitcoin/bitcoin/pull/28868#discussion_r1439890323)
Done as suggested