⚠️ 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?
💬 pinheadmz commented on issue "estimateSmartFee error: "Insufficient data or no feerate found"":
(https://github.com/bitcoin/bitcoin/issues/31116#issuecomment-2423881835)
It might be helpful to have version of the affected node and debug log output. You may need to run `bitcoin-cli logging '["estimatefee"]'`
(https://github.com/bitcoin/bitcoin/issues/31116#issuecomment-2423881835)
It might be helpful to have version of the affected node and debug log output. You may need to run `bitcoin-cli logging '["estimatefee"]'`
💬 EthanHeilman commented on pull request "CAT in Tapscript (BIP-347)":
(https://github.com/bitcoin/bitcoin/pull/29247#issuecomment-2423935186)
@achow101 What does draft vs non-draft mean in the bitcoin-core github? My understanding was moving from draft to non-draft means code is ready for review. Similar to moving WIP.
Is draft/non-draft is being used to signal community consensus or bitcoin-core consensus? If so, I agree this should be a draft.
(https://github.com/bitcoin/bitcoin/pull/29247#issuecomment-2423935186)
@achow101 What does draft vs non-draft mean in the bitcoin-core github? My understanding was moving from draft to non-draft means code is ready for review. Similar to moving WIP.
Is draft/non-draft is being used to signal community consensus or bitcoin-core consensus? If so, I agree this should be a draft.
🤔 Zidane115 reviewed a pull request: "optimization: reserve memory allocation for transaction inputs/outputs"
(https://github.com/bitcoin/bitcoin/pull/30093#pullrequestreview-2379595565)
Wwe
(https://github.com/bitcoin/bitcoin/pull/30093#pullrequestreview-2379595565)
Wwe
📝 fjahr opened a pull request: "miner: Reorg Testnet4 minimum difficulty blocks"
(https://github.com/bitcoin/bitcoin/pull/31117)
Note: This is just a proof of concept put here for discussion/feedback/brainstorming/improvement. I am not sure if we want to merge this into core at all since it can be dealt with externally as well. But this was the simplest way for me to make it work and it's probably also simpler for many miners to run this branch rather than another external software.
### Context
Testnet4 fixes block storms but it kept the minimum-difficulty exception in place. The rationale was that this would be the
...
(https://github.com/bitcoin/bitcoin/pull/31117)
Note: This is just a proof of concept put here for discussion/feedback/brainstorming/improvement. I am not sure if we want to merge this into core at all since it can be dealt with externally as well. But this was the simplest way for me to make it work and it's probably also simpler for many miners to run this branch rather than another external software.
### Context
Testnet4 fixes block storms but it kept the minimum-difficulty exception in place. The rationale was that this would be the
...
📝 fjahr converted_to_draft a pull request: "miner: Reorg Testnet4 minimum difficulty blocks"
(https://github.com/bitcoin/bitcoin/pull/31117)
Note: This is just a proof of concept put here for discussion/feedback/brainstorming/improvement. I am not sure if we want to merge this into core at all since it can be dealt with externally as well. But this was the simplest way for me to make it work and it's probably also simpler for many miners to run this branch rather than another external software.
### Context
Testnet4 fixes block storms but it kept the minimum-difficulty exception in place. The rationale was that this would be the
...
(https://github.com/bitcoin/bitcoin/pull/31117)
Note: This is just a proof of concept put here for discussion/feedback/brainstorming/improvement. I am not sure if we want to merge this into core at all since it can be dealt with externally as well. But this was the simplest way for me to make it work and it's probably also simpler for many miners to run this branch rather than another external software.
### Context
Testnet4 fixes block storms but it kept the minimum-difficulty exception in place. The rationale was that this would be the
...
💬 fjahr commented on pull request "Testnet4 including PoW difficulty adjustment fix":
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2424064713)
Re: the recent discussion here, see #31117
(https://github.com/bitcoin/bitcoin/pull/29775#issuecomment-2424064713)
Re: the recent discussion here, see #31117
📝 l0rinc opened a pull request: "doc: replace `-?` with `-h` for bench_bitcoin help"
(https://github.com/bitcoin/bitcoin/pull/31118)
The question mark is interpreted as a wildcard for any single character in Zsh (see https://www.techrepublic.com/article/globbing-wildcard-characters-with-zsh), so `bench_bitcoin -?` will not show the help message on systems using Zsh, such as macOS.
Since `-h` provides equivalent help functionality (as defined in https://github.com/bitcoin/bitcoin/blob/master/src/common/args.cpp#L684-L693), the `benchmarking.md` documentation has been updated to ensure compatibility with macOS.
----
#
...
(https://github.com/bitcoin/bitcoin/pull/31118)
The question mark is interpreted as a wildcard for any single character in Zsh (see https://www.techrepublic.com/article/globbing-wildcard-characters-with-zsh), so `bench_bitcoin -?` will not show the help message on systems using Zsh, such as macOS.
Since `-h` provides equivalent help functionality (as defined in https://github.com/bitcoin/bitcoin/blob/master/src/common/args.cpp#L684-L693), the `benchmarking.md` documentation has been updated to ensure compatibility with macOS.
----
#
...
💬 TheCharlatan commented on pull request "init: Some small chainstate load improvements":
(https://github.com/bitcoin/bitcoin/pull/31046#discussion_r1807432735)
I think your suggestion is a bit better. I'll push it if something else comes up. Looks to me like that code iterated over the chainstates in a previous un-pushed version, that would explain why only the errors are surfaced here. There is also ryanofsky's assumeutxo state cleanup PR that could catch this later if we don't get it here
(https://github.com/bitcoin/bitcoin/pull/31046#discussion_r1807432735)
I think your suggestion is a bit better. I'll push it if something else comes up. Looks to me like that code iterated over the chainstates in a previous un-pushed version, that would explain why only the errors are surfaced here. There is also ryanofsky's assumeutxo state cleanup PR that could catch this later if we don't get it here
💬 TheCharlatan commented on pull request "init: Correct coins db cache size setting":
(https://github.com/bitcoin/bitcoin/pull/31064#discussion_r1807433006)
fyi I also hope we can improve how to do this in ryanofsky's #30214.
(https://github.com/bitcoin/bitcoin/pull/31064#discussion_r1807433006)
fyi I also hope we can improve how to do this in ryanofsky's #30214.
💬 l0rinc commented on pull request "test: Fuzz the human-readable part of bech32 as well":
(https://github.com/bitcoin/bitcoin/pull/30623#discussion_r1807434072)
> BIP173/BIP350 specify the maximum length of bech32/bech32m strings as 90 characters.
Yes, but https://en.bitcoin.it/wiki/BIP_0352 states that:
> Note: [BIP173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki) imposes a 90 character limit for Bech32 segwit addresses and limits versions to 0 through 16, whereas a silent payment address requires at least 117 characters[[12]](https://en.bitcoin.it/wiki/BIP_0352#cite_note-why_117_chars-12) and allows versions up to 31. Additional
...
(https://github.com/bitcoin/bitcoin/pull/30623#discussion_r1807434072)
> BIP173/BIP350 specify the maximum length of bech32/bech32m strings as 90 characters.
Yes, but https://en.bitcoin.it/wiki/BIP_0352 states that:
> Note: [BIP173](https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki) imposes a 90 character limit for Bech32 segwit addresses and limits versions to 0 through 16, whereas a silent payment address requires at least 117 characters[[12]](https://en.bitcoin.it/wiki/BIP_0352#cite_note-why_117_chars-12) and allows versions up to 31. Additional
...
💬 andrewtoth commented on pull request "validation: Make ReplayBlocks interruptible":
(https://github.com/bitcoin/bitcoin/pull/30155#issuecomment-2424107647)
Concept ACK
It appears to me that the size of the cache used in ReplayBlocks is never checked if it grows too large. Wouldn't this mean that if the node was sufficiently far behind, the rolling forward would fill up the cache to levels exceeding dbcache? This would result in a cycle of rolling forward and then OOM crashing, never being able to write any chainstate to disk.
(https://github.com/bitcoin/bitcoin/pull/30155#issuecomment-2424107647)
Concept ACK
It appears to me that the size of the cache used in ReplayBlocks is never checked if it grows too large. Wouldn't this mean that if the node was sufficiently far behind, the rolling forward would fill up the cache to levels exceeding dbcache? This would result in a cycle of rolling forward and then OOM crashing, never being able to write any chainstate to disk.