💬 marcofleon commented on pull request "policy: ephemeral dust followups":
(https://github.com/bitcoin/bitcoin/pull/31279#discussion_r1840960818)
It's this commit here that's causing the errors. Seems that this was actually needed.

💬 fanquake commented on pull request "guix: remove `util-linux`":
(https://github.com/bitcoin/bitcoin/pull/31285#issuecomment-2474401790)
> Does this make a difference to the build env?

Yea, it's pruning out`util-linux`. See here for a diff of `/bin` of the profile of master vs this PR: https://gist.github.com/fanquake/2785035aeab228a1d6046dbbdd55f299, for `x86_64-linux-gnu`.

💬 sdaftuar commented on pull request "cluster mempool: Implement changeset interface for mempool":
(https://github.com/bitcoin/bitcoin/pull/31122#issuecomment-2474424857)
Just rebased this on master -- @0xB10C thanks for the note on the tracepoint change. @instagibbs I think I could rewrite the `CheckEphemeralSpends()` code to take advantage of the changesets for package validation (since we will now be maintaining a map of package transactions that we can query), but maybe that can be done in a separate PR? Just left that code as-is for now.

💬 laanwj commented on pull request "guix: remove `util-linux`":
(https://github.com/bitcoin/bitcoin/pull/31285#issuecomment-2474441538)
Nice!

Of those, `hexdump` was required with the autotools build system. Not sure about others.

💬 sr-gi commented on pull request "p2p: Fill reconciliation sets (Erlay) attempt 2":
(https://github.com/bitcoin/bitcoin/pull/30116#discussion_r1841026397)
Sure, looks like tests can be rewritten for it not to be needed. Will address in the next push

💬 polespinasa commented on pull request "Wallet: "listreceivedby*" fix":
(https://github.com/bitcoin/bitcoin/pull/30972#issuecomment-2474535023)
Lgtm
Tested ack

I ran the unit test and functional test (without bdb) and all pass.
Also tested manually using regtest the steps in function ``test_listreceivedby`` and the behaviour is the expected.

👍 instagibbs approved a pull request: "cluster mempool: Implement changeset interface for mempool"
(https://github.com/bitcoin/bitcoin/pull/31122#pullrequestreview-2434231838)
ACK 5736d1ddacc4019101e7a5170dd25efbc63b622a

Picks up TRACEPOINT and ephemeral dust stuff.

via `git range-diff master 0ca1e05d8bcbc42892156c15f128a5f829e9e48e 5736d1ddacc4019101e7a5170dd25efbc63b622a`

💬 instagibbs commented on pull request "policy: ephemeral dust followups":
(https://github.com/bitcoin/bitcoin/pull/31279#discussion_r1841060999)
specifically needs the `SyncWithValidationInterfaceQueue`, not the unused part.

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