💬 t-bast commented on pull request "Ephemeral Dust":
(https://github.com/bitcoin/bitcoin/pull/30239#issuecomment-2239497457)
> Forcing them to be put towards the keyless ephemeral output potentially creates incentive problems around stealing that output.

Not really, because it will always be the miner that will steal it (since they can replace any spend by a spend to themselves). As was detailed in the delving post you're referencing, putting HTLC values in the keyless ephemeral output ensures that it's spent and doesn't pollute the utxo set, while putting the fees directly to the commitment transaction doesn't in
...

💬 sipa commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1684577252)
Not a typo. There can be multiple distinct optimal linearizations; we just check for optimality, not that it is actually identical to the exhaustive solutions.

💬 petertodd commented on pull request "Ephemeral Dust":
(https://github.com/bitcoin/bitcoin/pull/30239#issuecomment-2239528767)
Stealing an ephemeral anchor output can only be done in certain conditions, at specific ranges of values. It is not always profitable due to overheads, and you can reduce those overheads by doing complex things.

The game theory is much simpler if the dust HTLC funds go directly to fees.

On July 19, 2024 5:50:49 PM GMT+02:00, Bastien Teinturier ***@***.***> wrote:
>> Forcing them to be put towards the keyless ephemeral output potentially creates incentive problems around stealing that output.

...

💬 petertodd commented on pull request "policy: Add PayToAnchor(P2A), `OP_TRUE <0x4e73>` as a standard output script for spending":
(https://github.com/bitcoin/bitcoin/pull/30352#issuecomment-2239532688)
I responded to all those points, as you can see in the thread. Anyway, it's clearly an on topic FYI as it impacts how useful this feature actually is. But no need to discuss it further than the FYI link.

On July 19, 2024 5:43:53 PM GMT+02:00, Bastien Teinturier ***@***.***> wrote:
>> FYI anchor channels having two anchor outputs is actually a design oversight. Only one anchor output is needed in almost all cases: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December/004246.htm
...

💬 brunoerg commented on pull request "fuzz: Limit parse_univalue input length":
(https://github.com/bitcoin/bitcoin/pull/30473#discussion_r1684608209)
Nice

👍 brunoerg approved a pull request: "fuzz: Limit parse_univalue input length"
(https://github.com/bitcoin/bitcoin/pull/30473#pullrequestreview-2188623731)
utACK fa80b16b20dffcb85b80f75fee64ed333f2062f9

📝 fanquake converted_to_draft a pull request: "guix: bump time-machine to 1aa8dfaeec3c6e4e587aadf7440246f7c5c04b9f"
(https://github.com/bitcoin/bitcoin/pull/30452)
Needed for https://github.com/bitcoin/bitcoin/issues/30210. This doesn't switch runtimes, because upstream is
still configured to use the old runtime. See:
https://git.savannah.gnu.org/cgit/guix.git/commit/?id=17188be0f723e00377b21b767f5447d7938a116e.

git-mimimal 2.45.1 -> 2.45.2
Kernel Headers 6.1.92 -> 6.1.99
LLVM 18.1.6 -> 18.1.8
mingw-w64 11.0.1 -> 12.0.0
NSIS 3.09 -> 3.10
patch 2.7.6 -> 2.7.6-0.f144b35

💬 brunoerg commented on issue "scriptpubkeyman fuzz target TopUp is slow":
(https://github.com/bitcoin/bitcoin/issues/30476#issuecomment-2239617385)
Instead of calling `TopUp` every time we call `AddDescriptorKey`, maybe it could be done just one time per iteration. I can see it.

🤔 glozow reviewed a pull request: "cluster mempool: cluster linearization algorithm"
(https://github.com/bitcoin/bitcoin/pull/30126#pullrequestreview-2182496612)
code review ACK, planning to spend more time reviewing the tests

💬 glozow commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1684495081)
```suggestion
* In this case, the possibilities are, in order:
```

💬 glozow commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1684658967)
nit: maybe something like "explore and add a work item if there are any transactions left to split on" ?

💬 glozow commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1684491008)
a53b7eb82c3: nitty nit
```suggestion
* The serialization format outputs information about transactions in a topological order (parents
```

🤔 BrandonOdiwuor reviewed a pull request: "test: Add arguments for creating a slimmer TestingSetup"
(https://github.com/bitcoin/bitcoin/pull/30399#pullrequestreview-2188743300)
Concept ACK

💬 hebasto commented on pull request "depends: build zeromq with CMake":
(https://github.com/bitcoin/bitcoin/pull/29723#issuecomment-2239718965)
My Guix build:
```
x86_64
c7aa6bd428ba4ea1c925dafe4df3505ad92e84a196b17c8cb7965d7db231e6a0 guix-build-0388ad0d65b6/output/aarch64-linux-gnu/SHA256SUMS.part
944e734a719886ec26aff12a80be67d28f2c4b7781a341894d3e2ca8477e3497 guix-build-0388ad0d65b6/output/aarch64-linux-gnu/bitcoin-0388ad0d65b6-aarch64-linux-gnu-debug.tar.gz
087ac7a0c1d87a95adacb9fa138aced37a172d4d5199fc75c64831d9f6211972 guix-build-0388ad0d65b6/output/aarch64-linux-gnu/bitcoin-0388ad0d65b6-aarch64-linux-gnu.tar.gz
3b0105522
...

💬 instagibbs commented on pull request "Ephemeral Dust":
(https://github.com/bitcoin/bitcoin/pull/30239#issuecomment-2239730901)
Ok, the rework ended up being quite easy.

Pushed an update that generalizes to non-TRUC transactions, but as noted earlier, individual transactions have to meet minrelay for now unless they are TRUC, see/divert discussion here for that specific point: https://github.com/bitcoin/bitcoin/pull/26933 . If this restriction goes away, it will be usable(see tests I added with v2 transactions at the bottom where I checked it). Note that we are still constrained to 1P1C relay until we get general pack
...

💬 sipa commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1684698131)
Done.

💬 sipa commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1684698616)
We don't invoke ExhaustiveCandidateFinder for larger clusters because it just gets too computationally expensive to do so. I've added a comment to clarify this.

💬 sipa commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1684698702)
Done.

💬 sipa commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1684698780)
Fixed.

💬 sipa commented on pull request "cluster mempool: cluster linearization algorithm":
(https://github.com/bitcoin/bitcoin/pull/30126#discussion_r1684698872)
Fixed.