💬 vasild commented on pull request "Broadcast own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2553254778)
Changed to `_strong()` even though the [docs read](https://en.cppreference.com/w/cpp/atomic/atomic/compare_exchange):

> compare_exchange_weak is allowed to fail spuriously, that is, acts as if *this != expected even if they are equal. When a compare-and-exchange is in a loop, compare_exchange_weak will yield better performance on some platforms.
>
> When compare_exchange_weak would require a loop and compare_exchange_strong would not, compare_exchange_strong is preferable ...

I find the
...

💬 vasild commented on pull request "Broadcast own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/29415#issuecomment-3566902150)
`7987000d36...73ea6405da`: take some suggestions and avoid the `<=>` operator since it does not compile on Xcode 15.

💬 l0rinc commented on pull request "Broadcast own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2553258829)
In other cases like https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2550252802 we were going with the simplest one having the strongest guarantees - but if you think I'm wrong here, please leave the old value, no strong feelings here.

💬 l0rinc commented on pull request "Broadcast own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2553306050)
Discussed this out of band, the tx has a clear pattern already, let's keep the current value - please resolve the comment

📝 151henry151 opened a pull request: "Align legacy script policy with P2SH policy in AreInputsStandard"
(https://github.com/bitcoin/bitcoin/pull/33926)
Legacy scripts currently require solvability, while P2SH scripts only check sigop count. This asymmetry causes some non-solvable legacy scripts to be rejected even when they have acceptable sigop counts, while equivalent P2SH scripts would be accepted.

This change updates AreInputsStandard to check sigop count for legacy scripts instead of requiring solvability, matching P2SH behavior. Non-solvable legacy scripts with sigop counts within the limit are now accepted, consistent with P2SH.

This i
...

💬 hebasto commented on pull request "qt: Defer transaction signing until user clicks Send":
(https://github.com/bitcoin/bitcoin/pull/33925#issuecomment-3566981166)
Please move this PR to the GUI repository: https://github.com/bitcoin-core/gui/pulls.

💬 151henry151 commented on pull request "qt: Defer transaction signing until user clicks Send":
(https://github.com/bitcoin/bitcoin/pull/33925#issuecomment-3566982934)
Moving this PR to the GUI repository as requested by @hebasto.

✅ 151henry151 closed a pull request: "qt: Defer transaction signing until user clicks Send"
(https://github.com/bitcoin/bitcoin/pull/33925)

📝 151henry151 opened a pull request: "qt: Defer transaction signing until user clicks Send"
(https://github.com/bitcoin-core/gui/pull/915)
Fixes #30070

When creating an unsigned PSBT from the GUI, the transaction was already signed during preparation, causing legacy inputs to have non-empty scriptSig fields. The PSBT parser then rejects them.

This defers signing until the user clicks "Send" instead of signing during preparation. Fee calculation still works since transactions can be created without signing.

Follows the approach suggested by @achow101 in the issue comments.

💬 151henry151 commented on pull request "Align legacy script policy with P2SH policy in AreInputsStandard":
(https://github.com/bitcoin/bitcoin/pull/33926#issuecomment-3567065533)
Our change allows NONSTANDARD legacy scripts with acceptable sigop counts to pass AreInputsStandard, which breaks tests that relied on those scripts being rejected.

p2p_segwit.py uses a NONSTANDARD script (0 sigops) as self.utxo[0] that now passes instead of being rejected, so transactions that should be rejected are getting accepted.

feature_taproot.py has some spenders with NONSTANDARD scripts that are now allowed, so the test's standardness checks don't match the new policy.

I'll fix
...

💬 hebasto commented on pull request "qa: Remove no longer needed `feature_dirsymlinks.py`":
(https://github.com/bitcoin/bitcoin/pull/33924#issuecomment-3567069472)
> Being able to symlink the dir seems like a Bitcoin Core feature that should be supported and tested?

If "a Bitcoin Core feature" is taken to mean something explicitly implemented in the Bitcoin Core codebase, then this PR would indeed reduce test coverage. But that is not the case here.

💬 hebasto commented on issue "`test_bitcoin` from pre-built 28.0rc2 tarball is failing for JSON parsing":
(https://github.com/bitcoin/bitcoin/issues/30938#issuecomment-3567084620)
> This can be worked around by installing python3. An alternative would be something like done here: https://github.com/bitcoin/bitcoin/pull/29868/files#r1747435819 (but that diff currently does not compile, as can be seen in the CI output)

I’ve revisited this and now think it’s reasonable for a test of a feature that itself depends on Python (HWI) to use Python directly. The only requirement is a runtime check ensuring that Python is available in `PATH`.

The dependency on `coreutils` may not
...

⚠️ mosbygerry2-svg opened an issue: "HOW DO I GET MY LOST BITCOIN BACK FROM SCAMMERS? Through TechY Force Cyber Retrieval"
(https://github.com/bitcoin/bitcoin/issues/33927)
I recently had the opportunity to work with a skilled programmer who specialized in recovering crypto assets, and the results were nothing short of impressive. The experience not only helped me regain control of my investments but also provided valuable insight into the intricacies of cryptocurrency technology and cybersecurity. The journey began when I attempted to withdraw $183,000 from an investment firm, only to be met with a series of challenges that made it impossible for me to access my
...

💬 instagibbs commented on pull request "Cluster mempool":
(https://github.com/bitcoin/bitcoin/pull/33629#discussion_r2553391883)
https://github.com/bitcoin/bitcoin/pull/28676#discussion_r2359774840

was already hashed over in other PR

💬 billythekid commented on issue ".":
(https://github.com/bitcoin/bitcoin/issues/33927#issuecomment-3567163720)
This is fantastic.

⚠️ SeaSquared24 opened an issue: "Fresh install version 30.0 bitcoin-cli kicks me out if adding rpc creds"
(https://github.com/bitcoin/bitcoin/issues/33928)
I have already read this other [issue](https://github.com/bitcoin/bitcoin/issues/14627) and could not determine if it was relevant to mine.

This is a fresh install of Bitcoin Core 30.0 and I am using the conf file from Ministry of Nodes 2024 [guide](https://www.youtube.com/watch?v=l-JJzodH2l8&list=PLCRbH-IWlcW0g0HCrtI06_ZdVVolUWr39&index=6) MINUS the rpc creds because I am too lazy at the moment to do the rpcauth.py stuff and found that I can use the node normally until I add lines for rpcuser=
...

📝 andrewtoth converted_to_draft a pull request: "validation: fetch block inputs on parallel threads >20% faster IBD"
(https://github.com/bitcoin/bitcoin/pull/31132)
This PR parallelizes fetching all input prevouts of a block right before block connection, achieving up to 31% faster IBD performance[^1][^2][^3].

### Problem

Currently, when fetching inputs in `ConnectBlock`, each input is fetched from the cache sequentially. A cache miss requires a round trip to the disk database to fetch the outpoint and insert it into the cache. Since the database is read-only during `ConnectBlock`, we can fetch all inputs of a block in parallel on multiple threads whi
...

✅ RandyMcMillan closed a pull request: "rpcnestedtests.cpp:remove qtest-obsolete members"
(https://github.com/bitcoin-core/gui/pull/900)

💬 yuvicc commented on pull request "kernel, validation: Refactor ProcessNewBlock(Headers) to return BlockValidationState":
(https://github.com/bitcoin/bitcoin/pull/33856#discussion_r2553777710)
Makes sense. Thanks.

💬 yuvicc commented on pull request "kernel, validation: Refactor ProcessNewBlock(Headers) to return BlockValidationState":
(https://github.com/bitcoin/bitcoin/pull/33856#issuecomment-3567526785)
Thanks for the review @w0xlt
- Addressed the [suggestion](https://github.com/bitcoin/bitcoin/pull/33856#discussion_r2547248797) and added you as co-author