Bitcoin Core Github
44 subscribers
121K links
Download Telegram
πŸ’¬ fanquake commented on pull request "depends: fix libevent `_WIN32_WINNT` usage":
(https://github.com/bitcoin/bitcoin/pull/32837#issuecomment-3078450101)
Backported to 29.x in #32863.
⚠️ tonypatrick8390 opened an issue: "WHAT IS THE GREATEST WAY TO CATCH A CHEATING PARTNER?"
(https://github.com/bitcoin/bitcoin/issues/32992)
### Please describe the feature you'd like to see added.

In any relationship, trust is fundamental, and discovering infidelity can be emotionally devastating. When faced with this challenging situation, finding reliable information is critical. I turned to FUNDS RECLAIMER COMPANY, a resource-oriented tool designed to help individuals gather pertinent data without invasive methods. This service offered me insights into the online activities that could shed light on the truth of my partner’s acti
...
πŸ’¬ willcl-ark commented on pull request "Migrate CI to hosted Cirrus Runners":
(https://github.com/bitcoin/bitcoin/pull/32989#discussion_r2210385688)
Actually I feel a bit less convinced that dropping a `sudo ... ` command into the CI scripts is ideal for this actually. I see comments that 32 bits should now be "fixed": https://github.com/google/sanitizers/issues/1614#issuecomment-1885369007

Testing this now locally...
πŸ’¬ maflcko commented on issue "ci: improve "test each commit" job to handle more complex scenarios":
(https://github.com/bitcoin/bitcoin/issues/32991#issuecomment-3078554931)
I can't reproduce this locally, when copy-pasting the command (https://github.com/bitcoin/bitcoin/actions/runs/16315746903/job/46081155541?pr=28122#step:7:3), even when installing the git version from GHA (https://github.com/actions/runner-images/commit/723cd0240d0c380f28bfd66e4ec6556dc3b536fd#diff-cc12e5c5d005932feaacf280af949d83e2cb6020dff8203d9ead2e00c30e8b7fR77):

```
# git checkout a4c84b90c0f2be478e84c39785cbda2a8b2512db && git rebase --exec "git merge --no-commit origin/master && echo ./.
...
πŸ’¬ maflcko commented on issue "ci: improve "test each commit" job to handle more complex scenarios":
(https://github.com/bitcoin/bitcoin/issues/32991#issuecomment-3078562830)
> I'm not sure what you mean by "create the subtree merge commit from scratch."

Sorry, I misread that you were rebasing the subtree merge commit, but you were rebasing *on* the subtree merge commit, which should be correct.
πŸ“ brunoerg opened a pull request: "fuzz: wallet: add target for tx scanning"
(https://github.com/bitcoin/bitcoin/pull/32993)
Tracking issue (#29901)

This PR adds a fuzz target for wallet tx scanning (`ScanForWalletTransactions`). Unfortunately, it's not a regression test for the issue #31474 since it would require a more complex scenario/async operations.
πŸ‘ stickies-v approved a pull request: "log: [refactor] Use info level for init logs"
(https://github.com/bitcoin/bitcoin/pull/32967#pullrequestreview-3024974858)
ACK fa65716a878dbc0daabf1b31e832db5b230c285c

Mostly refactor operations, with a couple of minor logging statement updates (e.g. removing function names, adding detail on which operation is started/exited, ...)
πŸ’¬ stickies-v commented on pull request "log: [refactor] Use info level for init logs":
(https://github.com/bitcoin/bitcoin/pull/32967#discussion_r2210416125)
nit: would be good to add braces or move to one-liner while touching this
πŸ’¬ stickies-v commented on pull request "log: [refactor] Use info level for init logs":
(https://github.com/bitcoin/bitcoin/pull/32967#discussion_r2210405561)
I think `LogWarning` could be appropriate here?
πŸ‘‹ brunoerg's pull request is ready for review: "fuzz: wallet: add target for tx scanning"
(https://github.com/bitcoin/bitcoin/pull/32993)
πŸ’¬ rkrux commented on pull request "wallet/rpc: fix listdescriptors RPC fails to return descriptors with private key information when wallet contains descriptors missing any key":
(https://github.com/bitcoin/bitcoin/pull/32471#issuecomment-3078633756)
Concept ACK bb14e8ac7d38f3698d76ea3d6dce09e1387d59f3

Started reviewing the PR.
πŸ’¬ instagibbs commented on pull request "validation: docs and cleanups for MemPoolAccept coins views":
(https://github.com/bitcoin/bitcoin/pull/32973#discussion_r2210398185)
> The view doesn't track whether a coin previously existed but has now been spent

been spent in mempool/package contexts, I presume
πŸ‘ instagibbs approved a pull request: "validation: docs and cleanups for MemPoolAccept coins views"
(https://github.com/bitcoin/bitcoin/pull/32973#pullrequestreview-3022450569)
ACK b5805eddefced4cd8bb6f8069ea0a4bf199bacff

confirmed that the remaining tests cases fail when specific key clauses are modified, that it seems implausible that the test adds much assurances, and honestly is not a particularly maintainable test. The new comments are helpful for me to trace the code in a directed way and confirm what it's saying.
πŸ“ danielabrozzoni opened a pull request: "doc: clarify AddrMan::GetAddresses documentation"
(https://github.com/bitcoin/bitcoin/pull/32994)
Improve the GetAddresses documentation by specifying that one version of the function uses the address response cache while the other does not.

Also update the outdated "call the function without a parameter" phrasing in the cached version. This wording was accurate when the cache was introduced in #18991, but became outdated after later commits (f26502e9fc8a669b30717525597e3f468eaecf79, 81b00f87800f40cb14f2131ff27668bd2bb9e551) added parameters to each function.
πŸ’¬ instagibbs commented on pull request "Reduce minrelaytxfee to 100 sats/kvB":
(https://github.com/bitcoin/bitcoin/pull/32959#issuecomment-3078738029)
@kurapika007

> So why not increase it to 10 sats/vBβ€”reducing bandwidth consumption by 10Γ—, making the network 10Γ— more resilient to spam, and sending the right economic signal for long-term sustainability?

Because especially with arbitrary values, the onus is on the person attempting to change it. Constantly fiddling with the default value is also not really a sustainable option even if we somehow found a new "optimal". If we enter a 90% drawdown bear market, we aren't going to revisit th
...
πŸ’¬ maflcko commented on issue "getbestblockhash is sometimes taking a very long time":
(https://github.com/bitcoin/bitcoin/issues/32733#issuecomment-3078781773)
Does `-forcecompactdb` improve the situation for you?
πŸ’¬ martinatime commented on issue "getbestblockhash is sometimes taking a very long time":
(https://github.com/bitcoin/bitcoin/issues/32733#issuecomment-3078804148)
I don't think I have tried that. Is there a way I can tell if the db needs to be compacted before I attempt this?
πŸ’¬ sr-gi commented on pull request "Adds transaction propagation information to mempool transactions":
(https://github.com/bitcoin/bitcoin/pull/32986#issuecomment-3078827018)
> > I'm unsure whether the added complexity is justified, given that it's unlikely to be used beyond that specific context.
>
> Would adding tracepoint(s) be a suitable alternative? More overhead for the user, but probably much less in this repo?

I think existing tracepoints can be used as the base to build something similar outside Core, like `net:outbound_message` and `net:inbound_message`. Similarly, a log grabber (grepper?) can also work in some cases. The issue I see with both solutio
...
πŸ’¬ kurapika007 commented on pull request "Reduce minrelaytxfee to 100 sats/kvB":
(https://github.com/bitcoin/bitcoin/pull/32959#issuecomment-3078830847)
> @kurapika007
>
> Because especially with arbitrary values, the onus is on the person attempting to change it. Constantly fiddling with the default value is also not really a sustainable option even if we somehow found a new "optimal". If we enter a 90% drawdown bear market, we aren't going to revisit this value and raise it, are we?
>
Perhaps the solution lies not simply in arbitrarily adjusting technical parameters, but rather in adopting rules that better align the economic incentives of
...
πŸ‘ TheCharlatan approved a pull request: "init: [gui] Avoid UB/crash in InitAndLoadChainstate"
(https://github.com/bitcoin/bitcoin/pull/32987#pullrequestreview-3025283492)
Thanks for fixing, should have thought of this when I started making the destructors more powerful! ACK on the fixes, the functional test is a bit hacky, but I don't have a better idea either. Maybe we could hook into the ui interface instead, but that's not necessarily cleaner and we only have one caller of `ThreadSafeQuestion` anyway.