Bitcoin Core Github
44 subscribers
122K links
Download Telegram
💬 MarcoFalke commented on pull request "fuzz: a target for the block index database":
(https://github.com/bitcoin/bitcoin/pull/28209#discussion_r1283056551)
nit: remove newline?
💬 ajtowns commented on pull request "p2p: Drop m_recently_announced_invs bloom filter":
(https://github.com/bitcoin/bitcoin/pull/27675#issuecomment-1663824558)
Update for glozow's review; fixes off-by-one error and adds some glozow's test coverage of reorg behaviour
💬 darosior commented on pull request "fuzz: a target for the block index database":
(https://github.com/bitcoin/bitcoin/pull/28209#discussion_r1283080177)
Sure
💬 darosior commented on pull request "fuzz: a target for the block index database":
(https://github.com/bitcoin/bitcoin/pull/28209#discussion_r1283080569)
Oh, i forgot to push my last change, this include shouldn't be here (that's why i had separated it).
💬 stickies-v commented on pull request "kernel: Prune leveldb headers":
(https://github.com/bitcoin/bitcoin/pull/28186#discussion_r1283080816)
Good point. Okay, let's mark as resolved.
💬 petertodd commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1663835792)
> Even assuming pinning was an issue, it wouldn't be a blocker. It could simply be released at the same time as some other policy change (package relay, #27677, v3 transactions, the next soft fork, etc). Or even just with sufficient heads-up.

I've sent an email to the bitcoin-dev mailing list announcing this proposed change: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-August/021840.html
💬 petertodd commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1663840167)
> Enacting this change of policy would be reason enough for me to stop updating Bitcoin Core forever. If anything node runners are asking for ways to filter the recent tidal wave of spam while it is still unconfirmed, not surrender to it.

FYI if merged, this pull-req would allow you to continue to limit or block data-carrying OP_Return outputs by setting `-datacarriersize=n` or `-datacarriersize=0` respectively. Of course, if a non-trivial minority of nodes and miners choose to relay and mine
...
💬 hebasto commented on pull request "refactor: Remove unused includes from wallet.cpp":
(https://github.com/bitcoin/bitcoin/pull/28200#discussion_r1283086785)
> I think this bug should be reported to IWYU...

https://github.com/include-what-you-use/include-what-you-use/issues/1280
💬 darosior commented on pull request "fuzz: a target for the block index database":
(https://github.com/bitcoin/bitcoin/pull/28209#issuecomment-1663841536)
Thanks, addressed your comments.
💬 dergoegge commented on pull request "fuzz: a target for the block index database":
(https://github.com/bitcoin/bitcoin/pull/28209#issuecomment-1663851387)
Concept ACK
💬 MarcoFalke commented on pull request "refactor: serialization simplifications":
(https://github.com/bitcoin/bitcoin/pull/28203#issuecomment-1663857107)
only change is to add a missing `&`. lgtm, re-ACK f054bd072afb72d8dae7adc521ce15c13b236700 📦

<details><summary>Show signature</summary>

Signature:

```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
t
...
💬 petertodd commented on pull request "policy: Enable full-rbf by default":
(https://github.com/bitcoin/bitcoin/pull/28132#discussion_r1283105646)
Thanks! Good idea; fixed.
💬 RobinLinus commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1663887625)
Concept NACK

This will most likely increase the spam problems significantly.
📝 MarcoFalke opened a pull request: "build: Bump minimum supported Clang to clang-13"
(https://github.com/bitcoin/bitcoin/pull/28210)
All supported operating systems ship with clang-13 (or later), so bump the minimum to that and remove now unused workarounds for previous clang bugs.

For reference:
* https://packages.debian.org/bullseye/clang-13
* https://packages.ubuntu.com/jammy/clang (`clang-14`) and https://packages.ubuntu.com/jammy/clang-15
* CentOS 8 Stream: All Clang versions from 11.0 to 15.0

This is for Bitcoin Core 27.0 in 2024 (next year), not the soon upcoming 26.0 next month.
💬 MarcoFalke commented on pull request "build: Bump minimum supported Clang to clang-13":
(https://github.com/bitcoin/bitcoin/pull/28210#issuecomment-1663903532)
(Draft for now because CI will likely fail)
📝 MarcoFalke opened a pull request: "Bump python minimum version to 3.9"
(https://github.com/bitcoin/bitcoin/pull/28211)
All supported operating systems ship with python 3.9 (or later), so bumping the minimum should not cause any issues. A bump will allow new code to use new python 3.9 features.

For reference:
* https://packages.debian.org/bullseye/python3
* https://packages.ubuntu.com/focal/python3.9
* CentOS Stream also ships with 3.9

This is for Bitcoin Core 27.0 in 2024 (next year), not the soon upcoming 26.0 next month.
💬 MarcoFalke commented on pull request "Bump python minimum version to 3.9":
(https://github.com/bitcoin/bitcoin/pull/28211#issuecomment-1663927124)
Currently a draft to see the CI result
💬 petertodd commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#issuecomment-1663927559)
> Concept NACK
>
> This will most likely increase the spam problems significantly.

Since OP_Return outputs to not benefit from the segwit discount, publishing data via them is about 4x more expensive than publishing data in witness space. Eg via the taproot mechanism used by inscriptions.

Why do you believe that expanding a publication mechanism that is 4x more expensive than the heavily used taproot witness mechanism will "increase the spam problems significantly"?
💬 MarcoFalke commented on pull request "Remove arbitrary restrictions on OP_RETURN by default":
(https://github.com/bitcoin/bitcoin/pull/28130#discussion_r1283165130)
Any reason to remove this option? Seems fine to keep it as an alias to completely disable any OP_RETURN. I know it may be redundant with the other option, but for some reason most other devs and users like the UX of it, similar to `-regtest` and `-chain=regtest`, or other options.
💬 TheCharlatan commented on pull request "kernel: Prune leveldb headers":
(https://github.com/bitcoin/bitcoin/pull/28186#issuecomment-1663941035)
Thank you for the re-review @MarcoFalke,

Updated 8c4481ed3713931247e4cedcb5733d3598050eb7 -> 8c4481ed3713931247e4cedcb5733d3598050eb7 ([cleaveLeveldbHeaders_2](https://github.com/TheCharlatan/bitcoin/tree/cleaveLeveldbHeaders_2) -> [cleaveLeveldbHeaders_3](https://github.com/TheCharlatan/bitcoin/tree/cleaveLeveldbHeaders_3), [compare](https://github.com/TheCharlatan/bitcoin/compare/cleaveLeveldbHeaders_2..cleaveLeveldbHeaders_3))
* Addressed @MarcoFalke's [comment](https://github.com/bitcoi
...