Bitcoin Core Github
44 subscribers
120K links
Download Telegram
πŸ‘‹ hebasto's pull request is ready for review: "build, docs: Fix Boost-related issues on NetBSD"
(https://github.com/bitcoin/bitcoin/pull/32828)
πŸ’¬ ariard commented on pull request "BIP-119 (OP_CHECKTEMPLATEVERIFY) (regtest only)":
(https://github.com/bitcoin/bitcoin/pull/31989#issuecomment-3017163445)
Opened a pull request on Jamesob repository with the suggested changes: due to current block sigs exhaustions exposure:
https://github.com/jamesob/bitcoin/pull/3

Changes motivated by current exposure to block signature overflow attacks and it’s quite simple to fix.
⚠️ Raimo33 opened an issue: "Redundant else statements in SRC/logging.cpp"
(https://github.com/bitcoin/bitcoin/issues/32830)
static std::optional<BCLog::Level> GetLogLevel(std::string_view level_str)
{
if (level_str == "trace") {
return BCLog::Level::Trace;
} else if (level_str == "debug") {
return BCLog::Level::Debug;
} else if (level_str == "info") {
return BCLog::Level::Info;
} else if (level_str == "warning") {
return BCLog::Level::Warning;
} else if (level_str == "error") {
return BCLog::Level::Error;
} else {
return std::nullopt;
}
}
πŸ€” mzumsande reviewed a pull request: "mempool: Avoid needless vtx iteration in `removeForBlock` during IBD"
(https://github.com/bitcoin/bitcoin/pull/32827#pullrequestreview-2969577114)
"known to be empty" / "always empty" is too strong:
It's quite common for nodes that are not online 24/7 to be in IBD (because they have to catch up a few weeks/months) but have a non-empty mempool. This doesn't affect the approach, just the PR / commit message description.
⚠️ jasminemoore0410 opened an issue: "FUNDS RECLAIMER COMPANY / BEST RECOVERY SERVICE TO HELP YOU GET BACK YOUR LOST CRYPTO"
(https://github.com/bitcoin/bitcoin/issues/32831)
### Motivation

CONTACT INFO BELOW

WhatsApp:: + 1 3 6 1 2 5 0 4 1 1 0

Email:: fundsreclaimer@consultant.com

Telegram:: @fundsreclaimercompany0

A new breed of scam has emerged in the USA, and unfortunately, I became one of its victims. I was drawn in by the allure of an online gambling platform that promised easy winnings and thrilling experiences. The site looked legitimate, and I was excited to deposit my cryptocurrency, specifically 4.5 BTC, believing I was making a smart investment. Howev
...
πŸ’¬ l0rinc commented on pull request "mempool: Avoid needless vtx iteration in `removeForBlock` during IBD":
(https://github.com/bitcoin/bitcoin/pull/32827#issuecomment-3017884339)
Thanks, updated - though I don't think that's "Initial", just regular Block Download.
πŸ’¬ l0rinc commented on issue "Redundant else statements in SRC/logging.cpp":
(https://github.com/bitcoin/bitcoin/issues/32830#issuecomment-3017886926)
Please stop spamming, this isn't useful
βœ… maflcko closed an issue: "Redundant else statements in SRC/logging.cpp"
(https://github.com/bitcoin/bitcoin/issues/32830)
πŸ’¬ maflcko commented on pull request "p2p: add more bad ports":
(https://github.com/bitcoin/bitcoin/pull/32826#issuecomment-3017950506)
Please squash your commits according to https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#squashing-commits
πŸ’¬ maflcko commented on pull request "docs: add guidance on initialism capitalisation in PascalCase identifiers.":
(https://github.com/bitcoin/bitcoin/pull/32720#issuecomment-3017954531)
Please squash your commits according to https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#squashing-commits
πŸ’¬ maflcko commented on pull request "rpc: Handle -named argument parsing where '=' character is used":
(https://github.com/bitcoin/bitcoin/pull/32821#discussion_r2174327111)
this list is incomplete. Also, I wonder how this should be maintained. There needs to be an automated check that the list is up-to-date, like for the other list.
πŸ’¬ darosior commented on pull request "policy: make pathological transactions packed with legacy sigops non-standard":
(https://github.com/bitcoin/bitcoin/pull/32521#discussion_r2174491505)
I don't think there is any point in trying to micro-optimize this.
πŸ’¬ Muniru0 commented on pull request "docs: add guidance on initialism capitalisation in PascalCase identifiers.":
(https://github.com/bitcoin/bitcoin/pull/32720#issuecomment-3018221235)
> Please squash your commits according to https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#squashing-commits

aaah, forgot. thanks
πŸ’¬ darosior commented on pull request "policy: make pathological transactions packed with legacy sigops non-standard":
(https://github.com/bitcoin/bitcoin/pull/32521#discussion_r2174500469)
> Asking because of

This is unrelated. Most sigops counted here are not counted in the old rule. In any case this change cannot lead to miners create invalid blocks.
πŸ’¬ darosior commented on pull request "policy: make pathological transactions packed with legacy sigops non-standard":
(https://github.com/bitcoin/bitcoin/pull/32521#discussion_r2174503497)
Don't think that matters much, but i'll take your suggestion.
πŸ’¬ darosior commented on pull request "policy: make pathological transactions packed with legacy sigops non-standard":
(https://github.com/bitcoin/bitcoin/pull/32521#discussion_r2174515133)
In real usage `AreInputsStandard` is always called with a warm up cache so what you check here is not representative.
πŸ’¬ l0rinc commented on pull request "policy: make pathological transactions packed with legacy sigops non-standard":
(https://github.com/bitcoin/bitcoin/pull/32521#discussion_r2174523500)
> In any case this change cannot lead to miners creating invalid blocks.

I know, what I was asking is how we expect the non-standardness of blocks to change because of this PR, i.e. how many blocks are usually mined that contradict the new rules and how we expect this PR to change that in time.
πŸ’¬ l0rinc commented on pull request "policy: make pathological transactions packed with legacy sigops non-standard":
(https://github.com/bitcoin/bitcoin/pull/32521#discussion_r2174531192)
The current implementation is ~66% slower, nothing "micro" about that. Very often we can make code simpler (i.e. having fewer moving parts) AND faster at the same time. This repeats work currently, so it's not as simple as it can get - what I'm suggesting is to explore that since the redundancy has a measurable cost.
πŸ’¬ l0rinc commented on pull request "policy: make pathological transactions packed with legacy sigops non-standard":
(https://github.com/bitcoin/bitcoin/pull/32521#discussion_r2174535364)
We're doing needless work in this case - calling the second sigop count validation when we already know that we could exit early. This was the argument you gave against `return sigops <= MAX_TX_LEGACY_SIGOPS`. I would be fine with either, but this in-between needs a proper explanation in my opinion.
πŸ’¬ l0rinc commented on pull request "policy: make pathological transactions packed with legacy sigops non-standard":
(https://github.com/bitcoin/bitcoin/pull/32521#discussion_r2174536803)
Can you update the benchmark to make it representative?