💬 tdb3 commented on pull request "Add option dbfilesize to control LevelDB target ("max") file size":
(https://github.com/bitcoin/bitcoin/pull/30059#discussion_r1597350392)
The text states a range of 1MiB to 1024MiB, but these values didn't seem to be enforced (e.g. 0.5, -3, and 1025 were not rejected). Is the intent here to provide guidance for the user (i.e. tell the user to choose 1 to 1024 MiB) rather than enforce a specific range of values?

👍 theStack approved a pull request: "refactor: Remove unused code from `subprocess.h` header"
(https://github.com/bitcoin/bitcoin/pull/30081#pullrequestreview-2051074164)
Code-review ACK 5a11d3023f7d0cde777f3496c0f3aa381823d749

Thanks for following up!

👍 theStack approved a pull request: "crypto: add `NUMS_H` const"
(https://github.com/bitcoin/bitcoin/pull/30048#pullrequestreview-2051074508)
re-ACK 56b8f5e163465673e329f77f6cfcff3f0a42d533

📝 jonatack opened a pull request: "p2p: detect addnode cjdns peers in GetAddedNodeInfo()"
(https://github.com/bitcoin/bitcoin/pull/30085)
Addnode peers connected to us via the cjdns network are currently not detected by `CConnman::GetAddedNodeInfo()`, i.e. `fConnected` is always false. This causes the following issues:

- RPC `getaddednodeinfo` incorrectly shows them as not connected

- `CConnman::ThreadOpenAddedConnections()` continually retries to connect them

Fix the issue and add a unit regression test. Extracted from #28248. Suggest running the test with:

`./src/test/test_bitcoin -t net_peer_connection_tests -l test
...

💬 fanquake commented on pull request "script: lief updates":
(https://github.com/bitcoin/bitcoin/pull/30084#issuecomment-2105581083)
> This patch also avoids some duplicate work by the person who updates lief later on, who will most likely not see this if it is binned.

If someone if updating LIEF in Guix, they need to check the changes, and update the scripts for the new version, if needed.


I'm guessing your changes here will actually just break the Guix build, given it's still using 0.13.2?

💬 theStack commented on pull request "test: fix MiniWallet script-path spend (missing parity bit in leaf version)":
(https://github.com/bitcoin/bitcoin/pull/30076#discussion_r1597371622)
Good point. I think what we could do here is first asserting that there is only a single entry in the `_taproot_info.leaves` dictionary and then using that entry, so we don't even need the "only-path" magic string. Will look into it.

💬 theStack commented on pull request "test: fix MiniWallet script-path spend (missing parity bit in leaf version)":
(https://github.com/bitcoin/bitcoin/pull/30076#discussion_r1597374285)
The corresponding C++ code in Core for creating the control block (second item on the witness stack) can be found in the signingprovider module, see function [`TaprootBuilder::GetSpendData()`](https://github.com/bitcoin/bitcoin/blob/2cedb42a928fbf3a1e0e8715e918497cbe64af0d/src/script/signingprovider.cpp#L402):
https://github.com/bitcoin/bitcoin/blob/2cedb42a928fbf3a1e0e8715e918497cbe64af0d/src/script/signingprovider.cpp#L414-L417

The actual witness stack, consisting of script and control blo
...

💬 vasild commented on pull request "doc: removed help text saying that peers may not connect automatically":
(https://github.com/bitcoin/bitcoin/pull/29994#issuecomment-2105630195)
Not directly related to this PR, but somewhat on topic:

```sh
# total addresses in addrman
$ bitcoin-cli getnodeaddresses 0 |jq 'length'
73425

# number of addresses with != 8333 port
$ bitcoin-cli getnodeaddresses 0 |jq 'map(select(.port != 8333)) |map(select(.network != "i2p")) |length'
3667

# distribution of != 8333 ports
$ bitcoin-cli getnodeaddresses 0 |jq 'map(select(.port != 8333)) |map(select(.network != "i2p")) |.[].port' |sort |uniq -c |sort -r
1952 39388
158 8332
1
...

💬 josibake commented on pull request "refactor: Model the bech32 charlimit as an Enum":
(https://github.com/bitcoin/bitcoin/pull/30047#discussion_r1597409852)
Oof, also can't believe I missed this. Thanks for taking a look @paplorinc ! Took a look at your PR and I think this is the most elegant way to solve getting rid of the 90 in ExpandHRP, so I cherry-picked your last commit in (added `CHECKSUM_SIZE` and modified the commit message to fit this PR a bit more). As a nice side benefit, just this last commit improves the benchmark.

💬 fanquake commented on pull request "contrib: lief updates":
(https://github.com/bitcoin/bitcoin/pull/30084#issuecomment-2105653850)
> I'm guessing your changes here will actually just break the Guix build, given it's still using 0.13.2?

```bash
time BASE_CACHE="/base_cache" SOURCES_PATH="/sources" SDK_PATH="/SDKs" ./contrib/guix/guix-build
< snip >
make[1]: Leaving directory '/distsrc-base/distsrc-950b3d4587f0-x86_64-linux-gnu'
Traceback (most recent call last):
File "/distsrc-base/distsrc-950b3d4587f0-x86_64-linux-gnu/./contrib/devtools/security-check.py", line 230, in <module>
lief.Binary.FORMATS.ELF: {
Att
...

💬 josibake commented on pull request "refactor: Model the bech32 charlimit as an Enum":
(https://github.com/bitcoin/bitcoin/pull/30047#issuecomment-2105655080)
Cherry picked https://github.com/bitcoin/bitcoin/pull/29607/commits/b3b84c3b85c72135ec28904bdb4778024b74bd0d (h/t @paplorinc) to resolve https://github.com/bitcoin/bitcoin/pull/30047#discussion_r1597108664.

Ran the benchmarks and saw an improvement from the last commit, which is a nice side benefit!

#### Before

```
| ns/byte | byte/s | err% | ins/byte | cyc/byte | IPC | bra/byte | miss% | total | benchmark
|--------------------:
...

💬 josibake commented on pull request "refactor: Reduce memory copying operations in bech32 encoding/decoding":
(https://github.com/bitcoin/bitcoin/pull/29607#issuecomment-2105655507)
Concept ACK

I cherry-picked your last commit into #30047 to get rid of the hardcoded values inside `ExpandHRP`. Looking at the rest of your commits here, the rest of the changes look great and the benchmark numbers are a nice improvement. Will review more thoroughly this week!

💬 josibake commented on pull request "Silent payment index (for light wallets and consistency check)":
(https://github.com/bitcoin/bitcoin/pull/28241#discussion_r1597413689)
Yeah, with cut-through and a dust filter, this starts to feel like not a good fit for a BIP157 style filter, only because we'd basically have to get rid of the filter chain and hashes to avoid making the server constantly recalculate. Another thing about dust filters is we could make it client query param, i.e. the server still keeps everything and then the client says "only send me stuff where the UTXOs have a value of >= X". More storage space for the server, but clients then only download twe
...

🚀 fanquake merged a pull request: "build: swap cctools otool for llvm-objdump"
(https://github.com/bitcoin/bitcoin/pull/29739)

🚀 fanquake merged a pull request: "refactor: Remove unused code from `subprocess.h` header"
(https://github.com/bitcoin/bitcoin/pull/30081)

💬 hebasto commented on pull request "Reintroduce external signer support for Windows":
(https://github.com/bitcoin/bitcoin/pull/29868#issuecomment-2105674960)
Rebased due to the conflict with merged bitcoin/bitcoin#30081.

⚠️ qqxiaoteng opened an issue: "About Artificial Intelligence and digital currencies"
(https://github.com/bitcoin/bitcoin/issues/30086)
### Please describe the feature you'd like to see added.

It is believed that digital currencies such as Bitcoin and Litecoin are unnecessary, and the mining and earning of these currencies consume a large amount of human actual energy, resources, and computing power, resulting in only strings with no actual value or meaning. Using such strings as currency to measure value is not as good as using a certain indicator in the current development of artificial intelligence to act as a digital curren
...

⚠️ qqxiaoteng opened an issue: "About Artificial Intelligence and digital currencies"
(https://github.com/bitcoin/bitcoin/issues/30087)
### Please describe the feature you'd like to see added.

It is believed that digital currencies such as Bitcoin and Litecoin are unnecessary, and the mining and earning of these currencies consume a large amount of human actual energy, resources, and computing power, resulting in only strings with no actual value or meaning. Using such strings as currency to measure value is not as good as using a certain indicator in the current development of artificial intelligence to act as a digital curren
...

💬 qqxiaoteng commented on issue "About Artificial Intelligence and digital currencies":
(https://github.com/bitcoin/bitcoin/issues/30087#issuecomment-2105740834)
Keep up with the era of artificial intelligence to avoid being eliminated

✅ fanquake closed an issue: "About Artificial Intelligence and digital currencies"
(https://github.com/bitcoin/bitcoin/issues/30086)