Bitcoin Core Github
43 subscribers
122K links
Download Telegram
πŸ’¬ ismaelsadeeq commented on pull request "node: add `BlockTemplateCache`":
(https://github.com/bitcoin/bitcoin/pull/33421#issuecomment-3492547495)
I forced pushed from 084bfbc1ec7f8f64f54d231bb641285622311b59 to a3f0010c2062fc88720e7eae33694f2491c32ebe [2311b59..a3f001](https://github.com/bitcoin/bitcoin/compare/084bfbc1ec7f8f64f54d231bb641285622311b59..a3f0010c2062fc88720e7eae33694f2491c32ebe)
- We now avoid the second copy when submitting solution by moving the block by value when constructing the shared pointer https://github.com/bitcoin/bitcoin/pull/33421#discussion_r2486576551
- Removed the `operator=` in block assembler options an
...
πŸ’¬ frankomosh commented on pull request "doc: add cmake help option in Windows build docs":
(https://github.com/bitcoin/bitcoin/pull/33789#discussion_r2495546955)
I think it needs to match the format in `doc/build-unix.md`.
πŸ’¬ vasild commented on pull request "net: make m_nodes_mutex non-recursive":
(https://github.com/bitcoin/bitcoin/pull/32394#discussion_r2495596406)
I considered this again. I like to have the `Assume()` for documentation purposes. But that would make it stricter compared to `master` and this is not the purpose of this PR. I mean - in `master` and in this PR as it is now the logic is "if there are more than 3, remove one". Yes, we do imply that there will not be more than 3 at the end, but asserting that (in dev-only `Assume()`) seems to be out of the scope of this PR. So, I will leave it as it is.
πŸ’¬ vasild commented on pull request "net: make m_nodes_mutex non-recursive":
(https://github.com/bitcoin/bitcoin/pull/32394#issuecomment-3492632122)
`4b3a2c2360...1a9274f391`: rebase due to conflicts
πŸ’¬ l0rinc commented on issue "dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us appears to be violating DNS seed policy":
(https://github.com/bitcoin/bitcoin/issues/33734#issuecomment-3492922390)
Would we add Luke as a DNS seed operator now, if that was the discussion instead?
πŸ’¬ ajtowns commented on pull request "Relax standardness rules regarding CHECKMULTISIG":
(https://github.com/bitcoin/bitcoin/pull/33755#issuecomment-3493057300)
It would be good to add a test case that demonstrates scriptPubKeys of this form (baremultisig and possible multisig in p2sh, with valid key push prior to invalid key) are spendable.

I think creating these outputs became non-standard with #12460 (2018-04-05 merge date), which changed the checks for pubkeys in a bare multisig from a size between 33 and 65 bytes (inclusive) to an explicit check of 02/03-and-33-bytes or 04/06/07-and-65-bytes.

In trying to create a functional test to validate
...
πŸ’¬ kevkevinpal commented on pull request "script: remove dead code in `CountWitnessSigOps`":
(https://github.com/bitcoin/bitcoin/pull/33786#issuecomment-3493137616)
ACK [24bcad3](https://github.com/bitcoin/bitcoin/pull/33786/commits/24bcad3d4df59690f30c9df8ebb62f0bddd0f1c7)
πŸ’¬ Sjors commented on issue "RFC: Do we want to support fuzzing on MacOS?":
(https://github.com/bitcoin/bitcoin/issues/33731#issuecomment-3493139664)
The only performant macOS machine I have is a laptop, so I would never use that for long running fuzzer jobs. I do want to be able to reproduce failures, but that's not at stake here.

If I ever want to add a new fuzz target, I don't mind trying it on a physical linux machine (virtualisation on Apple Silicon has often been a can of worms for me, though I haven't tried with fuzzing).

Not doing (1) does increase the barrier for macOS based developers to contribute fuzz code. I'm not sure how to c
...
πŸ’¬ TheCharlatan commented on pull request "kernel: Separate UTXO set access from validation functions":
(https://github.com/bitcoin/bitcoin/pull/32317#issuecomment-3493153738)
Rebased 9ce01e051bae5fb1d48d6d297eb011b13d20ec76 -> 5988c7172406e3caca32fc78c011d878a1abdf1e ([spendblock_13](https://github.com/TheCharlatan/bitcoin/tree/spendblock_13) -> [spendblock_14](https://github.com/TheCharlatan/bitcoin/tree/spendblock_14), [compare](https://github.com/TheCharlatan/bitcoin/compare/spendblock_13..spendblock_14))

* Fixed a silent merge conflict
πŸ’¬ yancyribbens commented on pull request "test: add case where `TOTAL_TRIES` is exceeded yet solution remains":
(https://github.com/bitcoin/bitcoin/pull/33701#discussion_r2496018695)
Thanks, done.
⚠️ zerozorotop945 opened an issue: "🎰 Casino Bonus Guide 2025 | Claim the Best Casino Bonuses"
(https://github.com/bitcoin/bitcoin/issues/33794)
Welcome to the **Ultimate Casino Bonus 2025 Guide**, your all-in-one resource to discover the most rewarding **casino bonuses**, **deposit offers**, and **crypto casino promotions** online.

At new users can unlock an exclusive **Casino Bonus** using promo code **2025**. Whether you’re looking for the best **casino deposit bonus**, exploring **stake bonuses**, or diving into **crypto casino** gaming, this guide will help you maximize your winnings and enjoy a next-level gaming experience.

---


...
βœ… willcl-ark closed an issue: "🎰 Casino Bonus Guide 2025 | Claim the Best Casino Bonuses"
(https://github.com/bitcoin/bitcoin/issues/33794)
πŸ’¬ yancyribbens commented on pull request "test: add case where `TOTAL_TRIES` is exceeded yet solution remains":
(https://github.com/bitcoin/bitcoin/pull/33701#discussion_r2496069524)
Ey thanks for catching that! I updated the test so that it re-populates the `doppelgangers` array. It's tricky that the api doesn't return a different result when the TOTAL_TRIES is exceeded.

I maintain a rust version of coin-grinder, and I added a test that is the same as here: https://github.com/p2pderivatives/rust-bitcoin-coin-selection/commit/a0e033b67ba20139472075a9fc428a1a81c357e7 . You'll notice in the rust version, one can actually assert `expected_error: Some(IterationLimitReached
...
πŸ’¬ hebasto commented on pull request "cmake: Move IPC tests to `ipc/test`":
(https://github.com/bitcoin/bitcoin/pull/33774#discussion_r2496260062)
Thanks! The comment has been restored and adjusted.
πŸ’¬ hebasto commented on pull request "cmake: Move IPC tests to `ipc/test`":
(https://github.com/bitcoin/bitcoin/pull/33774#issuecomment-3493631585)
The [feedback](https://github.com/bitcoin/bitcoin/pull/33774#discussion_r2494445665) from @ryanofsky has been addressed.

Additionally, `PROJECT_SOURCE_DIR` were replaced with `CMAKE_CURRENT_SOURCE_DIR`.
πŸ“ kevkevinpal opened a pull request: "test: skip interface_ipc if python version is freethreaded and PYTHON_GIL=0 is not set"
(https://github.com/bitcoin/bitcoin/pull/33795)
### Description
I was able to reproduce this issue https://github.com/bitcoin/bitcoin/issues/33582
We should skip the test if `PYTHON_GIL` is not set, instead of the test being abruptly stopped

### When `PYTHON_GIL` not set or set to `1`
```
PYTHON_GIL=1 ./build_dev_mode/test/functional/test_runner.py interface_ipc.py
or
./build_dev_mode/test/functional/test_runner.py interface_ipc.py

Temporary test directory at /tmp/test_runner_β‚Ώ_πŸƒ_20251105_180439
WARNING! There is already a bitc
...
πŸ“ w0xlt opened a pull request: "[kernel] Expose `CheckTransaction` consensus validation function"
(https://github.com/bitcoin/bitcoin/pull/33796)
This PR exposes the consensus-level `CheckTransaction` function through the libbitcoinkernel C API and adds a corresponding C++ wrapper.

Currently, libkernel only provided script-level validation via `btck_script_pubkey_verify` and `ScriptPubkeyApi<>::Verify`.

AFAIK there was no way to perform context-free consensus checks on a transaction’s structure (e.g., coinbase rules, money-range, duplicate inputs).

This change introduces a new API:

```c
int btck_check_transaction(const btck_
...
βœ… w0xlt closed a pull request: "Add libbitcoinkernel example files"
(https://github.com/bitcoin/bitcoin/pull/33669)
πŸ’¬ w0xlt commented on pull request "Add libbitcoinkernel example files":
(https://github.com/bitcoin/bitcoin/pull/33669#issuecomment-3494136470)
Closing this PR for now.
If there’s further interest in adding these examples to this project, we can reopen it.
πŸ’¬ pablomartin4btc commented on pull request "doc: add cmake help option in Windows build docs":
(https://github.com/bitcoin/bitcoin/pull/33789#discussion_r2496576852)
Not necessarily, in fact, most build instructions have different structure (unify it, if possible, could be the goal of a different PR, as you can see here we need to copy stuff for every platform). My suggestion is not a blocker just that you are adding this line in the middle of the building instructions, and that's not the case for the other file you are updating. It's an observation, up to you if you want to leave it that way or not.