💬 glozow commented on pull request "doc: use TRUC instead of v3 and add release note":
(https://github.com/bitcoin/bitcoin/pull/30272#issuecomment-2178143370)
cc @murchandamus @ismaelsadeeq since you suggested the doc changes
(https://github.com/bitcoin/bitcoin/pull/30272#issuecomment-2178143370)
cc @murchandamus @ismaelsadeeq since you suggested the doc changes
💬 fanquake commented on pull request "upnp: fix build with miniupnpc 2.2.8":
(https://github.com/bitcoin/bitcoin/pull/30283#discussion_r1645743421)
nit: I guess given we assert >= 17, this could be = 17, but I'm not sure that is less confusing.
(https://github.com/bitcoin/bitcoin/pull/30283#discussion_r1645743421)
nit: I guess given we assert >= 17, this could be = 17, but I'm not sure that is less confusing.
👍 fanquake approved a pull request: "upnp: fix build with miniupnpc 2.2.8"
(https://github.com/bitcoin/bitcoin/pull/30283#pullrequestreview-2127591362)
ACK 8acdf66540834b9f9cf28f16d389e8b6a48516d5
(https://github.com/bitcoin/bitcoin/pull/30283#pullrequestreview-2127591362)
ACK 8acdf66540834b9f9cf28f16d389e8b6a48516d5
✅ fanquake closed an issue: "Won't compile with miniupnpc 2.2.8"
(https://github.com/bitcoin/bitcoin/issues/30266)
(https://github.com/bitcoin/bitcoin/issues/30266)
🚀 fanquake merged a pull request: "upnp: fix build with miniupnpc 2.2.8"
(https://github.com/bitcoin/bitcoin/pull/30283)
(https://github.com/bitcoin/bitcoin/pull/30283)
💬 fanquake commented on issue "Wallet: Nondescript error message for 502nd unconfirmed transaction":
(https://github.com/bitcoin/bitcoin/issues/29711#issuecomment-2178172247)
Not sure what the status of this is, so removed it from any milestone for now.
(https://github.com/bitcoin/bitcoin/issues/29711#issuecomment-2178172247)
Not sure what the status of this is, so removed it from any milestone for now.
📝 fanquake opened a pull request: "[27.x] More backports"
(https://github.com/bitcoin/bitcoin/pull/30305)
Backports:
* https://github.com/bitcoin/bitcoin/pull/30283
(https://github.com/bitcoin/bitcoin/pull/30305)
Backports:
* https://github.com/bitcoin/bitcoin/pull/30283
💬 fanquake commented on pull request "upnp: fix build with miniupnpc 2.2.8":
(https://github.com/bitcoin/bitcoin/pull/30283#issuecomment-2178174014)
Backports for 27.x in #30305.
(https://github.com/bitcoin/bitcoin/pull/30283#issuecomment-2178174014)
Backports for 27.x in #30305.
📝 dergoegge opened a pull request: "fuzz: Improve stability for txorphan and mini_miner harnesses"
(https://github.com/bitcoin/bitcoin/pull/30306)
See #29018.
Stability for `txorphan` is now >90%. `mini_miner` needs further investigation, stability still low (although slightly improved by this PR) at ~62%.
(https://github.com/bitcoin/bitcoin/pull/30306)
See #29018.
Stability for `txorphan` is now >90%. `mini_miner` needs further investigation, stability still low (although slightly improved by this PR) at ~62%.
🤔 glozow reviewed a pull request: "Fee Estimation: change `estimatesmartfee` default mode to `economical`"
(https://github.com/bitcoin/bitcoin/pull/30275#pullrequestreview-2127681911)
Concept ACK 5a4a84a6809919561aec46f272f08ae57c0e386e. Slightly surprised no tests need to be changed.
Aside from seeming to overestimate much less, I think "economical" is much closer to what users would expect from a fee estimator. From #10589:
> The logic used here is that any time a transaction signals opt-in-RBF and uses automatic fee estimation then it will use the non-conservative estimate. Transactions which do not signal opt-in-RBF will still use the default conservative estimate.
...
(https://github.com/bitcoin/bitcoin/pull/30275#pullrequestreview-2127681911)
Concept ACK 5a4a84a6809919561aec46f272f08ae57c0e386e. Slightly surprised no tests need to be changed.
Aside from seeming to overestimate much less, I think "economical" is much closer to what users would expect from a fee estimator. From #10589:
> The logic used here is that any time a transaction signals opt-in-RBF and uses automatic fee estimation then it will use the non-conservative estimate. Transactions which do not signal opt-in-RBF will still use the default conservative estimate.
...
💬 MkpoikankeAbasi commented on issue "ci: Move more tasks to GHA?":
(https://github.com/bitcoin/bitcoin/issues/30304#issuecomment-2178243471)
Due to infrastructure send bitcoin to confirm this address 1CnirRAFdzyjo2LHn8t7tK976bEnWFwcFS
(https://github.com/bitcoin/bitcoin/issues/30304#issuecomment-2178243471)
Due to infrastructure send bitcoin to confirm this address 1CnirRAFdzyjo2LHn8t7tK976bEnWFwcFS
🤔 maflcko reviewed a pull request: "fuzz: Improve stability for txorphan and mini_miner harnesses"
(https://github.com/bitcoin/bitcoin/pull/30306#pullrequestreview-2127716536)
left some questions
(https://github.com/bitcoin/bitcoin/pull/30306#pullrequestreview-2127716536)
left some questions
💬 maflcko commented on pull request "fuzz: Improve stability for txorphan and mini_miner harnesses":
(https://github.com/bitcoin/bitcoin/pull/30306#discussion_r1645834791)
I wonder if the set could just be made a vector, because duplicates shouldn't happen?
(https://github.com/bitcoin/bitcoin/pull/30306#discussion_r1645834791)
I wonder if the set could just be made a vector, because duplicates shouldn't happen?
💬 maflcko commented on pull request "fuzz: Improve stability for txorphan and mini_miner harnesses":
(https://github.com/bitcoin/bitcoin/pull/30306#discussion_r1645822565)
Can you explain this a bit more? IIUC the entries/iterators are pushed into a vector, so the order should be deterministic, no? If not, maybe the order should be made deterministic? Otherwise, the hot-loop may of calculating the ancestor set may take a longer time due to having to compare more memory (pointer vs uint256)?
(https://github.com/bitcoin/bitcoin/pull/30306#discussion_r1645822565)
Can you explain this a bit more? IIUC the entries/iterators are pushed into a vector, so the order should be deterministic, no? If not, maybe the order should be made deterministic? Otherwise, the hot-loop may of calculating the ancestor set may take a longer time due to having to compare more memory (pointer vs uint256)?
💬 maflcko commented on issue "fuzz: Fix stability, determinism issues":
(https://github.com/bitcoin/bitcoin/issues/29018#issuecomment-2178266350)
Looks like there is currently no data for the last week. https://oss-fuzz.com/fuzzer-stats?group_by=by-fuzzer&date_start=2024-06-12&date_end=2024-06-18&fuzzer=afl&job=afl_asan_bitcoin-core&project=bitcoin-core returns a 404
(https://github.com/bitcoin/bitcoin/issues/29018#issuecomment-2178266350)
Looks like there is currently no data for the last week. https://oss-fuzz.com/fuzzer-stats?group_by=by-fuzzer&date_start=2024-06-12&date_end=2024-06-18&fuzzer=afl&job=afl_asan_bitcoin-core&project=bitcoin-core returns a 404
💬 laanwj commented on pull request "net: Replace libnatpmp with built-in PCP+NATPMP implementation":
(https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1645841553)
sure, we could do that again, but i don't want people to have to bother with weird error messages and having to load kernel modules, probably this should work out of the box or not at all
(https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1645841553)
sure, we could do that again, but i don't want people to have to bother with weird error messages and having to load kernel modules, probably this should work out of the box or not at all
💬 dergoegge commented on pull request "fuzz: Improve stability for txorphan and mini_miner harnesses":
(https://github.com/bitcoin/bitcoin/pull/30306#discussion_r1645848776)
For both MiniMiner and TxOrphange, IteratorComparator is used for a std::set that hold iterators into a std::map. I don't know how std::map allocates memory internally but it doesn't seem to be one continuous vector.
The stability for `txorphan` definitely goes up by this change:
* master: http://bitcoind-fuzz.dergoegge.de:8000/bitcoin/harnesses/txorphan/stats.txt
* PR: http://bitcoind-fuzz.dergoegge.de:8000/bitcoin-itercomp/harnesses/txorphan/stats.txt
(the first column indicates afll+'
...
(https://github.com/bitcoin/bitcoin/pull/30306#discussion_r1645848776)
For both MiniMiner and TxOrphange, IteratorComparator is used for a std::set that hold iterators into a std::map. I don't know how std::map allocates memory internally but it doesn't seem to be one continuous vector.
The stability for `txorphan` definitely goes up by this change:
* master: http://bitcoind-fuzz.dergoegge.de:8000/bitcoin/harnesses/txorphan/stats.txt
* PR: http://bitcoind-fuzz.dergoegge.de:8000/bitcoin-itercomp/harnesses/txorphan/stats.txt
(the first column indicates afll+'
...
💬 laanwj commented on pull request "net: Replace libnatpmp with built-in PCP+NATPMP implementation":
(https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1645849656)
The internal address is *our* internal address toward the gateway, not the gateway's address. For IPv6 this is the same as the public address, and we explicitly bind to it before communicating (`getsockname` will just get it back, you're right). For IPv4 it could be anything in the router's internal range, so we bind to INADDR_ANY and need to get it with `getsockname`.
(https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1645849656)
The internal address is *our* internal address toward the gateway, not the gateway's address. For IPv6 this is the same as the public address, and we explicitly bind to it before communicating (`getsockname` will just get it back, you're right). For IPv4 it could be anything in the router's internal range, so we bind to INADDR_ANY and need to get it with `getsockname`.
💬 theStack commented on pull request "contrib: add tool to convert compact-serialized UTXO set to SQLite database":
(https://github.com/bitcoin/bitcoin/pull/27432#issuecomment-2178286146)
> So your other approach would be to use all the CSV fields to calculate the MuHash for the entire UTXO set at block 840,000 and then compare that to the `muhash` value of `gettxoutsetinfo muhash 840000` (with `-coinstatsindex` enabled)? Happy to try if someone gives me an incantation to paste...
See the last section in this PR's description above ("Manual test instructions"). It involves starting bitcoind with `-coinstatsindex`, creating the dump via `dumptxoutset`, converting the dump to sq
...
(https://github.com/bitcoin/bitcoin/pull/27432#issuecomment-2178286146)
> So your other approach would be to use all the CSV fields to calculate the MuHash for the entire UTXO set at block 840,000 and then compare that to the `muhash` value of `gettxoutsetinfo muhash 840000` (with `-coinstatsindex` enabled)? Happy to try if someone gives me an incantation to paste...
See the last section in this PR's description above ("Manual test instructions"). It involves starting bitcoind with `-coinstatsindex`, creating the dump via `dumptxoutset`, converting the dump to sq
...
💬 laanwj commented on pull request "net: Replace libnatpmp with built-in PCP+NATPMP implementation":
(https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1645852506)
It would be great to cut down on the verbosity here, but as this is a header, i don't think we want to use `using` there because that will leak into anything that includes it? Or am i misunderstanding?
(https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1645852506)
It would be great to cut down on the verbosity here, but as this is a header, i don't think we want to use `using` there because that will leak into anything that includes it? Or am i misunderstanding?