Bitcoin Core Github
43 subscribers
123K links
Download Telegram
💬 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.
💬 achow101 commented on pull request "wallet: init, don't error out when loading legacy wallets":
(https://github.com/bitcoin/bitcoin/pull/32449#discussion_r2093740236)
In 86e1111239cdb39dd32cfb5178653c608fa30515 "test: verify node skips loading legacy wallets during startup"

Is there a reason to use settings.json instead of passing in `-wallet=legacy_up...` as part of `extra_args` during the restart?
💬 TEU7ZoTHLa7sZchXmdqZn5pE75ikooVNfv commented on pull request "wallet: init, don't error out when loading legacy wallets":
(https://github.com/bitcoin/bitcoin/pull/32449#issuecomment-2887797539)
‏alvandisaeed43@gmail.com‏
💬 murchandamus commented on pull request "wallet: Keep track of the wallet's own transaction outputs in memory":
(https://github.com/bitcoin/bitcoin/pull/27286#issuecomment-2887797583)
reACK https://github.com/bitcoin/bitcoin/pull/27286/commits/29cf059e6e592f7f82b982493a043219cdfa5b40

via git range-diff efac285a0d709f48856c37b15bfa09af94c1d75b..51d4846f648e79e3e098f1f1bea7d5e823ebdea8 b15c386933eb7bc5ed8644dd37f8169d81ea5a22..29cf059e6e592f7f82b982493a043219cdfa5b40

Hooray for `Txid` class!
💬 furszy commented on pull request "wallet: init, don't error out when loading legacy wallets":
(https://github.com/bitcoin/bitcoin/pull/32449#discussion_r2093771082)
> Is there a reason to use settings.json instead of passing in `-wallet=legacy_up...` as part of `extra_args` during the restart?

I just wanted to make the test case as realistic as possible (an existing legacy wallet with `load_on_startup=true`). But there shouldn't be any difference.
🤔 fjahr reviewed a pull request: "refactor: Improve assumeutxo state representation"
(https://github.com/bitcoin/bitcoin/pull/30214#pullrequestreview-2846790348)
Leaving some comments in case you want to address some of them with the rebase. I am mostly happy but there are a few things that I need to spend some more time on.