📝 monica69marquezserra-hash opened a pull request: "Create bc1qp4chet93ep8t5hc9kahrzk3k6zeyd88kdz6ml5"
(https://github.com/bitcoin/bitcoin/pull/33450)
<!--
*** Please remove the following help text before submitting: ***

Pull requests without a rationale and clear improvement may be closed
immediately.

GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->

<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:

* Any test improvements or new tests that improv
...

💬 fjahr commented on issue "v30.0 Testing":
(https://github.com/bitcoin/bitcoin/issues/33368#issuecomment-3315992776)
I have done full IBD with rc1 on mainnet and signet and also synced coinstatsindex and txindex from scratch. Also did some light testing once IBD was complete. No issues so far.

💬 l0rinc commented on pull request "log: don't rate limit "rolling forward" messages":
(https://github.com/bitcoin/bitcoin/pull/33443#issuecomment-3316042996)
I don't think this info is essential (though I like your proposed solution in case it is).
It's extremely spammy currently (my guess is that the logging is more costly than the operation itself).
Alternatively, we could show percentages only (as mentioned in the PR description), since we know how much work we need to do in advance.
I will push a proposal for that as well.

💬 tnndbtc commented on issue "v30.0 Testing":
(https://github.com/bitcoin/bitcoin/issues/33368#issuecomment-3316086099)
Tested https://github.com/bitcoin-core/bitcoin-devwiki/wiki/30.0-Release-Candidate-Testing-Guide/#11-datacarriersize-increase , but, it returns **_false_** instead of **_true_** after restarting bitcoind

Steps:
1) Modified bitcoin.conf:
```
regtest=1
daemon=1
datadir=/tmp/30-rc-test

# Options for regtest
[regtest]
rpcport=18443
datacarriersize=83
```

2) `alias bcli30='/Users/user/Downloads/tmp/bitcoin-30.0rc1/bin/bitcoin-cli -conf=/Users/user/Downloads/tmp/bitcoin-30.0rc1/bitcoin.conf'`

3) s
...

💬 janb84 commented on issue "v30.0 Testing":
(https://github.com/bitcoin/bitcoin/issues/33368#issuecomment-3316135266)
> Tested https://github.com/bitcoin-core/bitcoin-devwiki/wiki/30.0-Release-Candidate-Testing-Guide/#11-datacarriersize-increase , but, it returns **_false_** instead of **_true_** after restarting bitcoind. This is on MacOS Sequoia 15.1.1, Chip: Apple M1
>
> Binary downloaded: https://bitcoincore.org/bin/bitcoin-core-30.0/test.rc1/bitcoin-30.0rc1-arm64-apple-darwin.tar.gz
>
> Steps:
>
> 1. Modified bitcoin.conf:
>
> ```
> regtest=1
> daemon=1
> datadir=/tmp/30-rc-test
>


> ```
>
> Then I
...

🤔 pablomartin4btc reviewed a pull request: "refactor: unify container presence checks (without PR conflicts)"
(https://github.com/bitcoin/bitcoin/pull/33192#pullrequestreview-3250119556)
ACK f70d2c7faa8f7d724e146e4c409de9c6778b7299

Even the split into 3 commits was present in previous attempt (https://github.com/bitcoin/bitcoin/pull/33094), I didn't have the chance to check it there, it helps a lot in reviewing so many files.

💬 tnndbtc commented on issue "v30.0 Testing":
(https://github.com/bitcoin/bitcoin/issues/33368#issuecomment-3316188338)
@janb84 Indeed, I mis-read the test step. After commenting out `datacarriersize=83` and then restart the bitcoind, the test runs fine.

💬 ostruvek commented on pull request "Release: 30.0 translations update":
(https://github.com/bitcoin/bitcoin/pull/33275#issuecomment-3316206549)
Hello, sorry for a delay on my side. I have reviewed the Czech suggestions and made the edits.

📝 hebasto opened a pull request: "doc: Add `INSTALL.md` to Linux release tarballs"
(https://github.com/bitcoin/bitcoin/pull/33451)
Closes https://github.com/bitcoin/bitcoin/issues/32097:
> Better I think would be to add instructions for the most popular desktop distros.

💬 hebasto commented on issue "Linux download needs installation instructions":
(https://github.com/bitcoin/bitcoin/issues/32097#issuecomment-3316215206)
> [@hebasto](https://github.com/hebasto) can you followup here

https://github.com/bitcoin/bitcoin/pull/33451.

💬 l0rinc commented on pull request "net/rpc: Report inv information for debugging":
(https://github.com/bitcoin/bitcoin/pull/33448#discussion_r2366371242)
The CI failures indicate that we need to add the other field as well:
```suggestion
"last_inv_sequence": 0,
"inv_to_send": 0,
```
---
tested locally that it fixes the tests:
```
TEST | STATUS | DURATION

rpc_net.py --v1transport | ✓ Passed | 12 s
rpc_net.py --v2transport | ✓ Passed | 10 s
```

💬 TheCharlatan commented on pull request "depends: static libxcb-cursor":
(https://github.com/bitcoin/bitcoin/pull/33434#issuecomment-3316249701)
Concept ACK

I'm not familiar enough with X to say why it's seemingly not possible to link all the `xcb_utils` statically, but this change seems sane to me.

📝 hebasto opened a pull request: "Release: 30.0rc2 translations update"
(https://github.com/bitcoin/bitcoin/pull/33452)
This PR updates Spanish (es) and Czech (cs) translations and addresses the following comments:
- https://github.com/bitcoin/bitcoin/pull/33275#issuecomment-3315273628
- https://github.com/bitcoin/bitcoin/pull/33275#issuecomment-3316206549

Updates for other languages were skipped, as I believe the review effort would not be worthwhile at this stage of the release process.

💬 andrewtoth commented on pull request "validation: fetch block inputs on parallel threads 10% faster IBD":
(https://github.com/bitcoin/bitcoin/pull/31132#issuecomment-3316319902)
I benchmarked the latest branch with default dbcache up to 912683. Results are a speedup of 14% - 5:06 vs 5:47.

| Command | Mean [s] | Min [s] | Max [s] | Relative |
|:---|---:|---:|---:|---:|
| `echo 688c03597afb0b76077f1ffc4608eef19481056e && /usr/bin/time ./build/bin/bitcoind -printtoconsole=0 -connect=192.168.2.171 -stopatheight=912683` | 18430.672 ± 19.856 | 18416.631 | 18444.712 | 1.00 |
| `echo 1444ed855f438f1270104fca259ce61b99ed5cdb && /usr/bin/time ./build/bin/bitcoind -printtoco
...

💬 polespinasa commented on issue "Cleanup CFeeRate constructor (sat/vB vs BTC/kvB)":
(https://github.com/bitcoin/bitcoin/issues/23129#issuecomment-3316478295)
Is this still relevant after #32750 is merged?

💬 ajtowns commented on pull request "Exponentially-decaying tx inventory queue":
(https://github.com/bitcoin/bitcoin/pull/33449#issuecomment-3316552769)
It's not the queue that's exponentially decaying, but the inv queue drain rate tracking the relay rate with an exponential decay? *shrug*

The previous PR, #33448, may be helpful for observing the behaviour of this PR in the wild. I use the following command occassionally:

```sh
bitcoin-cli getpeerinfo | jq -j '.[] | (.inv_to_send, " ", .last_inv_sequence, " ", .connection_type, " ", .id, " ", .relaytxes, " ", .synced_blocks, " ", (.network|sub("not_publicly_routable";"onion")), " inv-rx:"
...

💬 sipa commented on pull request "Exponentially-decaying tx inventory queue":
(https://github.com/bitcoin/bitcoin/pull/33449#issuecomment-3316566982)
@ajtowns What I meant is actually the queue itself whose size decays exponentially, though only in a fairly constrained setting.

I believe the following statement holds:

If at time $T$ the size of the queue is $N$, and after that, no more than $B$ inv elements get added to the queue per trickle, then after any trickle occurring at time $T+t$, the size of the queue is bounded by $\left\lceil N \exp(-t/A) \right\rceil$, regardless of how many trickles happened in between, or when those happened.
...

💬 l0rinc commented on issue "v30.0 Testing":
(https://github.com/bitcoin/bitcoin/issues/33368#issuecomment-3316923745)
I also just finished a full `-reindex` until `-stopatheight=915303` compiled with `AppleClang 17.0.0.17000319` against `master` with ` -assumevalid=0` (to test full script validation) and `-DCMAKE_BUILD_TYPE=Debug` (to test every assertion) and `-DHAVE_ARM_SHANI=OFF` (to test software hashing). Reindexing until block 1 took a day and reindexing the chainstate took 3 more (with default settings a reindex takes about 4-5 hours). I have cancelled it a few times, rolled the blocks forward successf
...

💬 ajtowns commented on pull request "Exponentially-decaying tx inventory queue":
(https://github.com/bitcoin/bitcoin/pull/33449#issuecomment-3317060161)
Oh! I hadn't noticed this was a different formula to what (I thought) we were discussing earlier.

I think our exponential-based inv timing implies that 1% of invs will be at least 23s after the previous inv, and the formula above will mean we immediately send 32% of our current queue at that point, which seems excessive to me? Compared to the previous sim I ran, I get 45% of the max queue size (2045 vs 4500), but 270%-580% of the max inv size.

💬 0xB10C commented on pull request "net/rpc: Report inv information for debugging":
(https://github.com/bitcoin/bitcoin/pull/33448#issuecomment-3317216893)
Concept ACK. I had exposing the inv-to-send size on my todo list too.