Bitcoin Core Github
42 subscribers
125K links
Download Telegram
💬 ajtowns commented on pull request "doc: Drop description of LogError messages as fatal":
(https://github.com/bitcoin/bitcoin/pull/30361#issuecomment-2312004308)
> I don't think anybody (even the original author) currently thinks this advice is something we should try to implement anymore.

Presuming that if it's me who's he-who-must-not-be-named here rather than referring back to #24464 etc, what I think is that if we're going to have distinct log levels for "error" and "warning", I think there should be a clear documented difference between what they are, so that PR authors, reviewers and users can know what to expect. If there's places in our code t
...
💬 maflcko commented on pull request "refactor: Testnet4 - Replace uint256S("str") -> uint256{"str"}":
(https://github.com/bitcoin/bitcoin/pull/30721#issuecomment-2312030309)
review-ACK 49f9b645ea3f42c1b9e0a83b26af8fc8f6fa159d 🐮

<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=
trusted comment: review-ACK 49f9b645ea3f
...
💬 hodlinator commented on issue "ci: ConnectionRefusedError: [WinError 10061] No connection could be made because the target machine actively refused it":
(https://github.com/bitcoin/bitcoin/issues/30390#issuecomment-2312067244)
> > This could potentially be an issue between two different tests as well, if they shut down/start up quickly enough to still be within the TCP `TIME_WAIT` period.
>
> I don't think different tests affect each other, because the test_runner assigns non-overlapping spans of ports for each test case (rpc, p2p, ...).

Yes, different tests would get different PIDs, which feed into `p2p_port` etc, so port collisions between tests should not happen *unless PIDs are reused within a too short time
...
💬 hodlinator commented on issue "ci: ConnectionRefusedError: [WinError 10061] No connection could be made because the target machine actively refused it":
(https://github.com/bitcoin/bitcoin/issues/30390#issuecomment-2312110573)
Read through the docs on [Python Popen](https://docs.python.org/3/library/subprocess.html#subprocess.Popen) and didn't find anything suspicious. Would assume that `Popen` would raise an exception immediately if it fails to start `bitcoind`. Seems more likely that `bitcoind` has gone into an infinite loop/blocked for some reason early during startup.

Might be helpful if we could log the callstack(s) from the `bitcoind` process when hitting the 2400s timeout.
💬 hebasto commented on issue "ci: ConnectionRefusedError: [WinError 10061] No connection could be made because the target machine actively refused it":
(https://github.com/bitcoin/bitcoin/issues/30390#issuecomment-2312121052)
Also https://github.com/bitcoin/bitcoin/pull/28509.
📝 fanquake opened a pull request: "[26.x] Fix compilation with GCC 15"
(https://github.com/bitcoin/bitcoin/pull/30722)
Backports #30633 to the `26.x` branch, so that it can be compiled with GCC 15.
fanquake closed an issue: "Intermittent timeout on p2p_ibd_stalling.py"
(https://github.com/bitcoin/bitcoin/issues/30704)
🚀 fanquake merged a pull request: "test: Avoid intermittent block download timeout in p2p_ibd_stalling"
(https://github.com/bitcoin/bitcoin/pull/30705)
💬 fjahr commented on pull request "refactor: Testnet4 - Replace uint256S("str") -> uint256{"str"}":
(https://github.com/bitcoin/bitcoin/pull/30721#issuecomment-2312141409)
ACK 49f9b645ea3f42c1b9e0a83b26af8fc8f6fa159d

For the future: you could have made the commit here an actual scripted diff too.
💬 fjahr commented on pull request "seeds: Pull additional nodes from my seeder and update fixed seeds":
(https://github.com/bitcoin/bitcoin/pull/30008#issuecomment-2312168836)
> it accidentally removes all hardcoded onion and i2p seeds

Wasn't that the plan? From the description:

> My seeder additionally crawls onion v3, i2p, and cjdns, so will now be able to set those fixed seeds automatically rather than curating manual lists.
💬 virtu commented on pull request "seeds: Pull additional nodes from my seeder and update fixed seeds":
(https://github.com/bitcoin/bitcoin/pull/30008#issuecomment-2312182332)
> > it accidentally removes all hardcoded onion and i2p seeds
>
> Wasn't that the plan? From the description:
>
> > My seeder additionally crawls onion v3, i2p, and cjdns, so will now be able to set those fixed seeds automatically rather than curating manual lists.

Removing manually curated Onion and I2P addresses from `nodes_main_manual.txt`, yes.

No Onion and I2P seeds hardcoded into the binary (via `src/chainparamsseeds.h`), an accident I believe.
👍 BrandonOdiwuor approved a pull request: "chainparams: Remove seed.bitcoinstats.com"
(https://github.com/bitcoin/bitcoin/pull/30720#pullrequestreview-2262943902)
ACK c88a7dc53e3be7489605c3326cf768df5437393a
💬 fanquake commented on pull request "chainparams: Remove seed.bitcoinstats.com":
(https://github.com/bitcoin/bitcoin/pull/30720#issuecomment-2312208366)
> I'm in the process of fixing the seeder. It should be back online by the end of the week, if that's acceptable

No worries. We can revert this once it's back up, and we can see it working correctly.
fanquake closed an issue: "DNS seed "seed.bitcoinstats.com" doesn't support filtering while the comments says it does"
(https://github.com/bitcoin/bitcoin/issues/29911)
🚀 fanquake merged a pull request: "chainparams: Remove seed.bitcoinstats.com"
(https://github.com/bitcoin/bitcoin/pull/30720)
💬 0xB10C commented on issue "b-msghand[4988] general protection fault":
(https://github.com/bitcoin/bitcoin/issues/30706#issuecomment-2312264308)
Thank you for reporting this.

While issues in `b-msghand` can be problematic and it's good to report them, I don't think this report contains any actionable details. The gbd backtrace only contains memory addresses and no further debug information.

Unless these you start to see more frequent segmentation faults, I don't think it's worth keeping this issue open.
💬 mzumsande commented on issue "b-msghand[4988] general protection fault":
(https://github.com/bitcoin/bitcoin/issues/30706#issuecomment-2312312701)
Was there anything unusual in the debug log before the crash?
💬 maflcko commented on issue "ci: ConnectionRefusedError: [WinError 10061] No connection could be made because the target machine actively refused it":
(https://github.com/bitcoin/bitcoin/issues/30390#issuecomment-2312318158)
> Also #28509.

Ah nice! I forgot about it. I guess it also underlines that the issue lies in starting the process.

Maybe GHA has some kind of "Anti-Virus" software that may block some processes?

> > > This could potentially be an issue between two different tests as well, if they shut down/start up quickly enough to still be within the TCP `TIME_WAIT` period.
> >
> >
> > I don't think different tests affect each other, because the test_runner assigns non-overlapping spans of ports
...
💬 glozow commented on pull request "refactor: TxDownloadManager + fuzzing":
(https://github.com/bitcoin/bitcoin/pull/30110#discussion_r1732688924)
done
💬 glozow commented on pull request "refactor: TxDownloadManager + fuzzing":
(https://github.com/bitcoin/bitcoin/pull/30110#discussion_r1732689092)
done