💬 laanwj commented on pull request "benchmark: Improve SipHash_32b accuracy to avoid potential optimization issues":
(https://github.com/bitcoin/bitcoin/pull/30349#discussion_r1807789736)
a workaround may be to do `val.data()[0] = (val.data()[0] + 1) & 0xff;` to make the wrap-around explicit, the C++ compiler will almost certainly just optimize it away

💬 sipa commented on pull request "benchmark: Improve SipHash_32b accuracy to avoid potential optimization issues":
(https://github.com/bitcoin/bitcoin/pull/30349#discussion_r1807792537)
This is not UB, but ubsan is explicitly told to warn for certain error-prone but implementation-defined or well-defined behaviors.

If the effect is deliberate, it is possible to add the function name to the ubsan suppressions.

💬 l0rinc commented on pull request "benchmark: Improve SipHash_32b accuracy to avoid potential optimization issues":
(https://github.com/bitcoin/bitcoin/pull/30349#discussion_r1807792637)
Would you prefer I '& 0xFF' the current implementation?

💬 laanwj commented on pull request "benchmark: Improve SipHash_32b accuracy to avoid potential optimization issues":
(https://github.com/bitcoin/bitcoin/pull/30349#discussion_r1807812963)
dunno, i would prefer `&0xff` to adding a supression, it more explicitly defines what is expected

💬 EthanHeilman commented on pull request "CAT in Tapscript (BIP-347)":
(https://github.com/bitcoin/bitcoin/pull/29247#issuecomment-2425013338)
@achow101 Thanks, that's helpful for understanding the context. If consensus forms around OP_CAT should I or @0xBEEFCAF3 mark this as no longer as draft? I can't speak for @0xBEEFCAF3 but I would feel uncomfortable making that decision as it would open me up to criticism that I was attempting to manufacture consensus, even if there was consensus. What is the process here?

💬 achow101 commented on pull request "CAT in Tapscript (BIP-347)":
(https://github.com/bitcoin/bitcoin/pull/29247#issuecomment-2425036043)
> If consensus forms around OP_CAT should I or @0xBEEFCAF3 mark this as no longer as draft?

Yes. A maintainer may also do so as well.

📝 fanquake opened a pull request: "guix: Enable CET for `glibc` package"
(https://github.com/bitcoin/bitcoin/pull/31121)
Pulled from #30685. This doesn't need to wait for anything.

💬 laanwj commented on pull request "guix: Enable CET for `glibc` package":
(https://github.com/bitcoin/bitcoin/pull/31121#issuecomment-2425148227)
Concept ACK

📝 sdaftuar opened a pull request: "cluster mempool: Implement changeset interface for mempool"
(https://github.com/bitcoin/bitcoin/pull/31122)
It became clear while working on cluster mempool that it would be helpful for transaction validation if we could consider a full set of proposed changes to the mempool -- consisting of a set of transactions to add, and a set of transactions (ie conflicts) to simultaneously remove -- and perform calculations on what the mempool would look like if the proposed changes were to be applied. Two specific examples of where we'd like to do this:

- Determining if ancestor/descendant/TRUC limits would
...

💬 mzumsande commented on issue "Listen on random port by default (not 8333)":
(https://github.com/bitcoin/bitcoin/issues/31036#issuecomment-2425156768)
> Downsides:

Another downside would be that finding an initial batch of peers would take longer. GETADDR answers will include many addresses that are not reachable, whereas DNS seeders only resolve to addresses of nodes that the crawler could reach very recently. I would expect that there would be quite a noticeable effect.

💬 laanwj commented on pull request "Windows bitcoind stall debugging [NOMERGE, DRAFT]":
(https://github.com/bitcoin/bitcoin/pull/30956#issuecomment-2425157662)
> The call to RegQueryValueExA in RandAddSeedPerfmon:

good find !

i couldn't find anything wrong with that code; however i looked into the Microsoft documentation for this: https://learn.microsoft.com/en-us/windows/win32/perfctrs/using-the-registry-functions-to-consume-counter-data

apparently, querying HKEY_PERFORMANCE_DATA can potentially load all kinds of DLLs for performance counter data, depending on drivers installed on the system, as well as collects performance information for ev
...

💬 1440000bytes commented on issue "Listen on random port by default (not 8333)":
(https://github.com/bitcoin/bitcoin/issues/31036#issuecomment-2425175641)
> > Downsides:
>
> Another downside would be that finding an initial batch of peers would take longer. GETADDR answers will include many addresses that are not reachable, whereas DNS seeders only resolve to addresses of nodes that the crawler could reach very recently. I would expect that there would be quite a noticeable effect.

Let's fix DNS seeds: https://github.com/bitcoin/bitcoin/issues/30900

Or someone experienced and influential does a RFC which changes https://datatracker.ietf.o
...

💬 laanwj commented on pull request "rpc: net: follow-ups for #30062":
(https://github.com/bitcoin/bitcoin/pull/30183#discussion_r1807984414)
agree that that's clearer; it may not always be (due to ASmap being an approximation, as well as incomplete information) but the AS number is supposed ot be the end-point AS, not just one along the route

⚠️ Billgates098 opened an issue: "Flash bitcoin"
(https://github.com/bitcoin/bitcoin/issues/31123)

✅ achow101 closed an issue: "Flash bitcoin"
(https://github.com/bitcoin/bitcoin/issues/31123)

:lock: achow101 locked an issue: "."
(https://github.com/bitcoin/bitcoin/issues/31123)

👍 rkrux approved a pull request: "Remove mempoolfullrbf"
(https://github.com/bitcoin/bitcoin/pull/30592#pullrequestreview-2380966553)
tACK https://github.com/bitcoin/bitcoin/commit/f863f5a4f991ccfdf865d39c73269b196eeb4902

Make and functional tests are successful.

💬 rkrux commented on pull request "Remove mempoolfullrbf":
(https://github.com/bitcoin/bitcoin/pull/30592#discussion_r1808131075)
Nice to see these checks going away!

👍 rkrux approved a pull request: "Package validation: accept packages of size 1"
(https://github.com/bitcoin/bitcoin/pull/31096#pullrequestreview-2381095095)
tACK https://github.com/bitcoin/bitcoin/commit/72872c7073e99da0828e788b25520dcecf721c1b
Would be great to have the docs updated as well.

Make and functional tests successful.

In regtest I manually created a PSBT, processed it and submitted a single transaction package with successful response.

```
➜ bitcoin git:(2024-10-submitpackage-singleton) ✗ bitcoincli submitpackage "[\"020000000001018e61beaa1f85daba48a46e6bef4e58d12f32768d347185cb077c988cc5af976b0000000000fdffffff02e60f10240100
...

💬 rkrux commented on pull request "Package validation: accept packages of size 1":
(https://github.com/bitcoin/bitcoin/pull/31096#discussion_r1808203711)
Worth updating RPC doc as well here? Informing that only child is also allowed.

https://github.com/bitcoin/bitcoin/blob/master/src/rpc/mempool.cpp#L926