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

💬 sandakersmann commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1657219473)
First-seen-safe is good enough for grocery shopping. But don't let me disturb you while you strip away the utility of BTC.

📝 hebasto opened a pull request: "ci: Run "macOS native x86_64" job on GitHub Actions"
(https://github.com/bitcoin/bitcoin/pull/28187)
From https://github.com/bitcoin/bitcoin/issues/28098:
> Thus, someone would have to sponsor an amount of roughly 5kUSD/mo for those two tasks.

> If the goal is to stay on a free plan, I think the only option is GitHub Actions CI.

Historical context:
- https://github.com/bitcoin/bitcoin/pull/17697
- https://github.com/bitcoin/bitcoin/issues/17803
- https://github.com/bitcoin/bitcoin/pull/18031

Security concerns:
- https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-16514321
...

💬 hebasto commented on issue "ci: Future of macOS and Windows MSVC CI tasks":
(https://github.com/bitcoin/bitcoin/issues/28098#issuecomment-1657245667)
Two PRs are aiming to address this issue:
- #28173
- #28187

💬 fanquake commented on pull request "ci: Run "macOS native x86_64" job on GitHub Actions":
(https://github.com/bitcoin/bitcoin/pull/28187#issuecomment-1657246934)
This is replacing the arm64 job with an x86_64 job?

💬 hebasto commented on pull request "ci: Run "macOS native x86_64" job on GitHub Actions":
(https://github.com/bitcoin/bitcoin/pull/28187#issuecomment-1657247268)
> This is replacing the arm64 job with an x86_64 job?

Yes. No `arm64` macOS images are available in GitHub Actions for now.

💬 fanquake commented on pull request "ci: Run "macOS native x86_64" job on GitHub Actions":
(https://github.com/bitcoin/bitcoin/pull/28187#issuecomment-1657248139)
The PR description should probably mention that, as it's a regression in terms of testing. i.e no-longer testing on Apples primarily supported hardware.

💬 hebasto commented on pull request "ci: Run "macOS native x86_64" job on GitHub Actions":
(https://github.com/bitcoin/bitcoin/pull/28187#issuecomment-1657249053)
> The PR description should probably mention that, as it's a regression in terms of testing. i.e no-longer testing on Apples primarily supported hardware.

Done.