💬 Sjors commented on pull request "Add waitNext() to BlockTemplate interface":
(https://github.com/bitcoin/bitcoin/pull/31283#issuecomment-2474606749)
I pushed a commit refactoring `miner_tests` to use the `Mining` interface. I plan to expand those tests to cover `waitNext()`.

💬 Sjors commented on pull request "Add waitNext() to BlockTemplate interface":
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1841070497)
a316ba58cba5df8aadb05737959b97eeb6a350b4: I think dropping this doesn't matter?

💬 Sjors commented on pull request "Add waitNext() to BlockTemplate interface":
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1841075744)
a316ba58cba5df8aadb05737959b97eeb6a350b4: I'm tempted to use `miner.submitSolution()` here.

💬 Sjors commented on issue "Bitcoin Core "not opened" after software update to macOS Sequoia 15.0.1 (24A348)":
(https://github.com/bitcoin/bitcoin/issues/31069#issuecomment-2474702003)
@sipa afaik self-signing should only be needed for the tar download, which has bitcoind, bitcoin-qt, etc. It should not be needed for the main zip release. I'm also unable to start the downloaded version on my new M4 mac. Looks like #15774 got a lot worse as of macOS 15.1.

The way to work around it now is to go to Security Settings. It will show you Bitcoin Core was blocked from starting, and you can click Open Anyway. This really requires being careful about how you go the binary obviously.

💬 Sjors commented on issue "macOS App Notarization & Stapling":
(https://github.com/bitcoin/bitcoin/issues/15774#issuecomment-2474704643)
Ah great, anyone macOS release, another pain increase.

I'm also unable to start the downloaded version on my new M4 mac running macOS 15.1.

The option-click workaround no longer works. The new way is just open it, dismiss the error. Then go to Security Settings. It will show you Bitcoin Core was blocked from starting, and you can click Open Anyway.

⚠️ Sjors opened an issue: "v27 node thinks my v28 / master block database is corrupted"
(https://github.com/bitcoin/bitcoin/issues/31286)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

I'm unable to start Bitcoin Core v27.1 or v27.2 (haven't tried older) on my newly installed node. The node works with v28.0 and on recent master (2b33322169bc).

I never set `-blocksxor`.

I did use assume utxo during the initial sync. I haven't tried (yet) to sync again and see if that matters.

The initial sync was done on master, I haven't tried doing the sync with the release ins
...

💬 Sjors commented on issue "v27 node thinks my v28 / master block database is corrupted":
(https://github.com/bitcoin/bitcoin/issues/31286#issuecomment-2474736673)
Although I did not use `-blocksxor` there is a `xor.dat` file in my blocks dir.

Here's the block, undo and xor file: https://download.sprovoost.nl/download.php?id=10&token=34c0e1dcec8e6d096c2f25ebfe8f59f2

💬 maflcko commented on issue "v27 node thinks my v28 / master block database is corrupted":
(https://github.com/bitcoin/bitcoin/issues/31286#issuecomment-2474746949)
> Although I did not use `-blocksxor` there is a `xor.dat` file in my blocks dir.

This is expected. You can print the help (and the default values) of args with the `-help` arg.

💬 maflcko commented on issue "v27 node thinks my v28 / master block database is corrupted":
(https://github.com/bitcoin/bitcoin/issues/31286#issuecomment-2474750672)
I can see the point of delaying the default value by one release, but creating a blocksdir with the most recent release, only to downgrade seems an edge case.

💬 Sjors commented on issue "v27 node thinks my v28 / master block database is corrupted":
(https://github.com/bitcoin/bitcoin/issues/31286#issuecomment-2474753134)
Too late now, but I think the release notes should have made it more clear that you can't downgrade.

https://bitcoincore.org/en/releases/28.0/

Burried under "Low-level Changes":

> Blockstorage

> Block files are now XOR’d by default with a key stored in the blocksdir. Previous releases of Bitcoin Core or previous external software will not be able to read the blocksdir with a non-zero XOR-key.

✅ Sjors closed an issue: "v27 node thinks my v28 / master block database is corrupted"
(https://github.com/bitcoin/bitcoin/issues/31286)

💬 Sjors commented on issue "v27 node thinks my v28 / master block database is corrupted":
(https://github.com/bitcoin/bitcoin/issues/31286#issuecomment-2474756367)
Oh never mind, that's only "for a freshly initialized blocksdir". That seems reasonable.

💬 sr-gi commented on pull request "p2p: Fill reconciliation sets (Erlay) attempt 2":
(https://github.com/bitcoin/bitcoin/pull/30116#discussion_r1841164936)
`2==true` would mean that we had the transaction in both places, which should never happen (I'd mean that a transaction is both ready and delayed at the same time).

If that were to happen in production for whatever reason, this would return false with the suggested changes, which may break something?

💬 sr-gi commented on pull request "p2p: Fill reconciliation sets (Erlay) attempt 2":
(https://github.com/bitcoin/bitcoin/pull/30116#discussion_r1841223757)
In that case, no transaction would be moved from the reconciliation set to `invs_to_send`, given no transaction would be removed:

```cpp
auto it = std::find(fanout_with_ancestors.begin(), fanout_with_ancestors.end(), peer_id);
if (it != fanout_with_ancestors.end()) {
for (const auto wtxid: parents) {
m_txreconciliation->TryRemovingFromSet(peer_id, wtxid);
invs_to_send.push_back(wtxid);
}
} else {
// If the peer is registered for set reconciliation, maybe pi
...

💬 sr-gi commented on pull request "p2p: Fill reconciliation sets (Erlay) attempt 2":
(https://github.com/bitcoin/bitcoin/pull/30116#discussion_r1841243963)
Done

💬 sr-gi commented on pull request "p2p: Fill reconciliation sets (Erlay) attempt 2":
(https://github.com/bitcoin/bitcoin/pull/30116#discussion_r1841245788)
Done

💬 sr-gi commented on pull request "p2p: Fill reconciliation sets (Erlay) attempt 2":
(https://github.com/bitcoin/bitcoin/pull/30116#discussion_r1841245945)
Done

👍 hodlinator approved a pull request: "tinyformat: Add compile-time checking for literal format strings"
(https://github.com/bitcoin/bitcoin/pull/31174#pullrequestreview-2434652082)
re-ACK fe39acf88ff552bfc4a502c99774375b91824bb1

`git range-diff master ecc5cb9 fe39acf`

- Added more `FailFmtWithError`-tests ([maflcko](https://github.com/bitcoin/bitcoin/pull/31174#pullrequestreview-2423906139)).
- Terser skipping of `%%` ([l0rinc](https://github.com/bitcoin/bitcoin/pull/31174#discussion_r1835770569)).
- Comment regarding format string components updated ([me](https://github.com/bitcoin/bitcoin/pull/31174#discussion_r1834472950)).

💬 hodlinator commented on pull request "Ephemeral Dust":
(https://github.com/bitcoin/bitcoin/pull/30239#discussion_r1841318869)
Thanks for clarifying when modified fees are ignored.

> We're assuming node operators/miners care about dust. If they do not, they can already set their dust relay rate to 0 and avoid all of these mechanisms entirely, ephemeral dust becomes a no-op. (e.g., MARA reportedly doesn't enforce dust limits and runs an accelerator already)
>
> If we end up being wrong and miners are ok putting one dust output in the utxo set but not multiple or whatever, we can revisit?

My assumption would be th
...

💬 achow101 commented on pull request "bench: add support for custom data directory":
(https://github.com/bitcoin/bitcoin/pull/31000#issuecomment-2475050409)
ACK fa66e0887ca1a1445d8b18ba1fadb12b2d911048