Bitcoin Core Github
42 subscribers
126K links
Download Telegram
πŸ‘ sedited approved a pull request: "rest: allow reading partial block data from storage"
(https://github.com/bitcoin/bitcoin/pull/33657#pullrequestreview-3536659569)
Re-ACK d2f4bccbf70031b84b6af1a6c8480c4b3071bfd7
πŸ’¬ maflcko commented on pull request "wallet: don't consider unconfirmed TRUC coins with ancestors":
(https://github.com/bitcoin/bitcoin/pull/33528#issuecomment-3608602721)
> Open/closed to re-run CI, and it seems to have the same issue.

Is it fixed now?
πŸ’¬ maflcko commented on pull request "Wallet: Add `maxfeerate` wallet startup option":
(https://github.com/bitcoin/bitcoin/pull/29278#issuecomment-3608605508)
Could turn into draft, while ci is red?
πŸ’¬ darosior commented on issue "ASN-based bucketing of the network nodes":
(https://github.com/bitcoin/bitcoin/issues/16599#issuecomment-3608666477)
Thanks for the data @virtu. I think it's important to make a compelling case that switching to ASmap by default won't lead to a degraded network that would take a long time to fix due to the slow take-up on new releases.

Regarding your minor concern, i previously [asked](https://btctranscripts.com/bitcoin-core-dev-tech/2025-02/asmap) about this and got back that the half-life of a map should be around 5 years. So it should always be better than the current method. And i guess it's always possib
...
⚠️ Sreejitroy opened an issue: "Request to help mining two Nonstandard UTXO which fails cleanstack"
(https://github.com/bitcoin/bitcoin/issues/34002)
### Please describe the feature you'd like to see added.

I have 2 anybody can spend UTXO which fails cleanstack validation which says non-mandatory script verify flag(Stack size must be exactly one after execution) for P2SH, the script passes consensus perfectly as top item is true but get problem here even if it ends with 2 elements gives the same error. Requesting you to at least make it 5 elements max on the stack .

### Is your feature related to a problem, if so please describe it.

_No re
...
πŸ’¬ l0rinc commented on pull request "qa: Avoid knock-on exception in assert_start_raises_init_error":
(https://github.com/bitcoin/bitcoin/pull/32929#issuecomment-3608760754)
I have tested the previous ACK, now just reviewed the range-diff and rebased soft-reset, the latest change looks good to me.

ACK 6b0eac750f3aecb29446d70c039559143e43a011

<details>
<summary>patch since last ACK</summary>

```patch
diff --git a/test/functional/feature_framework_startup_failures.py b/test/functional/feature_framework_startup_failures.py
--- a/test/functional/feature_framework_startup_failures.py (revision 298789b8cbc7283fd868934c615390b98943ebba)
+++ b/test/functional/f
...
πŸ’¬ hodlinator commented on pull request "qa: Avoid knock-on exception in assert_start_raises_init_error":
(https://github.com/bitcoin/bitcoin/pull/32929#issuecomment-3608761603)
Latest push (6b0eac750f3aecb29446d70c039559143e43a011):
* Restores the " (cmd: ..." addition in d7ff1d0fa572ec36ff1eb10c0a1c04ef5e5be072 which had somehow gone missing in 4eccfae4563933c8499dc6994980d8bb8df53381. The test in c06a8ee18699800a0fa06898251ac7088ea8ef70 had also lost " \(cmd:" in ae69cf7bc7ebecd0d58b007a2c556a787554af28, so it's not just a mismerge. Possibly a case of working on multiple computers and not syncing properly between them before force-pushing. Thanks to @l0rinc for find
...
πŸ‘ sedited approved a pull request: "refactor: unify container presence checks"
(https://github.com/bitcoin/bitcoin/pull/33192#pullrequestreview-3536863021)
ACK d9319b06cf82664d55f255387a348135fd7f91c7
πŸ’¬ romanz commented on pull request "rest: allow reading partial block data from storage":
(https://github.com/bitcoin/bitcoin/pull/33657#issuecomment-3608793203)
Split https://github.com/bitcoin/bitcoin/commit/d2f4bccbf70031b84b6af1a6c8480c4b3071bfd7 into 3 commits:

$ git lg -3
* e6eb4a57df Roman Zeyde: rest: allow reading partial block data from storage
* 8f0bfb9343 Roman Zeyde: blockstorage: allow reading partial block data from storage
* 07b8278299 Roman Zeyde: blockstorage: overload `ReadRawBlock()` to return an error code

https://github.com/bitcoin/bitcoin/compare/d2f4bccbf70031b84b6af1a6c8480c4b3071bfd7..e6eb4a57df9f0379550358e4362729bf
...
πŸ‘ sedited approved a pull request: "rest: allow reading partial block data from storage"
(https://github.com/bitcoin/bitcoin/pull/33657#pullrequestreview-3536915373)
Re-ACK e6eb4a57df9f0379550358e4362729bfe5953007
πŸ’¬ jaonoctus commented on pull request "init: point out -stopatheight may be imprecise":
(https://github.com/bitcoin/bitcoin/pull/33993#issuecomment-3608878395)
tACK e4703863655135856d0d6ad54a7021d3326bf071

I would love to fix the issue mentioned tho, but updating the description is a good start
πŸ“ ryanofsky opened a pull request: "test: interface_ipc.py minor fixes and cleanup"
(https://github.com/bitcoin/bitcoin/pull/34003)
This PR cleans up the `interface_ipc.py` test, fixing broken checks, fixing missing await calls, removing to_dict calls, renaming variables, reducing `.result` accesses, and giving template objects explicit lifetimes. More details are in the commit message.
πŸ‘ pablomartin4btc approved a pull request: "init: point out -stopatheight may be imprecise"
(https://github.com/bitcoin/bitcoin/pull/33993#pullrequestreview-3537008041)
utACK e4703863655135856d0d6ad54a7021d3326bf071

I'd also go with @stickies-v's [version](https://github.com/bitcoin/bitcoin/pull/33993#discussion_r2580857428) if you have to retouch.
πŸ’¬ ryanofsky commented on pull request "mining: add getMemoryLoad() and track template non-mempool memory footprint":
(https://github.com/bitcoin/bitcoin/pull/33922#issuecomment-3608940825)
Concept ACK e8f8f7f677bcde0179526be3ed9a657c44998b93. All the changes here seem good and mostly straightforward. The `getMemoryLoad()` function seems useful by itself and the underlying tracking would seem to provide almost everything needed to limit memory used by block templates.

I am a little concerned about the idea of proactively deleting block templates in FIFO order on behalf of clients, since it seems like this could increase complexity server-side, and client-side if clients have to
...
βœ… pinheadmz closed an issue: "Request to help mining two Nonstandard UTXO which fails cleanstack"
(https://github.com/bitcoin/bitcoin/issues/34002)
πŸ’¬ pinheadmz commented on issue "Request to help mining two Nonstandard UTXO which fails cleanstack":
(https://github.com/bitcoin/bitcoin/issues/34002#issuecomment-3609010449)
The Bitcoin Core issue tracker is reserved for specific software issues like bug reports and feature requests. Individual help inquiries or general Bitcoin usage questions are more appropriate at https://bitcoin.stackexchange.com https://reddit.com/r/bitcoin or IRC channels such as `#bitcoin`
πŸ’¬ mzumsande commented on issue "ASN-based bucketing of the network nodes":
(https://github.com/bitcoin/bitcoin/issues/16599#issuecomment-3609099274)
> a conceivable scenario entails a non-negligible share of Bitcoin nodes not being able to sustain ten outbound connections because they are in constant competition with other nodes for inbound slots on β€žsmall-ASβ€œ nodes although ample unused inbound resources are available on β€žlarge-ASβ€œ nodes.

This would likely lead to a "ping-pong" effect of evictions:

When most popular reachable nodes are full (125 peers), and other nodes seeking for outbound peers will connect to them, they will usually ac
...
πŸ’¬ hodlinator commented on pull request "rest: allow reading partial block data from storage":
(https://github.com/bitcoin/bitcoin/pull/33657#issuecomment-3609114450)
Been running some benchmarks:

```shell
β‚Ώ cmake --build build -t bench_bitcoin && ./build/bin/bench_bitcoin -filter=ReadRawBlockBench -min-time=15000
```
(Usually second run has lower error rate).

### baseline - master - `07b82782~` = d30f149360

```
| ns/op | op/s | err% | ins/op | cyc/op | IPC | bra/op | miss% | total | benchmark
|--------------------:|--------------------:|--------:|----------------:|--------------
...
πŸ’¬ sipa commented on issue "ASN-based bucketing of the network nodes":
(https://github.com/bitcoin/bitcoin/issues/16599#issuecomment-3609129125)
> When most popular reachable nodes are full (125 peers), and other nodes seeking for outbound peers will connect to them, they will usually accept the connection, but at the same time evict another peer to make room. The evicted peer then looks for a new outbound peer, which, if also full, evicts yet another one and so on, leading to long chains of churning through peers which would obviously be bad for the network.

Is that really what happens? That sounds undesirable, independent of this issu
...