💬 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?
💬 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.
----
#
...