💬 maflcko commented on issue "Error when launching Bitcoin Core":
(https://github.com/bitcoin/bitcoin/issues/29995#issuecomment-2094090470)
Closing for now, but please leave a comment if you have more information indicating that this is a bug in the software, as opposed to a user error, or corrupt hardware.
(https://github.com/bitcoin/bitcoin/issues/29995#issuecomment-2094090470)
Closing for now, but please leave a comment if you have more information indicating that this is a bug in the software, as opposed to a user error, or corrupt hardware.
💬 maflcko commented on pull request "ci: add markdown link check job":
(https://github.com/bitcoin/bitcoin/pull/30034#discussion_r1589940997)
Not sure. I think it would be good to instead run it in the existing lint task. Otherwise it can not be run locally. (See e.g. shellcheck)
Also, duplicating the exclude list in yet another place isn't ideal.
(https://github.com/bitcoin/bitcoin/pull/30034#discussion_r1589940997)
Not sure. I think it would be good to instead run it in the existing lint task. Otherwise it can not be run locally. (See e.g. shellcheck)
Also, duplicating the exclude list in yet another place isn't ideal.
💬 maflcko commented on pull request "Remove redundant `-datacarrier` option":
(https://github.com/bitcoin/bitcoin/pull/29942#issuecomment-2094095382)
Are you still working on this?
(https://github.com/bitcoin/bitcoin/pull/29942#issuecomment-2094095382)
Are you still working on this?
📝 maciejsszmigiero opened a pull request: "dbwrapper: Bump LevelDB max file size to 128 MiB to avoid system slowdown from high disk cache flush rate"
(https://github.com/bitcoin/bitcoin/pull/30039)
The default max file size for LevelDB is 2 MiB, which results in the LevelDB compaction code generating ~4 disk cache flushes per second when syncing with the Bitcoin network.
These disk cache flushes are triggered by `fdatasync()` syscall issued by the LevelDB compaction code when reaching the max file size.
If the database is on a HDD this flush rate brings the whole system to a crawl.
It also results in very slow throughput since 2 MiB * 4 flushes per second is about 8 MiB / second max t
...
(https://github.com/bitcoin/bitcoin/pull/30039)
The default max file size for LevelDB is 2 MiB, which results in the LevelDB compaction code generating ~4 disk cache flushes per second when syncing with the Bitcoin network.
These disk cache flushes are triggered by `fdatasync()` syscall issued by the LevelDB compaction code when reaching the max file size.
If the database is on a HDD this flush rate brings the whole system to a crawl.
It also results in very slow throughput since 2 MiB * 4 flushes per second is about 8 MiB / second max t
...
💬 emc99 commented on pull request "msvc: Compile `test\fuzz\miniscript.cpp`":
(https://github.com/bitcoin/bitcoin/pull/30031#issuecomment-2094127754)
There is no file at test/fuzz/miniscript
(https://github.com/bitcoin/bitcoin/pull/30031#issuecomment-2094127754)
There is no file at test/fuzz/miniscript
💬 hebasto commented on pull request "msvc: Compile `test\fuzz\miniscript.cpp`":
(https://github.com/bitcoin/bitcoin/pull/30031#issuecomment-2094128496)
> There is no file at test/fuzz/miniscript
```
$ file src/test/fuzz/miniscript.cpp
src/test/fuzz/miniscript.cpp: C++ source, ASCII text
```
(https://github.com/bitcoin/bitcoin/pull/30031#issuecomment-2094128496)
> There is no file at test/fuzz/miniscript
```
$ file src/test/fuzz/miniscript.cpp
src/test/fuzz/miniscript.cpp: C++ source, ASCII text
```
💬 hebasto commented on pull request "Simplify network-adjusted time warning logic":
(https://github.com/bitcoin/bitcoin/pull/29623#issuecomment-2094140548)
Ported to the CMake-based build system in https://github.com/hebasto/bitcoin/pull/186.
(https://github.com/bitcoin/bitcoin/pull/29623#issuecomment-2094140548)
Ported to the CMake-based build system in https://github.com/hebasto/bitcoin/pull/186.
💬 Sjors commented on pull request "Silent payment index (for light wallets and consistency check)":
(https://github.com/bitcoin/bitcoin/pull/28241#issuecomment-2094145823)
Took two days, but everything matches!
Best to run this script in a few parallel windows, because after block 790K or so it gets extremely slow.
```sh
./compare.sh 709632 790000
```
```sh
./compare.sh 790000 800000
```
etc
```sh
#!/bin/bash
# Taproot activation: 709632
set -e
TIP=`bitcoin-cli getblockcount`
for height in $(seq $1 $2); do
if [ $height -eq $TIP ]; then
echo "Reached the tip at $height"
exit 0
fi
if [ $((height % 1000)) -eq 0 ]; then
...
(https://github.com/bitcoin/bitcoin/pull/28241#issuecomment-2094145823)
Took two days, but everything matches!
Best to run this script in a few parallel windows, because after block 790K or so it gets extremely slow.
```sh
./compare.sh 709632 790000
```
```sh
./compare.sh 790000 800000
```
etc
```sh
#!/bin/bash
# Taproot activation: 709632
set -e
TIP=`bitcoin-cli getblockcount`
for height in $(seq $1 $2); do
if [ $height -eq $TIP ]; then
echo "Reached the tip at $height"
exit 0
fi
if [ $((height % 1000)) -eq 0 ]; then
...
💬 hebasto commented on pull request "msvc: Compile `test\fuzz\miniscript.cpp`":
(https://github.com/bitcoin/bitcoin/pull/30031#issuecomment-2094192476)
Ported to the CMake-based build system in https://github.com/hebasto/bitcoin/pull/187.
(https://github.com/bitcoin/bitcoin/pull/30031#issuecomment-2094192476)
Ported to the CMake-based build system in https://github.com/hebasto/bitcoin/pull/187.
💬 hebasto commented on pull request "build: no-longer disable WARN_CXXFLAGS when CXXFLAGS is set":
(https://github.com/bitcoin/bitcoin/pull/25972#issuecomment-2094203809)
Ported to the CMake-based build system in https://github.com/hebasto/bitcoin/pull/188.
(https://github.com/bitcoin/bitcoin/pull/25972#issuecomment-2094203809)
Ported to the CMake-based build system in https://github.com/hebasto/bitcoin/pull/188.
💬 sipa commented on pull request "dbwrapper: Bump LevelDB max file size to 128 MiB to avoid system slowdown from high disk cache flush rate":
(https://github.com/bitcoin/bitcoin/pull/30039#issuecomment-2094216364)
@jamesob Feel like benchmarking a reindex or so with this?
(https://github.com/bitcoin/bitcoin/pull/30039#issuecomment-2094216364)
@jamesob Feel like benchmarking a reindex or so with this?
💬 tdb3 commented on issue "RfC: increase minimum prune target?":
(https://github.com/bitcoin/bitcoin/issues/30037#issuecomment-2094223248)
It seems reasonable and safer to increase the min prune target, since blocks can be larger post-segwit (and we've seen it, e.g. 774628). Some rough napkin math for a new value (correct me if something looks off):
- 4MB per block, 288 blocks = 1152MB
- Add 15% for Undo data = 1325MB
- Add 20% for Orphan block rate = 1590MB
- Add one block file + added 15% undo data = 147MB
- Target >= 1737MB, so something like 1750MB seems at first glance that it could work
I would recommend we minimize
...
(https://github.com/bitcoin/bitcoin/issues/30037#issuecomment-2094223248)
It seems reasonable and safer to increase the min prune target, since blocks can be larger post-segwit (and we've seen it, e.g. 774628). Some rough napkin math for a new value (correct me if something looks off):
- 4MB per block, 288 blocks = 1152MB
- Add 15% for Undo data = 1325MB
- Add 20% for Orphan block rate = 1590MB
- Add one block file + added 15% undo data = 147MB
- Target >= 1737MB, so something like 1750MB seems at first glance that it could work
I would recommend we minimize
...
💬 katesalazar commented on pull request "doc: fix broken relative md links":
(https://github.com/bitcoin/bitcoin/pull/30025#issuecomment-2094235168)
Concept ACK
(https://github.com/bitcoin/bitcoin/pull/30025#issuecomment-2094235168)
Concept ACK
💬 Eunovo commented on pull request "rpc: parse legacy pubkeys consistently with specific error messages":
(https://github.com/bitcoin/bitcoin/pull/28336#issuecomment-2094267853)
Tested ACK https://github.com/bitcoin/bitcoin/pull/28336/commits/98570fe29bb08d7edc48011aa6b9731c6ab4ed2e
Verified that all checks are covered in tests
(https://github.com/bitcoin/bitcoin/pull/28336#issuecomment-2094267853)
Tested ACK https://github.com/bitcoin/bitcoin/pull/28336/commits/98570fe29bb08d7edc48011aa6b9731c6ab4ed2e
Verified that all checks are covered in tests
💬 laanwj commented on pull request "[PoC, nomerge] PCP IPv4 portmap+IPv6 pinhole test":
(https://github.com/bitcoin/bitcoin/pull/30005#issuecomment-2094269014)
@sjors It creates a IPv4 as well as IPv6 mappings now. The added complexity isn't even too bad, mostly a matter of using CNetAddr/CService/Sock abstraction that we already have.
(https://github.com/bitcoin/bitcoin/pull/30005#issuecomment-2094269014)
@sjors It creates a IPv4 as well as IPv6 mappings now. The added complexity isn't even too bad, mostly a matter of using CNetAddr/CService/Sock abstraction that we already have.
💬 laanwj commented on pull request "chainparams: Add achow101 DNS seeder":
(https://github.com/bitcoin/bitcoin/pull/30007#issuecomment-2094289500)
> TXT records could work but that will require lot of other changes (out of scope)
Right-DNS can serve arbitrary information, but it would complicate things in the client: the cross-platform libc resolver, `getaddrinfo`, can only resolve addresses. So for that'd we'd need to add some dependency library for DNS resolving. The question is whether it's worth it.
Also, IIRC caching DNS servers don't always cache TXT records (*because* they can store arbitrary data); the caching and the privacy
...
(https://github.com/bitcoin/bitcoin/pull/30007#issuecomment-2094289500)
> TXT records could work but that will require lot of other changes (out of scope)
Right-DNS can serve arbitrary information, but it would complicate things in the client: the cross-platform libc resolver, `getaddrinfo`, can only resolve addresses. So for that'd we'd need to add some dependency library for DNS resolving. The question is whether it's worth it.
Also, IIRC caching DNS servers don't always cache TXT records (*because* they can store arbitrary data); the caching and the privacy
...
💬 paplorinc commented on pull request "test: use assert_greater_than util":
(https://github.com/bitcoin/bitcoin/pull/30019#discussion_r1590014513)
this looks like an actual assert_greater_than
```suggestion
assert_greater_than(conflicted_A_tx["confirmations"], 0)
```
(https://github.com/bitcoin/bitcoin/pull/30019#discussion_r1590014513)
this looks like an actual assert_greater_than
```suggestion
assert_greater_than(conflicted_A_tx["confirmations"], 0)
```
🤔 paplorinc requested changes to a pull request: "test: use assert_greater_than util"
(https://github.com/bitcoin/bitcoin/pull/30019#pullrequestreview-2039497086)
The errors will improve this way, even though I wouldn't call the code more readable.
And to not make it less readable, I suggested a few other places where these changes could be applied.
(https://github.com/bitcoin/bitcoin/pull/30019#pullrequestreview-2039497086)
The errors will improve this way, even though I wouldn't call the code more readable.
And to not make it less readable, I suggested a few other places where these changes could be applied.
💬 paplorinc commented on pull request "test: use assert_greater_than util":
(https://github.com/bitcoin/bitcoin/pull/30019#discussion_r1590014819)
```suggestion
assert_greater_than(MAX_NODES + 1, idx)
```
(https://github.com/bitcoin/bitcoin/pull/30019#discussion_r1590014819)
```suggestion
assert_greater_than(MAX_NODES + 1, idx)
```
💬 paplorinc commented on pull request "test: use assert_greater_than util":
(https://github.com/bitcoin/bitcoin/pull/30019#discussion_r1590015083)
Do we need the `Decimal` here?
Seems basically the same as https://github.com/bitcoin/bitcoin/pull/30019/files?diff=split&w=1#diff-c1987c24fa3e5c788d16de5359500a19a1fea4f379e4288d076cf92be89541dcR478
(https://github.com/bitcoin/bitcoin/pull/30019#discussion_r1590015083)
Do we need the `Decimal` here?
Seems basically the same as https://github.com/bitcoin/bitcoin/pull/30019/files?diff=split&w=1#diff-c1987c24fa3e5c788d16de5359500a19a1fea4f379e4288d076cf92be89541dcR478