💬 ariard commented on issue "Follow-up from Moderation Rules":
(https://github.com/bitcoin/bitcoin/issues/31110#issuecomment-2423252219)
> It speculates about individuals rather than focusing on ideas.
It’s not like some people with perm rights have actually done “fat fingers” mistakes in the past…( and I can go back in IRC logs here). If it’s an infrastructure compromise it’s still better to be verbose about it. Github fwiw is used for code distribution among the whole ecosystem. It’s very different than a bug directly affecting core code.
Better to continue the discussion in /meta.
(https://github.com/bitcoin/bitcoin/issues/31110#issuecomment-2423252219)
> It speculates about individuals rather than focusing on ideas.
It’s not like some people with perm rights have actually done “fat fingers” mistakes in the past…( and I can go back in IRC logs here). If it’s an infrastructure compromise it’s still better to be verbose about it. Github fwiw is used for code distribution among the whole ecosystem. It’s very different than a bug directly affecting core code.
Better to continue the discussion in /meta.
💬 andrewtoth commented on pull request "sync: improve CCoinsViewCache ReallocateCache - 2nd try":
(https://github.com/bitcoin/bitcoin/pull/30370#issuecomment-2423256908)
While trying to implement the approach above, it became apparent that we still need the call to ReallocateCache here. This is for the case when IBD is done with memory normally reserved for the mempool. After IBD is finished and the mempool starts filling up and encroaching on the memory used by the cache, the cache must be reallocated. There is no other way to shrink it.
I think it's good that we are not calling reallocate on the ephemeral views, but I think we can do better with the preallo
...
(https://github.com/bitcoin/bitcoin/pull/30370#issuecomment-2423256908)
While trying to implement the approach above, it became apparent that we still need the call to ReallocateCache here. This is for the case when IBD is done with memory normally reserved for the mempool. After IBD is finished and the mempool starts filling up and encroaching on the memory used by the cache, the cache must be reallocated. There is no other way to shrink it.
I think it's good that we are not calling reallocate on the ephemeral views, but I think we can do better with the preallo
...
💬 Prabhat1308 commented on pull request "test: Assert that when we add the max orphan amount that we cannot add anymore and that a random orphan gets dropped":
(https://github.com/bitcoin/bitcoin/pull/31040#issuecomment-2423265583)
Concept ACK for the test
While we are trying to add another orphan transaction when the max amount is reached , why are we dropping a random orphan and not just the incoming orphan ? Even in the condition of the node getting DOSed , having to remove a random transaction translates to some amount of work done while its not the case when we just drop the incoming transaction.
(https://github.com/bitcoin/bitcoin/pull/31040#issuecomment-2423265583)
Concept ACK for the test
While we are trying to add another orphan transaction when the max amount is reached , why are we dropping a random orphan and not just the incoming orphan ? Even in the condition of the node getting DOSed , having to remove a random transaction translates to some amount of work done while its not the case when we just drop the incoming transaction.
⚠️ Sandra-Amina-Boss opened an issue: "From https://github.com/bitcoin/bitcoin/blob/master/doc/fuzzing.md#macos-hints-for-libfuzzer:"
(https://github.com/bitcoin/bitcoin/issues/31115)
From https://github.com/bitcoin/bitcoin/blob/master/doc/fuzzing.md#macos-hints-for-libfuzzer:
> brew install llvm
...
> $ cmake --preset=libfuzzer -DCMAKE_C_COMPILER="$(brew --prefix llvm)/bin/clang" -DCMAKE_CXX_COMPILER="$(brew --prefix llvm)/bin/clang++" -DAPPEND_LDFLAGS=-Wl,-no_warn_duplicate_libraries
_Originally posted by @sipa in https://github.com/bitcoin/bitcoin/issues/31111#issuecomment-2421978663_
(https://github.com/bitcoin/bitcoin/issues/31115)
From https://github.com/bitcoin/bitcoin/blob/master/doc/fuzzing.md#macos-hints-for-libfuzzer:
> brew install llvm
...
> $ cmake --preset=libfuzzer -DCMAKE_C_COMPILER="$(brew --prefix llvm)/bin/clang" -DCMAKE_CXX_COMPILER="$(brew --prefix llvm)/bin/clang++" -DAPPEND_LDFLAGS=-Wl,-no_warn_duplicate_libraries
_Originally posted by @sipa in https://github.com/bitcoin/bitcoin/issues/31111#issuecomment-2421978663_
✅ fanquake closed an issue: "From https://github.com/bitcoin/bitcoin/blob/master/doc/fuzzing.md#macos-hints-for-libfuzzer:"
(https://github.com/bitcoin/bitcoin/issues/31115)
(https://github.com/bitcoin/bitcoin/issues/31115)
:lock: fanquake locked an issue: "."
(https://github.com/bitcoin/bitcoin/issues/31115)
(https://github.com/bitcoin/bitcoin/issues/31115)
💬 theStack commented on issue "COIN_VALUE no longer accessible in const contexts":
(https://github.com/bitcoin/bitcoin/issues/31113#issuecomment-2423360017)
Was this issue intended for another project? Bitcoin Core never had a `COIN_VALUE` constant, there is also no `Amount` class (or namespace).
(https://github.com/bitcoin/bitcoin/issues/31113#issuecomment-2423360017)
Was this issue intended for another project? Bitcoin Core never had a `COIN_VALUE` constant, there is also no `Amount` class (or namespace).
💬 casey commented on issue "COIN_VALUE no longer accessible in const contexts":
(https://github.com/bitcoin/bitcoin/issues/31113#issuecomment-2423366334)
Oh no. Yes, it was, this was intended for `rust-bitcoin/rust-bitcoin` 😅 Sorry for the noise!
(https://github.com/bitcoin/bitcoin/issues/31113#issuecomment-2423366334)
Oh no. Yes, it was, this was intended for `rust-bitcoin/rust-bitcoin` 😅 Sorry for the noise!
✅ casey closed an issue: "COIN_VALUE no longer accessible in const contexts"
(https://github.com/bitcoin/bitcoin/issues/31113)
(https://github.com/bitcoin/bitcoin/issues/31113)
💬 sdaftuar commented on issue "Trouble fuzzing on macos":
(https://github.com/bitcoin/bitcoin/issues/31111#issuecomment-2423719604)
Thanks, I actually had tried that but got some kind of failure as well. Starting over and trying that step now, I see that the first step of setting up the build_fuzz directory succeeds, but when I try to build, I get this linker error:
```
$ cmake --build build_fuzz/ -j12
<snip>
[ 99%] Building CXX object src/test/fuzz/CMakeFiles/fuzz.dir/__/__/wallet/test/fuzz/scriptpubkeyman.cpp.o
[ 99%] Building CXX object src/test/fuzz/CMakeFiles/fuzz.dir/__/__/wallet/test/fuzz/wallet_bdb_parser.cpp.o
...
(https://github.com/bitcoin/bitcoin/issues/31111#issuecomment-2423719604)
Thanks, I actually had tried that but got some kind of failure as well. Starting over and trying that step now, I see that the first step of setting up the build_fuzz directory succeeds, but when I try to build, I get this linker error:
```
$ cmake --build build_fuzz/ -j12
<snip>
[ 99%] Building CXX object src/test/fuzz/CMakeFiles/fuzz.dir/__/__/wallet/test/fuzz/scriptpubkeyman.cpp.o
[ 99%] Building CXX object src/test/fuzz/CMakeFiles/fuzz.dir/__/__/wallet/test/fuzz/wallet_bdb_parser.cpp.o
...
💬 fanquake commented on issue "Trouble fuzzing on macos":
(https://github.com/bitcoin/bitcoin/issues/31111#issuecomment-2423755158)
I think this is an issue with latest LLVM and Apples ld, see #31049. You could `brew install llvm@18` (and sub that in for however you'd got clang/clang++ available), and that will work for now, until we fix the incompatibilty.
(https://github.com/bitcoin/bitcoin/issues/31111#issuecomment-2423755158)
I think this is an issue with latest LLVM and Apples ld, see #31049. You could `brew install llvm@18` (and sub that in for however you'd got clang/clang++ available), and that will work for now, until we fix the incompatibilty.
⚠️ ella-quicknode opened an issue: "estimateSmartFee error: "Insufficient data or no feerate found""
(https://github.com/bitcoin/bitcoin/issues/31116)
I am seeing a couple of issues been raised in the past. We currently experiencing the same issue. The work around was to delete `fee_estimate.dat` and `mempool.dat` from the node.
With regards to the below comment from issue 19150, I would like know what are the recommended config we can apply? Or is there a better way to manage this error?
It is only possible to estimate fees when you have enough mempool transactions from the outside p2p network
_Originally posted by @maflcko in h
...
(https://github.com/bitcoin/bitcoin/issues/31116)
I am seeing a couple of issues been raised in the past. We currently experiencing the same issue. The work around was to delete `fee_estimate.dat` and `mempool.dat` from the node.
With regards to the below comment from issue 19150, I would like know what are the recommended config we can apply? Or is there a better way to manage this error?
It is only possible to estimate fees when you have enough mempool transactions from the outside p2p network
_Originally posted by @maflcko in h
...
✅ sdaftuar closed an issue: "Trouble fuzzing on macos"
(https://github.com/bitcoin/bitcoin/issues/31111)
(https://github.com/bitcoin/bitcoin/issues/31111)
💬 sdaftuar commented on issue "Trouble fuzzing on macos":
(https://github.com/bitcoin/bitcoin/issues/31111#issuecomment-2423772036)
Thanks @fanquake, yeah this looks like a duplicate issue -- closing.
(https://github.com/bitcoin/bitcoin/issues/31111#issuecomment-2423772036)
Thanks @fanquake, yeah this looks like a duplicate issue -- closing.
💬 hodlinator commented on pull request "Windows bitcoind stall debugging [NOMERGE, DRAFT]":
(https://github.com/bitcoin/bitcoin/pull/30956#issuecomment-2423789917)
Had a few other cases. First 2 are confirmed to be the same issue - seeding randomness entropy from Windows performance data obtained through the Registry API during startup hangs when attempting to release a semaphore deep in Microsoft code. Turned off the once-per-hour CI schedule on my master-branch for now. More work to follow next week.
(https://github.com/bitcoin/bitcoin/pull/30956#issuecomment-2423789917)
Had a few other cases. First 2 are confirmed to be the same issue - seeding randomness entropy from Windows performance data obtained through the Registry API during startup hangs when attempting to release a semaphore deep in Microsoft code. Turned off the once-per-hour CI schedule on my master-branch for now. More work to follow next week.
💬 sipa commented on issue "Listen on random port by default (not 8333)":
(https://github.com/bitcoin/bitcoin/issues/31036#issuecomment-2423835494)
Concept ACK.
Regarding DNS seeds, I think there is a 3rd option, which I favor. We keep the DNS seeds, but treat them always as addrfetch peers, rather than as names to resolve directly. This is what already happens when you're running in tor-only mode: a P2P connection is made "to" the DNS seed name at port 8333 (i.e., the Tor exit node resolves the name for us, picks one of the IP addresses it resolves to, establishes a connection to it, and forwards it to us without revealing what that IP
...
(https://github.com/bitcoin/bitcoin/issues/31036#issuecomment-2423835494)
Concept ACK.
Regarding DNS seeds, I think there is a 3rd option, which I favor. We keep the DNS seeds, but treat them always as addrfetch peers, rather than as names to resolve directly. This is what already happens when you're running in tor-only mode: a P2P connection is made "to" the DNS seed name at port 8333 (i.e., the Tor exit node resolves the name for us, picks one of the IP addresses it resolves to, establishes a connection to it, and forwards it to us without revealing what that IP
...
💬 pinheadmz commented on issue "estimateSmartFee error: "Insufficient data or no feerate found"":
(https://github.com/bitcoin/bitcoin/issues/31116#issuecomment-2423838766)
Fee rate estimates are only available after the full node has monitored transactions entering the mempool and waiting for confirmation, over a long enough time span. I'm not sure what deleting those files would accomplish besides starting that process over. You can set a hard coded fee, or trust fee rates provide from some other source (like mempool.space)
(https://github.com/bitcoin/bitcoin/issues/31116#issuecomment-2423838766)
Fee rate estimates are only available after the full node has monitored transactions entering the mempool and waiting for confirmation, over a long enough time span. I'm not sure what deleting those files would accomplish besides starting that process over. You can set a hard coded fee, or trust fee rates provide from some other source (like mempool.space)
💬 sipa commented on pull request "test: Fuzz the human-readable part of bech32 as well":
(https://github.com/bitcoin/bitcoin/pull/30623#discussion_r1807329737)
BIP173/BIP350 specify the maximum length of bech32/bech32m strings as 90 characters.
And "bias" isn't really the right metric in fuzz tests, because fuzz tests aren't trying to be uniformly random (they're coverage driven, aiming to explore variations that trigger edge cases). Of course, ideally all (hard) cases are (easily) reachable from the fuzz input. If you'd actually restrict the input to 90 characters, then yes, the code for detecting too-long strings would never trigger. But it's not
...
(https://github.com/bitcoin/bitcoin/pull/30623#discussion_r1807329737)
BIP173/BIP350 specify the maximum length of bech32/bech32m strings as 90 characters.
And "bias" isn't really the right metric in fuzz tests, because fuzz tests aren't trying to be uniformly random (they're coverage driven, aiming to explore variations that trigger edge cases). Of course, ideally all (hard) cases are (easily) reachable from the fuzz input. If you'd actually restrict the input to 90 characters, then yes, the code for detecting too-long strings would never trigger. But it's not
...
💬 ella-quicknode commented on issue "estimateSmartFee error: "Insufficient data or no feerate found"":
(https://github.com/bitcoin/bitcoin/issues/31116#issuecomment-2423861403)
Thanks for the reply @pinheadmz
We are seeing enough tx entering our infra consistently, but for some reason, the nodes occasionally returns this error `Insufficient data or no feerate found`, this error can't be self subsided unless we manually delete the dat files, then nodes recovered for estmiateSmartFee.
I was just curious what's the expected behaviour when we see error `Insufficient data or no feerate found`. 🙂
(https://github.com/bitcoin/bitcoin/issues/31116#issuecomment-2423861403)
Thanks for the reply @pinheadmz
We are seeing enough tx entering our infra consistently, but for some reason, the nodes occasionally returns this error `Insufficient data or no feerate found`, this error can't be self subsided unless we manually delete the dat files, then nodes recovered for estmiateSmartFee.
I was just curious what's the expected behaviour when we see error `Insufficient data or no feerate found`. 🙂
💬 pinheadmz commented on issue "estimateSmartFee error: "Insufficient data or no feerate found"":
(https://github.com/bitcoin/bitcoin/issues/31116#issuecomment-2423881142)
So the nodes return fee estimates as expected for some time, then just stop for some reason?
(https://github.com/bitcoin/bitcoin/issues/31116#issuecomment-2423881142)
So the nodes return fee estimates as expected for some time, then just stop for some reason?