💬 pablomartin4btc commented on pull request "assumeutxo, rpc: Improve EOF error when reading snapshot metadata in loadtxoutset":
(https://github.com/bitcoin/bitcoin/pull/28670#discussion_r1597331838)
It makes sense, I'll fix it, thanks!
(https://github.com/bitcoin/bitcoin/pull/28670#discussion_r1597331838)
It makes sense, I'll fix it, thanks!
📝 jonatack opened a pull request: "script: lief updates"
(https://github.com/bitcoin/bitcoin/pull/30084)
Fix the following linter errors observed since recent releases of lief (see its [changelog](https://lief.re/doc/latest/changelog.html))
```
contrib/devtools/symbol-check.py:269: error: Module has no attribute "NOTE_TYPES" [attr-defined]
contrib/devtools/symbol-check.py:270: error: Module has no attribute "NOTE_ABIS" [attr-defined]
contrib/devtools/symbol-check.py:274: error: Module has no attribute "EXE_FORMATS" [attr-defined]
contrib/devtools/symbol-check.py:281: error: Module has no
...
(https://github.com/bitcoin/bitcoin/pull/30084)
Fix the following linter errors observed since recent releases of lief (see its [changelog](https://lief.re/doc/latest/changelog.html))
```
contrib/devtools/symbol-check.py:269: error: Module has no attribute "NOTE_TYPES" [attr-defined]
contrib/devtools/symbol-check.py:270: error: Module has no attribute "NOTE_ABIS" [attr-defined]
contrib/devtools/symbol-check.py:274: error: Module has no attribute "EXE_FORMATS" [attr-defined]
contrib/devtools/symbol-check.py:281: error: Module has no
...
💬 fanquake commented on pull request "script: lief updates":
(https://github.com/bitcoin/bitcoin/pull/30084#issuecomment-2105498216)
> Fix the following linter errors observed
There are currently no linter errors if you [run the linter using the container](https://github.com/bitcoin/bitcoin/tree/master/test/lint), which installs the same versions as the CI. This is the recommended way to run the linters, as it avoids differences that may occur due to different versions of dependencies installed on your local system, and the need for changes like this.
> since recent releases of lief
As LIEF mostly exists here for the
...
(https://github.com/bitcoin/bitcoin/pull/30084#issuecomment-2105498216)
> Fix the following linter errors observed
There are currently no linter errors if you [run the linter using the container](https://github.com/bitcoin/bitcoin/tree/master/test/lint), which installs the same versions as the CI. This is the recommended way to run the linters, as it avoids differences that may occur due to different versions of dependencies installed on your local system, and the need for changes like this.
> since recent releases of lief
As LIEF mostly exists here for the
...
💬 jonatack commented on pull request "script: lief updates":
(https://github.com/bitcoin/bitcoin/pull/30084#issuecomment-2105505084)
This patch allows the individual linters to continue to be usefully called without Docker or Rust, per the following section of `test/lint/README.md`:
```
#### Running the tests
Individual tests can be run by directly calling the test script, e.g.:
test/lint/lint-files.py
```
I've been running them that way for 5+ years and would prefer to be able to continue doing so. If we now no longer want to support calling them directly or individually, then I'll update the README to disc
...
(https://github.com/bitcoin/bitcoin/pull/30084#issuecomment-2105505084)
This patch allows the individual linters to continue to be usefully called without Docker or Rust, per the following section of `test/lint/README.md`:
```
#### Running the tests
Individual tests can be run by directly calling the test script, e.g.:
test/lint/lint-files.py
```
I've been running them that way for 5+ years and would prefer to be able to continue doing so. If we now no longer want to support calling them directly or individually, then I'll update the README to disc
...
👋 jonatack's pull request is ready for review: "script: lief updates"
(https://github.com/bitcoin/bitcoin/pull/30084)
(https://github.com/bitcoin/bitcoin/pull/30084)
🤔 tdb3 reviewed a pull request: "Add option dbfilesize to control LevelDB target ("max") file size"
(https://github.com/bitcoin/bitcoin/pull/30059#pullrequestreview-2051068940)
Concept ACK.
Thank you. Seems reasonable to include this as a debug option, and increases flexibility over the single value chosen for PR #30039. Left an inline comment/question.
Ran a quick sanity check:
With `dbfilesize=64` set (along with txindex=1), performed an IBD on Signet from a node on the same LAN, then stopped and restarted bitcoind. Saw chainstate and indexes/txindex files that were close to 64MB (blocks/index for signet was less than 64MB, but still had a file over 2MB).
...
(https://github.com/bitcoin/bitcoin/pull/30059#pullrequestreview-2051068940)
Concept ACK.
Thank you. Seems reasonable to include this as a debug option, and increases flexibility over the single value chosen for PR #30039. Left an inline comment/question.
Ran a quick sanity check:
With `dbfilesize=64` set (along with txindex=1), performed an IBD on Signet from a node on the same LAN, then stopped and restarted bitcoind. Saw chainstate and indexes/txindex files that were close to 64MB (blocks/index for signet was less than 64MB, but still had a file over 2MB).
...
💬 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?
(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!
(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
(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
...
(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?
(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.
(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
...
(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
...
(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.
(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
...
(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
|--------------------:
...
(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!
(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
...
(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)
(https://github.com/bitcoin/bitcoin/pull/29739)