💬 glozow commented on pull request "refactor: TxDownloadManager + fuzzing":
(https://github.com/bitcoin/bitcoin/pull/30110#discussion_r1801661898)
Thanks for noticing, very subtle! Added a commit to make this change explicit, though it is overwritten immediately afterwards.

💬 glozow commented on pull request "refactor: TxDownloadManager + fuzzing":
(https://github.com/bitcoin/bitcoin/pull/30110#discussion_r1801662930)
Added a comment that this specifically refers to peers in the map.

I also added a doxygen comment to the `TxDownloadManager` definition saying that this class isn't thread-safe and needs to be externally synced.

💬 glozow commented on pull request "refactor: TxDownloadManager + fuzzing":
(https://github.com/bitcoin/bitcoin/pull/30110#issuecomment-2414663136)
Resolved https://github.com/bitcoin/bitcoin/pull/30110#issuecomment-2391859626 by adding this:

> don't return package if child is in rejects filter(seems most robust?)

I like this suggestion as well:

> Call TxOrphanage::EraseTx using both txid and wtxid in this case (witness-free tx can never be valid)

I've dropped the one_honest_peer fuzzer and plan to open it as a separate PR, because it's quite a large portion of the new code and imo underripe compared to the rest of the changes.
...

💬 1440000bytes commented on pull request "wallet: Deniability API (Unilateral Transaction Meta-Privacy)":
(https://github.com/bitcoin/bitcoin/pull/27792#issuecomment-2414671643)
Its true there was a lack of interest to review this pull request and its not the best tool for privacy. However, a worse way to do the same thing was used in Samourai earlier and still available in Ashigaru. Ricochet fee is 0.001 BTC for the default 4 hops, with an additional fee for each extra hop beyond 4.



http://ashicodepbnpvslzsl2bz7l2pwrjvajgumgac423pp3y2deprbnzz7id.onion/Ashigaru/Ashigaru-Mob
...

⚠️ D33r-Gee opened an issue: "cpp: exposing AssumeUTXO functionality to the GUI (QML) via the Node interface"
(https://github.com/bitcoin/bitcoin/issues/31094)
### Issues, reports or feature requests related to the GUI should be opened directly on the GUI repo

- [X] I still think this issue should be opened here

### Report

To facilitate UTXO snapshot loading through the GUI, specifically for the QML implementation, we need to extend the Node interface in [src/interfaces/node.h](https://github.com/bitcoin/bitcoin/blob/master/src/interfaces/node.h) and provide a corresponding implementation in [src/node/interfaces.cpp](https://github.com/bitcoin/bitco
...

💬 adamandrews1 commented on pull request "fees: document non-monotonic estimation edge case":
(https://github.com/bitcoin/bitcoin/pull/31080#discussion_r1801864730)
Nit: The lead is a bit buried here. I would plainly state "Monotonically increasing estimates are not guaranteed in certain data-sparse scenarios. In particular, (fill in the rest of your comment)"

💬 jarolrod commented on issue "cpp: exposing AssumeUTXO functionality to the GUI (QML) via the Node interface":
(https://github.com/bitcoin/bitcoin/issues/31094#issuecomment-2415197540)
I don't think this needs an issue opened up here yet, the draft implementation linked isn't ready for review.

It would be unclear who the user would be now in relation to this repo with the Qt Widgets GUI not having a design to represent AssumeUTXO states.

Issues related to the QML GUI should be contained in that [repo](https://github.com/bitcoin-core/gui-qml), until it's clearly relevant here.

💬 furszy commented on pull request "rpc: add `revelant_blocks` to `scanblocks status`":
(https://github.com/bitcoin/bitcoin/pull/30713#issuecomment-2415235999)
> Perhaps @furszy, that https://github.com/bitcoin/bitcoin/pull/26780 on a https://github.com/bitcoin/bitcoin/pull/23549#pullrequestreview-1105712566 of the rpc command, has an idea if it's possible (and if worth it).

Not sure if it worth it but could craft an unit test that calls to the RPC command. Subclassing and setting the block manager class so the file opening method "stops" at a certain point. It would mimic the delay.

💬 willcl-ark commented on pull request "fees: document non-monotonic estimation edge case":
(https://github.com/bitcoin/bitcoin/pull/31080#discussion_r1802066494)
Thanks, I'm happy to take this suggestion. What do you think about:

* Note: Monotonically increasing estimates are not guaranteed in certain
* data-sparse scenarios. In particular, if estimateCombinedFee returns no
* valid data (-1) for some estimates for a lower target, but does return
* valid data for a higher target, the estimate can theoretically return a
* higher value for higher targets.

💬 adamandrews1 commented on pull request "fees: document non-monotonic estimation edge case":
(https://github.com/bitcoin/bitcoin/pull/31080#discussion_r1802068118)
Great - LGMT

🤔 furszy reviewed a pull request: "test: Introduce ensure_for helper"
(https://github.com/bitcoin/bitcoin/pull/30893#pullrequestreview-2370781495)
ACK 352b8209aa5

✅ D33r-Gee closed an issue: "cpp: exposing AssumeUTXO functionality to the GUI (QML) via the Node interface"
(https://github.com/bitcoin/bitcoin/issues/31094)

💬 D33r-Gee commented on issue "cpp: exposing AssumeUTXO functionality to the GUI (QML) via the Node interface":
(https://github.com/bitcoin/bitcoin/issues/31094#issuecomment-2415254311)
Makes sense... thanks for catching that... closing the issue

⚠️ elapsedluck opened an issue: "HardFork (SLH-DSA)"
(https://github.com/bitcoin/bitcoin/issues/31095)
### Please describe the feature you'd like to see added.

# Hardforking Bitcoin to SLH-DSA

Bitcoin's transition to a post-quantum cryptographic algorithm like SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) would be a significant and complex undertaking. Here's an analysis of the potential process and implications:

## Motivation for the Transition

The primary reason for considering a transition to SLH-DSA would be to protect Bitcoin against potential threats from quantum comp
...

✅ achow101 closed an issue: "HardFork (SLH-DSA)"
(https://github.com/bitcoin/bitcoin/issues/31095)

💬 achow101 commented on issue "HardFork (SLH-DSA)":
(https://github.com/bitcoin/bitcoin/issues/31095#issuecomment-2415316539)
The issue tracker is used to track technical issues related to the Bitcoin Core code base. Network-wide consensus and/or P2P changes first need to be discussed with the greater community, e.g. the `bitcoin-dev` mailing list. Also, they need a BIP to be implemented in Bitcoin Core and other software that connects to the bitcoin P2P network.

💬 apulsifer commented on issue "LevelDB read failure: Corruption: block checksum mismatch":
(https://github.com/bitcoin/bitcoin/issues/30159#issuecomment-2415392949)
I haven't seen any data corruption since Sept 12, so at this point I can't really give you any information to duplicate the problem.

I did note when checking the system logs that I have only ever seen corruption on systems where the bitcoind process is listening on an IPv6 port. I believe all of those machines are also getting incoming peer connection via IPv6, but at minimum, they are either getting incoming connections via IPv6 or making outgoing connections via IPv6, since that is the only
...

💬 hodlinator commented on pull request "Windows bitcoind stall debugging [NOMERGE, DRAFT]":
(https://github.com/bitcoin/bitcoin/pull/30956#issuecomment-2415939359)
We have a winner! https://github.com/hodlinator/bitcoin/actions/runs/11311779692/job/31458399560
Downloaded the artifacts now just to be sure, but I won't be able to look at them until early next week.
Might keep the CI schedule running for one more dump before turning it off unless anyone disagrees.

💬 cdecker commented on pull request "chainparams: Re-add seed.bitcoinstats.com":
(https://github.com/bitcoin/bitcoin/pull/31086#issuecomment-2415961306)
> No IPv6 support?

I might add ipv6 support, but still fighting with my cloud provider about that.

💬 cdecker commented on pull request "chainparams: Re-add seed.bitcoinstats.com":
(https://github.com/bitcoin/bitcoin/pull/31086#issuecomment-2415961904)
> It currently doesn't give me any results for `x9`, IIRC the most common filter:
> ```
> host x9.seed.bitcoinstats.com.
> ```

Interesting, I'll check why that is.