Bitcoin Core Github
43 subscribers
122K links
Download Telegram
💬 achow101 commented on pull request "descriptors: MuSig2":
(https://github.com/bitcoin/bitcoin/pull/31244#discussion_r2093554764)
Done
💬 achow101 commented on pull request "descriptors: MuSig2":
(https://github.com/bitcoin/bitcoin/pull/31244#discussion_r2093554945)
"is"
💬 achow101 commented on pull request "descriptors: MuSig2":
(https://github.com/bitcoin/bitcoin/pull/31244#discussion_r2093555270)
Added comments.
💬 achow101 commented on pull request "descriptors: MuSig2":
(https://github.com/bitcoin/bitcoin/pull/31244#discussion_r2093555374)
Done
💬 achow101 commented on pull request "descriptors: MuSig2":
(https://github.com/bitcoin/bitcoin/pull/31244#discussion_r2093555457)
any that we have.
💬 maflcko commented on pull request "node: cap `-maxmempool` and `-dbcache` values for 32-bit":
(https://github.com/bitcoin/bitcoin/pull/32530#issuecomment-2887503071)
No objection, but there is no hand-holding on 64-bit systems regarding OOM footguns, so doing it on 32-bit systems (the edge case ) seems fine, but a bit unexpected, given that OOM reports are generally on 64-bit systems? Again, no objection, just wondering if there is more background to it.
furszy closed a pull request: "restrict std::cerr to errors; use std::cout for warnings and info"
(https://github.com/bitcoin/bitcoin/pull/32538)
💬 furszy commented on pull request "restrict std::cerr to errors; use std::cout for warnings and info":
(https://github.com/bitcoin/bitcoin/pull/32538#issuecomment-2887513237)
> When something literally starts with Warning: ..., I fail to see how it can be misinterpreted.

It is actually being misinterpreted by our own test framework. The framework does not look
at the stderr content, it only checks whether there is something inside stderr or not during
shutdown, failing when finds something there.

> This change means that warnings may be missed in tests/CI or elsewhere (see the failing CI).

That's ok. That's what the PR is proposing. To redirect them to std
...
💬 furszy commented on pull request "wallet: init, don't error out when loading legacy wallets":
(https://github.com/bitcoin/bitcoin/pull/32449#discussion_r2093584558)
> why the `.rpc.`?

because my subconscious still thinks about the legacy wallet proxy methods and we don't have them anymore.
💬 furszy commented on pull request "wallet: init, don't error out when loading legacy wallets":
(https://github.com/bitcoin/bitcoin/pull/32449#discussion_r2093585184)
removed.
📝 pinheadmz opened a pull request: "init: Configure reachable networks before we start the RPC server"
(https://github.com/bitcoin/bitcoin/pull/32539)
Closes https://github.com/bitcoin/bitcoin/issues/32433

`MaybeFlipIPv6toCJDNS()` relies on `g_reachable_nets` to distinguish between CJDNS addresses and other IPv6 addresses. In particular, [RFC4193](https://www.rfc-editor.org/rfc/rfc4193#section-3.1) address or "Unique Local Address" with the L-bit unset also begins with the `fc` prefix. #32433 highlights a use case for these addresses that have nothing to do with CJDNS.

On master we don't parse init flags like `-cjdnsreachable` until *aft
...
💬 pinheadmz commented on issue ""rpcallowip=" configuration directive doesn't accept RFC4193 addresses":
(https://github.com/bitcoin/bitcoin/issues/32433#issuecomment-2887572908)
https://github.com/bitcoin/bitcoin/pull/32539
💬 BitcoinMechanic commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2887596317)
It seems if you want people to actually use this much OP RETURN data by relaxing the filter it'd make sense to simultaneously prevent "inscriptions" with this https://github.com/bitcoin/bitcoin/pull/28408
💬 achow101 commented on pull request "qt: drop unused watch-only functionality":
(https://github.com/bitcoin/bitcoin/pull/32459#issuecomment-2887600076)
ACK 0fc9bf05c36169ff746df10c5c8310f5adf2e202

There does not appear to be any visual differences, nor any remaining references to watch-only/watchonly in the GUI.
💬 achow101 commented on pull request "refactor: bdb removals":
(https://github.com/bitcoin/bitcoin/pull/32511#issuecomment-2887602257)
ACK fafee85358397289aa4c6b799d2603a5d89e83a2
💬 theuni commented on pull request "(RFC) kernel: Replace leveldb-based BlockTreeDB with flat-file based store":
(https://github.com/bitcoin/bitcoin/pull/32427#issuecomment-2887607766)
> > My bikeshed color: Since block hashes start with zeroes, maybe one could shard based off the last two bytes:
>
> Just curious because the FAT32 file limit per-directory is so small, is there any scenario where a miner could DoS nodes with this format by also mining the last two bytes?
>
> I think no, because at tip the additional hash needed for two bytes would be prohibitively expensive, although I'm not sure if there is a birthday-problem-like advantage because an attacker doesn't ne
...
🚀 achow101 merged a pull request: "refactor: bdb removals"
(https://github.com/bitcoin/bitcoin/pull/32511)
Pttn closed an issue: "Inconsistent Descriptor Space Parsing"
(https://github.com/bitcoin/bitcoin/issues/28943)
💬 Pttn commented on issue "Inconsistent Descriptor Space Parsing":
(https://github.com/bitcoin/bitcoin/issues/28943#issuecomment-2887649561)
Fixed by #31603 I think.