💬 apulsifer commented on issue "LevelDB read failure: Corruption: block checksum mismatch":
(https://github.com/bitcoin/bitcoin/issues/30159#issuecomment-2127451533)
xfs on the root and data drive
sudo mkswap /dev/nvme[4 GB disk]
sudo swapon /dev/nvme[4 GB disk]
sudo mkdir /bdata
sudo mkfs -t xfs /dev/nvme[40 GB disk]
lsblk -o name,size,type,uuid
sudo nano /etc/fstab
add to fstab:
UUID=[4 GB disk uuid] swap swap defaults 0 0
UUID=[40 GB disk uuid] /bdata xfs defaults,nofail 0 2
sudo mount -a
Filesystem Type Size Used Avail Use% Mounted on
devtmpfs devtmpfs 4.0M 0 4.0M 0% /dev
tmpfs tmpfs 210M
...
(https://github.com/bitcoin/bitcoin/issues/30159#issuecomment-2127451533)
xfs on the root and data drive
sudo mkswap /dev/nvme[4 GB disk]
sudo swapon /dev/nvme[4 GB disk]
sudo mkdir /bdata
sudo mkfs -t xfs /dev/nvme[40 GB disk]
lsblk -o name,size,type,uuid
sudo nano /etc/fstab
add to fstab:
UUID=[4 GB disk uuid] swap swap defaults 0 0
UUID=[40 GB disk uuid] /bdata xfs defaults,nofail 0 2
sudo mount -a
Filesystem Type Size Used Avail Use% Mounted on
devtmpfs devtmpfs 4.0M 0 4.0M 0% /dev
tmpfs tmpfs 210M
...
📝 sipa opened a pull request: "util: add BitSet"
(https://github.com/bitcoin/bitcoin/pull/30160)
Extracted from #30126.
This introduces the `BitSet` data structure, inspired by `std::bitset`, but with a few features that cannot be implemented on top without efficiency loss:
* Finding the first set bit.
* Finding the last set bit.
* Iterating over all set bits.
And a few other operators that help readability for #30126:
* `operator/` for set subtraction
* `operator&&` for testing whether intersection is non-empty
* `Fill` to construct a set with all numbers from 0 to n-1, inclusi
...
(https://github.com/bitcoin/bitcoin/pull/30160)
Extracted from #30126.
This introduces the `BitSet` data structure, inspired by `std::bitset`, but with a few features that cannot be implemented on top without efficiency loss:
* Finding the first set bit.
* Finding the last set bit.
* Iterating over all set bits.
And a few other operators that help readability for #30126:
* `operator/` for set subtraction
* `operator&&` for testing whether intersection is non-empty
* `Fill` to construct a set with all numbers from 0 to n-1, inclusi
...
💬 luke-jr commented on pull request "rpc: introduce getversion RPC":
(https://github.com/bitcoin/bitcoin/pull/30112#issuecomment-2127454770)
Concept NACK, consumers should just check if features are available
(https://github.com/bitcoin/bitcoin/pull/30112#issuecomment-2127454770)
Concept NACK, consumers should just check if features are available
💬 apulsifer commented on issue "LevelDB read failure: Corruption: block checksum mismatch":
(https://github.com/bitcoin/bitcoin/issues/30159#issuecomment-2127461229)
> Would it be possible for you to compile and run with asan, or a similar sanitizer?
I don't see where I would get a chunk of time to do that right now.... But as I mentioned, I copied the corrupted files, and that might give some clues to someone familiar with their format (especially if the corruption is ascii in the middle of binary, or vice versa)
(https://github.com/bitcoin/bitcoin/issues/30159#issuecomment-2127461229)
> Would it be possible for you to compile and run with asan, or a similar sanitizer?
I don't see where I would get a chunk of time to do that right now.... But as I mentioned, I copied the corrupted files, and that might give some clues to someone familiar with their format (especially if the corruption is ascii in the middle of binary, or vice versa)
💬 achow101 commented on pull request "policy: restrict all TRUC (v3) transactions to 10kvB":
(https://github.com/bitcoin/bitcoin/pull/29873#issuecomment-2127467518)
ACK 154b2b2296edccb5ed24e829798dacb6195edc11
(https://github.com/bitcoin/bitcoin/pull/29873#issuecomment-2127467518)
ACK 154b2b2296edccb5ed24e829798dacb6195edc11
💬 ryanofsky commented on pull request "Encapsulate warnings in generalized node::Warnings and remove globals":
(https://github.com/bitcoin/bitcoin/pull/30058#discussion_r1611939057)
I think in the longer run the string/enum distinction should not matter too much here.
In general, requiring kernel applications to get warning information from `warning`, or `warningSet`/`warningUnset` callbacks is not a nice API. It would make more sense for the kernel to treat errors and warnings similarly, and return this information directly in function return values or output arguments, instead of indirect callbacks. We have PR #29642 and #29700 which change kernel code to bubble up err
...
(https://github.com/bitcoin/bitcoin/pull/30058#discussion_r1611939057)
I think in the longer run the string/enum distinction should not matter too much here.
In general, requiring kernel applications to get warning information from `warning`, or `warningSet`/`warningUnset` callbacks is not a nice API. It would make more sense for the kernel to treat errors and warnings similarly, and return this information directly in function return values or output arguments, instead of indirect callbacks. We have PR #29642 and #29700 which change kernel code to bubble up err
...
💬 TheCharlatan commented on pull request "indexes: Don't wipe indexes again when continuing a prior reindex":
(https://github.com/bitcoin/bitcoin/pull/30132#issuecomment-2127473363)
Updated 9de8b263dabd6dd2f86f1f0253c6ee3fac7a4407 -> dd290b3b58a1f9f9e182803866b8e2b9f72ecb3b ([preserveIndexOnRestart_1](https://github.com/TheCharlatan/bitcoin/tree/preserveIndexOnRestart_1) -> [preserveIndexOnRestart_2](https://github.com/TheCharlatan/bitcoin/tree/preserveIndexOnRestart_2), [compare](https://github.com/TheCharlatan/bitcoin/compare/preserveIndexOnRestart_1..preserveIndexOnRestart_2))
* Added a commit for testing that the indexes are still there when continuing a reindex.
(https://github.com/bitcoin/bitcoin/pull/30132#issuecomment-2127473363)
Updated 9de8b263dabd6dd2f86f1f0253c6ee3fac7a4407 -> dd290b3b58a1f9f9e182803866b8e2b9f72ecb3b ([preserveIndexOnRestart_1](https://github.com/TheCharlatan/bitcoin/tree/preserveIndexOnRestart_1) -> [preserveIndexOnRestart_2](https://github.com/TheCharlatan/bitcoin/tree/preserveIndexOnRestart_2), [compare](https://github.com/TheCharlatan/bitcoin/compare/preserveIndexOnRestart_1..preserveIndexOnRestart_2))
* Added a commit for testing that the indexes are still there when continuing a reindex.
💬 BenWestgate commented on pull request "Drop -dbcache limit":
(https://github.com/bitcoin/bitcoin/pull/28358#issuecomment-2127487328)
> If we are worried about someone using an inappropriate value we can try to solve that separately (maybe by testing that we can allocate that much at startup or something?).
The best would be never setting it greater than total RAM. `-dbcache=<total RAM>` is still higher than optimal as there will be applications in memory that won't be swapped to disk including Bitcoin. But measuring Available RAM or swap is precarious as it changes.
Since other reviewers mentioned it's only wildly exces
...
(https://github.com/bitcoin/bitcoin/pull/28358#issuecomment-2127487328)
> If we are worried about someone using an inappropriate value we can try to solve that separately (maybe by testing that we can allocate that much at startup or something?).
The best would be never setting it greater than total RAM. `-dbcache=<total RAM>` is still higher than optimal as there will be applications in memory that won't be swapped to disk including Bitcoin. But measuring Available RAM or swap is precarious as it changes.
Since other reviewers mentioned it's only wildly exces
...
🚀 achow101 merged a pull request: "policy: restrict all TRUC (v3) transactions to 10kvB"
(https://github.com/bitcoin/bitcoin/pull/29873)
(https://github.com/bitcoin/bitcoin/pull/29873)
💬 Sjors commented on pull request "net: Replace libnatpmp with built-in PCP+NATPMP implementation":
(https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1611953200)
Possible alternative, makes it a bit more clear that we rely on `rt->rtm_msglen` to be correct. A `for` loop gives a false sense of safety. No strong feelings though.
```cpp
std::byte* p = buf.data();
while (true) {
rt = (const struct rt_msghdr*)p;
// ...
p += rt->rtm_msglen;
if (p == buf.data() + buf.size()) break;
assert(p < buf.data() + buf.size());
}
```
(https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1611953200)
Possible alternative, makes it a bit more clear that we rely on `rt->rtm_msglen` to be correct. A `for` loop gives a false sense of safety. No strong feelings though.
```cpp
std::byte* p = buf.data();
while (true) {
rt = (const struct rt_msghdr*)p;
// ...
p += rt->rtm_msglen;
if (p == buf.data() + buf.size()) break;
assert(p < buf.data() + buf.size());
}
```
💬 apoelstra commented on pull request "rpc: introduce getversion RPC":
(https://github.com/bitcoin/bitcoin/pull/30112#issuecomment-2127508227)
@luke-jr are you suggesting that all consumers should call the entire RPC surface to confirm which calls are present, what the types of all inputs are, what the types of all outputs are, etc., in order to determine whether their software is compatible with the interface?
(https://github.com/bitcoin/bitcoin/pull/30112#issuecomment-2127508227)
@luke-jr are you suggesting that all consumers should call the entire RPC surface to confirm which calls are present, what the types of all inputs are, what the types of all outputs are, etc., in order to determine whether their software is compatible with the interface?
👍 stickies-v approved a pull request: "[26.x] archive 26.1 release notes + backports"
(https://github.com/bitcoin/bitcoin/pull/29899#pullrequestreview-2074368997)
ACK a29e9e5fea98925cd19c4e9e8738de67d04da549 modulo release notes touchup
All backport commits are clean, except for:
- b1481467bdf6c1300341d1e2ca399ca5e30fdace: because of https://github.com/bitcoin/bitcoin/pull/28955
- 109b9d74f50651aa4765d6eec047f09e497215fd: because of LLVM version bump in #29659
- 7d13e6ab51a02db33fea4df61f70c3f919016a8b: because of removing -rpcserialversion (#28890, and #28438)
All of these look good to me.
nit: in b1481467bdf6c1300341d1e2ca399ca5e30fdace comm
...
(https://github.com/bitcoin/bitcoin/pull/29899#pullrequestreview-2074368997)
ACK a29e9e5fea98925cd19c4e9e8738de67d04da549 modulo release notes touchup
All backport commits are clean, except for:
- b1481467bdf6c1300341d1e2ca399ca5e30fdace: because of https://github.com/bitcoin/bitcoin/pull/28955
- 109b9d74f50651aa4765d6eec047f09e497215fd: because of LLVM version bump in #29659
- 7d13e6ab51a02db33fea4df61f70c3f919016a8b: because of removing -rpcserialversion (#28890, and #28438)
All of these look good to me.
nit: in b1481467bdf6c1300341d1e2ca399ca5e30fdace comm
...
💬 stickies-v commented on pull request "[26.x] archive 26.1 release notes + backports":
(https://github.com/bitcoin/bitcoin/pull/29899#discussion_r1611933793)
I think we usually keep this in for backports too?
(https://github.com/bitcoin/bitcoin/pull/29899#discussion_r1611933793)
I think we usually keep this in for backports too?
💬 furszy commented on pull request "indexes: Don't wipe indexes again when continuing a prior reindex":
(https://github.com/bitcoin/bitcoin/pull/30132#discussion_r1611957557)
thinking more about this, let's remove this timeout=3. It could fail on slow system or when running valgrind.
(https://github.com/bitcoin/bitcoin/pull/30132#discussion_r1611957557)
thinking more about this, let's remove this timeout=3. It could fail on slow system or when running valgrind.
💬 maflcko commented on pull request "indexes: Don't wipe indexes again when continuing a prior reindex":
(https://github.com/bitcoin/bitcoin/pull/30132#discussion_r1611961965)
Any reason to put the stop under the busy loop here?
(https://github.com/bitcoin/bitcoin/pull/30132#discussion_r1611961965)
Any reason to put the stop under the busy loop here?
💬 maflcko commented on pull request "indexes: Don't wipe indexes again when continuing a prior reindex":
(https://github.com/bitcoin/bitcoin/pull/30132#discussion_r1611961304)
any reason to use the busy loop here?
(https://github.com/bitcoin/bitcoin/pull/30132#discussion_r1611961304)
any reason to use the busy loop here?
💬 maflcko commented on pull request "indexes: Don't wipe indexes again when continuing a prior reindex":
(https://github.com/bitcoin/bitcoin/pull/30132#discussion_r1611962533)
nit: Should use named args for integral literal arguments
(https://github.com/bitcoin/bitcoin/pull/30132#discussion_r1611962533)
nit: Should use named args for integral literal arguments
💬 glozow commented on pull request "[26.x] archive 26.1 release notes + backports":
(https://github.com/bitcoin/bitcoin/pull/29899#issuecomment-2127527079)
Thanks so much @stickies-v! Nice catch, fixed the transifex line and PR number
(https://github.com/bitcoin/bitcoin/pull/29899#issuecomment-2127527079)
Thanks so much @stickies-v! Nice catch, fixed the transifex line and PR number
💬 Sjors commented on pull request "net: Replace libnatpmp with built-in PCP+NATPMP implementation":
(https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1611967800)
And maybe:
```cpp
// rt_msghdr is followed by zero or more sockaddrs, as indicated by rtm_addrs
auto sa = (const struct sockaddr*)(p + sizeof(rt_msghdr));
```
(https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1611967800)
And maybe:
```cpp
// rt_msghdr is followed by zero or more sockaddrs, as indicated by rtm_addrs
auto sa = (const struct sockaddr*)(p + sizeof(rt_msghdr));
```
💬 Sjors commented on pull request "net: Replace libnatpmp with built-in PCP+NATPMP implementation":
(https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1611968560)
How about:
```cpp
// rt_msghdr is followed by zero or more sockaddrs, as indicated by rtm_addrs
auto sa = (const struct sockaddr*)(p + sizeof(rt_msghdr));
```
(https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1611968560)
How about:
```cpp
// rt_msghdr is followed by zero or more sockaddrs, as indicated by rtm_addrs
auto sa = (const struct sockaddr*)(p + sizeof(rt_msghdr));
```