Bitcoin Core Github
44 subscribers
121K links
Download Telegram
πŸ’¬ delta1 commented on issue "Decouple datacarrier size and count limits (Draft PR)":
(https://github.com/bitcoin/bitcoin/issues/33595#issuecomment-3390394398)
@jotapea no issues understanding anything. It's apparent you used an LLM to write this. You should close this issue.
πŸ’¬ Aa777263100 commented on issue "Set default datacarriersize to 160 bytes":
(https://github.com/bitcoin/bitcoin/issues/33543#issuecomment-3390416885)
###
πŸ’¬ sipa commented on pull request "cluster mempool: control/optimize TxGraph memory usage":
(https://github.com/bitcoin/bitcoin/pull/33157#discussion_r2420487300)
I just noticed you said "proportional". Indeed, they are, but still off by a factor of up to 2, and 1.5 on average.
πŸ’¬ jotapea commented on issue "Decouple datacarrier size and count limits (Draft PR)":
(https://github.com/bitcoin/bitcoin/issues/33595#issuecomment-3390632428)
@delta1 You are partially right, ai was used as assistance to the original post. I can recommend it if you have similar needs, specially if is not your native language... Now, do you have anything concrete about the draft to discuss?

@pinheadmz Thank you for productively engaging. But please allow some discussion before deciding to close the issue.

By definition any additional configuration is adding complexity... ok I could agree. It is an extremely simple one though.

> reduce the quality of
...
πŸ“ maflcko opened a pull request: "refactor: Construct g_verify_flag_names on first use"
(https://github.com/bitcoin/bitcoin/pull/33600)
The current usage of the `g_verify_flag_names` map seems fine and I can not see a static initialization order fiasco here.

However, it seems brittle to hope this remains the case in the future. Also, it triggers a msan false-positive in the fuzz CI task. (C.f https://github.com/bitcoin-core/qa-assets/actions/runs/18352815555/job/52413137315?pr=241#step:7:5245)

So just apply the "Construct on first use" idiom.
πŸ’¬ delta1 commented on issue "Decouple datacarrier size and count limits (Draft PR)":
(https://github.com/bitcoin/bitcoin/issues/33595#issuecomment-3390749391)
Go ahead and make your PR for this πŸ‘ let’s see how it’s received
πŸ€” furszy reviewed a pull request: "rpc: add "ischange: true" to decoded tx outputs in wallet gettransaction response"
(https://github.com/bitcoin/bitcoin/pull/32517#pullrequestreview-3324273918)
utACK f6517df210f5e940d87823c86358976743de2641

left a small comment that would be nice to fix.
πŸ’¬ furszy commented on pull request "rpc: add "ischange: true" to decoded tx outputs in wallet gettransaction response":
(https://github.com/bitcoin/bitcoin/pull/32517#discussion_r2420826370)
Should be a const ref:
```suggestion
void TxToUniv(const CTransaction& tx, const uint256& block_hash, UniValue& entry, bool include_hex = true, const CTxUndo* txundo = nullptr, TxVerbosity verbosity = TxVerbosity::SHOW_DETAILS, std::function<bool(const CTxOut&)> is_change_func = {});
```
πŸ€” glozow reviewed a pull request: "[29.x] Finalise 29.2"
(https://github.com/bitcoin/bitcoin/pull/33551#pullrequestreview-3324377596)
ACK 46d9b9091baa096da30da5e14329a32f1264229a
πŸ’¬ hhhh3113 commented on something "":
(https://github.com/bitcoin/bitcoin/commit/8f55573ed327430609ec2d8f94cbb79ed03e8f64#r167672061)
==Deployments==

List of deployments.

State can be defined, active, failed. Dates are in UTC.
πŸš€ glozow merged a pull request: "[29.x] Finalise 29.2"
(https://github.com/bitcoin/bitcoin/pull/33551)
πŸ’¬ kevkevinpal commented on pull request "doc: bump the template macOS version since 14 is now the minimum supported version":
(https://github.com/bitcoin/bitcoin/pull/33573#discussion_r2421007513)
I've updated to use these newer versions in [c80bcfb](https://github.com/bitcoin/bitcoin/pull/33573/commits/c80bcfba084aa316d113730d731f79c3aa472abf)
πŸ’¬ glozow commented on issue "Minor Release 29.2":
(https://github.com/bitcoin/bitcoin/issues/33586#issuecomment-3390980492)
v29.2 has been tagged
πŸ’¬ mzumsande commented on pull request "p2p: Advance pindexLastCommonBlock early after connecting blocks":
(https://github.com/bitcoin/bitcoin/pull/32180#discussion_r2421152575)
> Is my understanding correct that pindexLastCommonBlock could be different across peers on the same chain as us (depending on which peers are processed first) or different because our peers may be on different chains from each other?

yes, that's correct. `pindexLastCommonBlock` is also moved forward [here](https://github.com/bitcoin/bitcoin/blob/becf1500131805bd6a47486cd5bc5bdb55839211/src/net_processing.cpp#L1481-L1486) in `FindNextBlocks` if all previous blocks have data, so each peer's `
...
πŸ’¬ willcl-ark commented on issue "Intermittent CI network issue downloading assets.json from GitHub":
(https://github.com/bitcoin/bitcoin/issues/33599#issuecomment-3391178427)
I have reached out to Cirrus to see if they aware of any rate-limiting or anything else which could cause this.
πŸ’¬ GrayHatGuy commented on issue "Intermittent CI network issue downloading assets.json from GitHub":
(https://github.com/bitcoin/bitcoin/issues/33599#issuecomment-3391210443)
It's probably due to all the non-financial op_return data polluting the chain
πŸ€” brunoerg reviewed a pull request: "index: initial sync speedup, parallelize process"
(https://github.com/bitcoin/bitcoin/pull/26966#pullrequestreview-3324866101)
Left the fuzz target (`threadpool`) running overnight, performance is reasonable and didn't get any memory leak. I generated a coverage report at https://brunoerg.xyz/bitcoin-core-coverage/26966/coverage_report/.
πŸ’¬ instagibbs commented on issue "test: intermittent issue in p2p_1p1c_network.py":
(https://github.com/bitcoin/bitcoin/issues/33318#issuecomment-3391409712)
I think I've nailed down what's happening from logs:

1. test peer sends child to node1
2. node1 has parent resolved normally, it's above minfee
3. test peer is picked as unique peer to schedule resolution of child during test peer's next "turn" in networking thread
4. node0 advertises child by wtxid (it's ignored currently because it's in orphanage and has no missing deps)
5. test peer disconnects before ProcessOrphanTx is called (and we never reconsider the orphan again because all parents are
...
πŸ’¬ furszy commented on pull request "index: initial sync speedup, parallelize process":
(https://github.com/bitcoin/bitcoin/pull/26966#issuecomment-3391433693)
> Left the fuzz target (`threadpool`) running overnight, performance is reasonable and didn't get any memory leak. I generated a coverage report at https://brunoerg.xyz/bitcoin-core-coverage/26966/coverage_report/.

Both awesome news! Added report link to the PR description. Thanks!