💬 MarcoFalke commented on pull request "test: Add unit & functional test coverage for blockstore":
(https://github.com/bitcoin/bitcoin/pull/27850#issuecomment-1657098924)
(Feel free to push the `chattr` changes here in the meantime. Obviously the CI won't pass, but people can start initial review)

💬 hebasto commented on pull request "qa, doc: Fix comment":
(https://github.com/bitcoin/bitcoin/pull/28181#discussion_r1278543285)
Done.

🚀 fanquake merged a pull request: "test: Add SyncWithValidationInterfaceQueue to mockscheduler RPC"
(https://github.com/bitcoin/bitcoin/pull/28118)

💬 ekzyis commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1657103010)
Concept ACK

💬 ekzyis commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1657103483)
Concept ACK

Enabling full-RBF by default removes remaining false sense of security

📝 MarcoFalke converted_to_draft a pull request: "ci: Use hard-coded root path for CI containers (bugfix)"
(https://github.com/bitcoin/bitcoin/pull/28185)
Currently the CI system will fail if the git folder that holds the Bitcoin Core source is moved from one location to another.

Fix this by using a single hard-coded root path *inside* the CI system containers.

Steps to test:

* Run the CI system: `MAKEJOBS="-j$(nproc)" FILE_ENV="./ci/test/00_setup_env_win64.sh" ./ci/test_run_all.sh`
* Move the git folder: `pwd && cd .. && mv bitcoin_core_folder_1 bitcoin_core_folder_2 && cd ./bitcoin_core_folder_2 && pwd`
* Run the CI system again: (sam
...

💬 ekzyis commented on pull request "Remove -mempoolfullrbf option":
(https://github.com/bitcoin/bitcoin/pull/26525#issuecomment-1657107679)
@BitcoinErrorLog I am wondering how this change which takes away an option from node operators is compatible with the slogan "Digital freedom starts with you" on https://synonym.to/ which seems to be a company you are the CEO of?

Is this change not infringing the digital freedom of node operators by making it harder to enable full-RBF on their nodes?

💬 RandyMcMillan commented on pull request "qa, doc: Fix comment":
(https://github.com/bitcoin/bitcoin/pull/28181#issuecomment-1657107808)
ACK ab498d913c6f9f6096c75cc43a91e7a12cfc3fb7

💬 dergoegge commented on pull request "fuzz: Test headers pre-sync through p2p interface":
(https://github.com/bitcoin/bitcoin/pull/28043#discussion_r1278551101)
it's not, iirc I had some trouble with thread safety annotations but I'll give `CallOneOf` another try

💬 Ayms commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1657116843)
As different people explained this change is really needed and really necessary for the future of bitcoin
Remember that some nacking this did store in addresses
It s too easy to store anywhere you want and even more easy if you collude with a miner
Regarding the 80 B number I don t understand where it comes from you can t even store a signature and a hash with this

I am on mobile too so sorry for the typos strange to see how shxtty is github on mobile

💬 sipa commented on pull request "BIP324 ciphersuite":
(https://github.com/bitcoin/bitcoin/pull/28008#discussion_r1278562569)
That very much sounds like it could have been my intent, but I honestly can't remember. I'll make this change if I retouch.

💬 petertodd commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1657177700)
@sandakersmann

> @petertodd Why didn't any hash power opt-in to RBF before you made that patch?

Someone had to actually write the code of course. AFAIK I was the first (though as far as I know, rbf was [first suggested by Satoshi](https://bitcointalk.org/index.php?topic=2181.msg28739#msg28739)).

💬 SparK-Cruz commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1657183466)
The fact RBF is possible already undermines the security of the mempool, which was already low, so having it on by default or not, the fact it exists already killed zero-conf a long time ago.

👋 hebasto's pull request is ready for review: "ci: Run Windows native task on GitHub Actions"
(https://github.com/bitcoin/bitcoin/pull/28173)

💬 hebasto commented on pull request "ci: Run Windows native task on GitHub Actions":
(https://github.com/bitcoin/bitcoin/pull/28173#issuecomment-1657189554)
> In the meantime it may be good to do 10 runs and then check how many of them fail

10 runs are green for the recent commit:
- https://github.com/hebasto/bitcoin/actions/runs/5701707622/attempts/1
- https://github.com/hebasto/bitcoin/actions/runs/5701707622/attempts/2
- https://github.com/hebasto/bitcoin/actions/runs/5701707622/attempts/3
- https://github.com/hebasto/bitcoin/actions/runs/5701707622/attempts/4
- https://github.com/hebasto/bitcoin/actions/runs/5701707622/attempts/5
- http
...

📝 TheCharlatan opened a pull request: "kernel: Prune leveldb headers"
(https://github.com/bitcoin/bitcoin/pull/28186)
Leveldb headers are currently included in the `dbwrapper.h` file and thus available to many of Bitcoin Core's source files. However, leveldb-specific functionality should be abstracted by the `dbwrapper` and does not need to be available to the rest of the code. Having leveldb included in a widely-used header such as `dbwrapper.h` bloats the entire project's header tree.

The `dbwrapper` is a key component of the libbitcoinkernel library. Future users of this library would not want to contend
...

✅ Crypt-iQ closed an issue: "depends build fails macOS intel"
(https://github.com/bitcoin/bitcoin/issues/27977)

💬 petertodd commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1657206487)
@ariard

> So I’m Concept ACK on this change, I still think this change deserves announcement on the mailing list and usual technical communication channels to warn ecosystem stakeholders impacted by the proposed change.

I've posted a notice on the bitcoin-dev mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-July/021823.html

Thanks for the Concept ACK!

💬 petertodd commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1657208422)
> @ChristopherA wrote:
>
> > In my own case, current op_return limits keep me from posting a signed hash plus some metadata (<256 bytes) and thus I must use Taproot tricks instead.
>
> @petertodd wrote:
>
> > Large amounts of data are already published in the bitcoin blockchain in a variety of ways.
>
> This seems like something to propose on the bitcoin-dev mailinglist, like it was [ten years ago](https://blog.bitmex.com/dapps-or-only-bitcoin-transactions-the-2014-debate/). You coul
...

💬 amitiuttarwar commented on pull request "p2p: Diversify automatic outbound connections with respect to networks":
(https://github.com/bitcoin/bitcoin/pull/27213#discussion_r1278586562)
I don't quite follow. if we have multiple networks that match, the randomization seems valuable in all the cases?