💬 rkrux commented on pull request "rpc: Add support to populate PSBT input utxos via rpc":
(https://github.com/bitcoin/bitcoin/pull/30886#discussion_r1807751783)
Outside the scope of this PR: While testing I realised that the output does not display the reason why it failed, would it be a good idea to display the error as well?
```
➜ src git:(2024-09-updateutxo_psbt) ✗ bitcoincli walletprocesspsbt cHNidP8BAFICAAAAAfDLyQnCSPG31wZz1rHABK8QVnQLIubUuakp3tA1b688AAAAAAD9////AQBlzR0AAAAAFgAU0NrK8DrQVPpN/ZzmgNtNu55HmNgAAAAAAAAA
{
"psbt": "cHNidP8BAFICAAAAAfDLyQnCSPG31wZz1rHABK8QVnQLIubUuakp3tA1b688AAAAAAD9////AQBlzR0AAAAAFgAU0NrK8DrQVPpN/ZzmgNtNu55HmNgAAA
...

💬 rkrux commented on pull request "rpc: Add support to populate PSBT input utxos via rpc":
(https://github.com/bitcoin/bitcoin/pull/30886#discussion_r1807750224)
```suggestion
{"", RPCArg::Type::STR, RPCArg::Optional::OMITTED, "A serialized previous transaction in hex"},
```
Assuming it's supposed to say `previous`.

💬 rkrux commented on pull request "rpc: Add support to populate PSBT input utxos via rpc":
(https://github.com/bitcoin/bitcoin/pull/30886#discussion_r1807751232)
Does it make sense to deduplicate this code piece by accepting `prev_txs, request.params[i]` as inputs to a function?

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