Bitcoin Core Github
44 subscribers
119K links
Download Telegram
💬 sstone commented on pull request "Add a "tx output spender" index":
(https://github.com/bitcoin/bitcoin/pull/24539#discussion_r2178244200)
done in https://github.com/bitcoin/bitcoin/pull/24539/commits/d5980f39f934a8e251ddaf6801d23bd5a4bcb3ef. Moving this does not work (maybe a conflict with the mempool lock ?) I'll investigate.
💬 sstone commented on pull request "Add a "tx output spender" index":
(https://github.com/bitcoin/bitcoin/pull/24539#discussion_r2178248747)
Correct but I wanted to have 2 explicit tests: one when a spending tx is replaced, the other when it is cancelled.
💬 sstone commented on pull request "Add a "tx output spender" index":
(https://github.com/bitcoin/bitcoin/pull/24539#discussion_r2178249989)
Sorry I don't understand this ?
💬 sstone commented on pull request "Add a "tx output spender" index":
(https://github.com/bitcoin/bitcoin/pull/24539#issuecomment-3025042997)
> In the pull request description you are saying that the keys are 64 bytes, but I guess you mean 64 bits?
Yes 64 bits.
>
> Did you split this work into two commits to gather feedback on tradeoffs between the two approaches? The space savings and the ability to immediately return a transaction is nice, but it is also not compatible with pruning (and still requires notices about that in init.cpp). Some lightning implementations do support pruned nodes, I guess they won't be able to leverage t
...
💬 sstone commented on pull request "Add a "tx output spender" index":
(https://github.com/bitcoin/bitcoin/pull/24539#discussion_r2178267285)
It may help user figure out they've made a mistake in their setup/configuration ?
💬 sstone commented on pull request "Add a "tx output spender" index":
(https://github.com/bitcoin/bitcoin/pull/24539#discussion_r2178272887)
It did help when the index returned a tx id, it does not anymore.
⚠️ henark opened an issue: "refactor: Standardize logging levels and increase granularity in P2P and mempool modules"
(https://github.com/bitcoin/bitcoin/issues/32851)
Problem: Analysis of developer notes shows five log levels (LogDebug, LogInfo, LogError, LogWarning, LogTrace), but their application can be inconsistent. Critical modules like P2P message handling and mempool acceptance logic lack sufficient LogTrace or fine-grained LogDebug messages, making it difficult to debug complex emergent behaviors like those seen in recent DoS vulnerabilities (CVE-2024-52914, CVE-2024-35202) without attaching a full debugger.

Proposal: Systematically review and refact
...
⚠️ henark opened an issue: "test: Create and maintain a test coverage risk matrix for consensus-critical modules"
(https://github.com/bitcoin/bitcoin/issues/32852)
Problem: While coverage reports exist, there is no formal process for prioritizing test development based on risk. Academic analysis and CVE history show that bugs in high-complexity, consensus-critical code are the most dangerous. A latent bug in a low-coverage area of validation.cpp is far more severe than one in the GUI.

Proposal: Introduce a documented process and associated tooling (e.g., a CI script) that combines code complexity metrics (e.g., cyclomatic complexity) with test coverage da
...
⚠️ henark opened an issue: "p2p: Implement proactive check for stale connections to mitigate eclipse attack vectors"
(https://github.com/bitcoin/bitcoin/issues/32853)
Problem: Eclipse attacks rely on monopolizing a node's connection slots. While Bitcoin Core rotates connections, a sophisticated attacker can attempt to keep connections open but unresponsive, or feed them low-utility data to prevent them from being dropped. The current 90-minute inactivity timeout may be too long.

Proposal: Implement a more proactive health check for peer connections. Beyond the simple ping message, this could involve a challenge-response mechanism that lightly queries the pee
...
⚠️ henark opened an issue: "research: Investigate feasibility of applying formal modeling to critical C++ consensus logic"
(https://github.com/bitcoin/bitcoin/issues/32854)
Problem: There is a significant assurance gap between the formally verified libsecp256k1 library and the unverified C++ code that implements the consensus rules which use it. Academic work has focused on modeling the protocol, not the C++ implementation. This gap is where subtle, critical bugs like CVE-2018-17144 can arise.

Proposal: Initiate a research track to explore the application of formal verification tools for C++ (e.g., Frama-C++, VeriFast, TIS-Analyzer) to a small but critical piece o
...
💬 achow101 commented on pull request "wallet: Remove ISMINE_WATCHONLY and watchonly from RPCs":
(https://github.com/bitcoin/bitcoin/pull/32618#issuecomment-3025100533)
Removed the `include_watchonly=True`.
achow101 closed an issue: "refactor: Standardize logging levels and increase granularity in P2P and mempool modules"
(https://github.com/bitcoin/bitcoin/issues/32851)
💬 achow101 commented on issue "refactor: Standardize logging levels and increase granularity in P2P and mempool modules":
(https://github.com/bitcoin/bitcoin/issues/32851#issuecomment-3025113896)
Please do not use AI to spam open issues.
💬 achow101 commented on pull request "doc: clarify that the "-j N" goes after the "--build build" part":
(https://github.com/bitcoin/bitcoin/pull/32846#issuecomment-3025180099)
ACK 0e9f409db3b7b08aef75ce39765b018b69cc8e9d
🚀 achow101 merged a pull request: "doc: clarify that the "-j N" goes after the "--build build" part"
(https://github.com/bitcoin/bitcoin/pull/32846)