💬 instagibbs commented on pull request "Parallel compact block downloads, take 3":
(https://github.com/bitcoin/bitcoin/pull/27626#issuecomment-1546173220)
> This PR makes that 3.

Makes it 3 parallel block downloads, first can be of any kind, the 2nd and 3rd must be compact block announcements from high badwidth peers.

> I am confused by the "it will not help" phrase

This PR does not take advantage of low-bandwidth compact block peers message patterns, in other words.

💬 theuni commented on pull request "build: Fix shared lib linking for darwin with lld":
(https://github.com/bitcoin/bitcoin/pull/27628#issuecomment-1546173685)
Updated the original commit to quote `"yes"` to match the others.

Also fixed up the comments as @hebasto suggested.

💬 Sjors commented on issue "Parallel compact block download":
(https://github.com/bitcoin/bitcoin/issues/25258#issuecomment-1546184277)
If we wait a little bit before the second attempt, and if we track which peers have since announced the header, we could pick from a larger set. Randomly and maybe with a preference for outbound. We can rely on high bandwidth mode compact block peer(s) for speed, but then for reliability use a bit more patience. Maybe we could even do one attempt at a getting compact block and then a few seconds later ask for a regular block.

💬 sr-gi commented on pull request "net processing: avoid serving non-announced txs as a result of a MEMPOOL message":
(https://github.com/bitcoin/bitcoin/pull/27602#discussion_r1192731365)
I think those are rate limited so they don't overflow in less than two minutes, after which they are not relevant anymore.

For outbound connections, INVs are sent out every 2s (`OUTBOUND_INV_BROADCAST_INTERVAL`), while for inbound, they are sent every 5s (`OUTBOUND_INV_BROADCAST_INTERVAL`). In a two-minute timespan, that results in 2100 and 840 INVs at max¹, respectively. The `m_recently_announced_invs` rolling filter is only checked in `FindTxForGetData` after making sure the trac
...

💬 instagibbs commented on pull request "rpc: allow submitpackage to be called outside of regtest":
(https://github.com/bitcoin/bitcoin/pull/27609#issuecomment-1546196121)
re:topology restrictions beyond generalized ancestor packages, is the thought to restrict the typologies at a higher level, vs AcceptMultipleTransactions? Noticed this branch is restricting at RPC layer. I presume it would also require tree structure in https://github.com/bitcoin/bitcoin/pull/26711 ?

💬 jamesob commented on pull request "rpc: allow submitpackage to be called outside of regtest":
(https://github.com/bitcoin/bitcoin/pull/27609#issuecomment-1546204526)
> I became convinced that this is unsafe

I'm curious, what's the worst-case failure here? Is it that a participating miner's mempool gets screwed up? or that replacement may not happen properly? or that pinning becomes an issue?

In other words, I'm wondering if the failure is tolerable in the sense that the damage would be contained to the user trying to submit a dumb (or "not topoolgically sensical") package?

I was enthusiastic about a small change that would open up this functionality
...

💬 sr-gi commented on pull request "net processing: avoid serving non-announced txs as a result of a MEMPOOL message":
(https://github.com/bitcoin/bitcoin/pull/27602#issuecomment-1546218018)
Addresses @willcl-ark comments and fixes tests to make sure the `MEMPOOL` message and the second `GETDATA` message are not processed within the same second, as per @vasild comment.

💬 glozow commented on pull request "rpc: allow submitpackage to be called outside of regtest":
(https://github.com/bitcoin/bitcoin/pull/27609#issuecomment-1546245665)
> re:topology restrictions beyond generalized ancestor packages, is the thought to restrict the typologies at a higher level, vs AcceptMultipleTransactions? Noticed this branch is restricting at RPC layer. I presume it would also require tree structure in https://github.com/bitcoin/bitcoin/pull/26711 ?

No tree-only in #26711, the hope is to handle ancestor packages so we can do ancestor package relay. We can do it 💪
This restriction is RPC-level because it's basically a "batched commitment
...

💬 ryanofsky commented on pull request "kernel: Remove interface_ui, util/system from kernel library":
(https://github.com/bitcoin/bitcoin/pull/27636#discussion_r1192780239)
Yes, I think that's preferable. Just pass `const ChainstateNotifications&` everywhere and don't have a lot of different awkward notifications

🤔 real-or-random reviewed a pull request: "Introduce field element and group element classes to test_framework/key.py"
(https://github.com/bitcoin/bitcoin/pull/26222#pullrequestreview-1425172202)
Concept ACK on making the code simple

Since this is something like a reference implementation, I think `GE` should get the infinity handling right. If you agree that's a good idea, then it's perhaps better to have a more explicit representation for infinity than none.

👍 hebasto approved a pull request: "build: Fix shared lib linking for darwin with lld"
(https://github.com/bitcoin/bitcoin/pull/27628#pullrequestreview-1425178142)
re-ACK 67aacc73ea427f89f005ae17d5fd1572409e649e

Guix builds:
```
8a8fb0b28786ca39ce748520df30008933aefd6fa10538207aa93991c7ab7c41 guix-build-67aacc73ea42/output/aarch64-linux-gnu/SHA256SUMS.part
a3f07b89ce463bfdaa91aa8240dfdbc62ffdeb734155739aa72928e205147ccf guix-build-67aacc73ea42/output/aarch64-linux-gnu/bitcoin-67aacc73ea42-aarch64-linux-gnu-debug.tar.gz
27d111b4924c99b798bc821aa475994d280a6d1a76d4c62c12cde10b7d0e61df guix-build-67aacc73ea42/output/aarch64-linux-gnu/bitcoin-67aacc7
...

✅ st3b1t closed a pull request: "rpc: append rpcauth.py hash in config and show pass"
(https://github.com/bitcoin/bitcoin/pull/27588)

📝 brunoerg opened a pull request: "fuzz: wallet, add target for `fees`"
(https://github.com/bitcoin/bitcoin/pull/27647)
This PR adds fuzz coverage for `wallet/fees`. Some functions may use or not (non default) values from `wallet`, `CCoinControl` or `FeeCalculation`. So the logic is to make the test sometimes fill up some attributes and others no.

⚠️ Aminkavoos opened an issue: "I can take the lock on this issue?"
(https://github.com/bitcoin/bitcoin/issues/27648)
I can take the lock on this issue?

_Originally posted by @vincenzopalazzo in https://github.com/bitcoin/bitcoin/issues/23119#issuecomment-929591085_

✅ pinheadmz closed an issue: "I can take the lock on this issue?"
(https://github.com/bitcoin/bitcoin/issues/27648)

🤔 mzumsande reviewed a pull request: "assumeutxo (2)"
(https://github.com/bitcoin/bitcoin/pull/27596#pullrequestreview-1425210799)
I started testing this by creating / loading a snapshot on signet at height 100016. I haven't really looked at the code yet and also didn't read the provided docs so that I could do things by trial and error, and hopefully get to the desired result anyway but have a better chance to encounter some edge cases / bugs along the way.

Things worked really well! Just some observations / minor issues:
- Didn't encounter any problems with indexes, pruning, `-reindex` or `reindex-chainstate`
- In on
...

💬 ajtowns commented on pull request "Relay own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/27509#discussion_r1192851862)
Also, if you send the `INV` first and wait for a request to send the actual tx, you might be a little more confident that the peer you connected to is really relaying txs, not just gathering statistics.

I was thinking that you could send a fixed `VERSION` string and no feature messages (`WTXIDRELAY`, `SENDADDRV2`, etc), as a way of minimising how identifiable your node is versus other clients doing sensitive-relay. (I don't think you can have a larger anonymity set than that, since "send a si
...

💬 brunoerg commented on issue "Increase fuzz coverage in the wallet":
(https://github.com/bitcoin/bitcoin/issues/27272#issuecomment-1546428911)
I'm working on increasing fuzz coverage in the wallet. Just to track:

- #27647 - for `wallet/fees` stuff
- #27585 - add more coverage for coin selection

:lock: fanquake locked an issue: "I can take the lock on this issue?"
(https://github.com/bitcoin/bitcoin/issues/27648)

⚠️ random9brat opened an issue: "BIP 39 words update"
(https://github.com/bitcoin/bitcoin/issues/27649)
### Please describe the feature you'd like to see added.

Would it be possible to update bip39 words somehow to contain Serbian words (would be much useful for people from Balkan). I know this github is just btc repo but where would be the best place for this conversation to start?

### Is your feature related to a problem, if so please describe it.

Brain wallet would be much easier for at least 50.000.000 people (Balkans+outside who uses that language).

### Describe the solution you'd like

A
...