Bitcoin Core Github
43 subscribers
123K links
Download Telegram
💬 Sjors commented on pull request "Have createNewBlock() wait for tip, make rpc handle shutdown during long poll and wait methods":
(https://github.com/bitcoin/bitcoin/pull/31785#discussion_r1962152011)
Indeed, I was briefly confused about this, but there's no need to change it.
💬 jonatack commented on pull request "Revert merge of PR #31826":
(https://github.com/bitcoin/bitcoin/pull/31908#issuecomment-2669409844)
> (Why my approve button can't click?

I believe it was disabled for non-members of the repository because we were seeing too much spamming from that functionality.
💬 Sjors commented on pull request "Have createNewBlock() wait for tip, make rpc handle shutdown during long poll and wait methods":
(https://github.com/bitcoin/bitcoin/pull/31785#issuecomment-2669414096)
Addressed feedback and updated the PR description.
💬 theuni commented on pull request "cmake: Do not modify `CMAKE_TRY_COMPILE_TARGET_TYPE` globally":
(https://github.com/bitcoin/bitcoin/pull/31662#discussion_r1962175261)
Probably not here. IIRC hebasto split this out of a larger commit. Agree that it's confusing, but since it's resolved later I'm not too worried. I'd say it's up to hebasto if he wants to fix it for the sake of history or not.
💬 ismaelsadeeq commented on pull request "mining: drop unused -nFees and sigops from CBlockTemplate":
(https://github.com/bitcoin/bitcoin/pull/31897#issuecomment-2669440541)
> block.vtx contains a dummy coinbase, vTxFees and vTxSigOpsCost contain dummy fees and dummy sigop cost

Good point.

> That seems more straight forward to me than having vTxFees be shorter and then having to document why these things have different lengths.


We don't have to document that `vTxFees` is just a vector of fees paid in the block.

Note: This is an unblocking comment.

This PR is an immediate win because we don't have to perform checks like we do in https://github.com/bi
...
glozow closed a pull request: "random: move VerifyRNDRRS above InitHardwareRand"
(https://github.com/bitcoin/bitcoin/pull/31902)
💬 glozow commented on pull request "random: move VerifyRNDRRS above InitHardwareRand":
(https://github.com/bitcoin/bitcoin/pull/31902#issuecomment-2669472019)
Closing since #31908 was merged.
💬 glozow commented on issue "GetRandBytes() Hangs on Samsung Galaxy S25 and OnePlus 13":
(https://github.com/bitcoin/bitcoin/issues/31817#issuecomment-2669479367)
Has not been fixed since #31908 reverted #31826, but also out of scope - see https://github.com/bitcoin/bitcoin/pull/31908#issuecomment-2669309907. I believe this should stay closed.
🤔 pablomartin4btc reviewed a pull request: "doc: update translation generation cmake example"
(https://github.com/bitcoin/bitcoin/pull/31731#pullrequestreview-2627689858)
ACK 79eb14003f42e1329fe3cdc17a42023c8b2d14b9

If we want to use the `dev-mode` preset perhaps we need to build `/depends` with `MULTIPROCESS=1`, as the preset has `"WITH_MULTIPROCESS": "ON",`. Please consider #31899 as it fixes the existent problem with multiprocess built.

We should add `-DWITH_USDT=OFF` (fails on mac otherwise) as @hebasto [confirmed](https://github.com/bitcoin/bitcoin/pull/31731#discussion_r1935753074) it won't affect the translation.

Just for reference, translation g
...
📝 Lynn-Matini opened a pull request: "Testing Matini"
(https://github.com/bitcoin/bitcoin/pull/31909)
Currently testing the PR assignment. No issue ID yet😊
💬 pinheadmz commented on pull request "guix: Notarize MacOS app bundle and codesign all MacOS and Windows binaries":
(https://github.com/bitcoin/bitcoin/pull/31407#issuecomment-2669518794)
I'm having an issue codesigning:

```

--> ./detached-sig-create.sh <...>p12 <...>p8 <...UUID...>

WARNING: Part of the file was not parsed: 37428 bytes
Enter the passphrase for /Volumes/safe2/bitcoin-core-csk/Archive/cert@bitcoincorecodesigning.org.p12:
Enter the passphrase for /Volumes/safe2/bitcoin-core-csk/app_store_connect_api_key/AuthKey_5ZTN3N6A87.p8:
WARNING: Part of the file was not parsed: 37428 bytes
Code signature created
WARNING: Part of the file was not parsed: 37428 byt
...
theuni closed a pull request: "Testing Matini"
(https://github.com/bitcoin/bitcoin/pull/31909)
💬 theuni commented on pull request "Testing Matini":
(https://github.com/bitcoin/bitcoin/pull/31909#issuecomment-2669539171)
Please don't clog our c-i/review pipelines with senseless PRs.
💬 mzumsande commented on pull request "wallet: fix crash on double block disconnection":
(https://github.com/bitcoin/bitcoin/pull/31757#discussion_r1962235520)
"Ensure the tx is still abandoned and the wallet has no balance" sounds too positive to me - the test comment should say clearly that this is a bug in master and the wallet is showing the wrong balance because it incorrectly treats a tx which is in the current chain as abandoned (even if it doesn't crash anymore).
💬 sipa commented on pull request "Add waitNext() to BlockTemplate interface":
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1962248389)
What is the rationale for this creating and returning a *new* `BlockTemplate` object, as opposed to replacing the current (`*this`) one? As far as I can see the current one becomes useless, as its `m_block_template` will be outdated, so future calls to `waitNext` for it will return instantly anyway.
💬 l0rinc commented on pull request "doc: update translation generation cmake example":
(https://github.com/bitcoin/bitcoin/pull/31731#discussion_r1962279607)
Added back `-DWITH_USDT=OFF`
💬 l0rinc commented on pull request "doc: update translation generation cmake example":
(https://github.com/bitcoin/bitcoin/pull/31731#issuecomment-2669606517)
Thanks @pablomartin4btc for the review, I've added back `-DWITH_USDT=OFF`
💬 l0rinc commented on pull request "refactor: modernize outdated trait patterns using helper aliases (C++14/C++17)":
(https://github.com/bitcoin/bitcoin/pull/31904#discussion_r1962284588)
Pushed https://github.com/llvm/llvm-project/pull/127811 and reverted the file here, thanks!
💬 ryanofsky commented on pull request "Add waitNext() to BlockTemplate interface":
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1962302827)
> As far as I can see the current one becomes useless, as its `m_block_template` will be outdated, so future calls to `waitNext` for it will return instantly anyway.

This should not be the case. This returns a pointer to a new block template so miners are able to mine with the old one while calling this.
💬 sipa commented on pull request "Add waitNext() to BlockTemplate interface":
(https://github.com/bitcoin/bitcoin/pull/31283#discussion_r1962305664)
Sure, while calling `waitNext`, but after it returns, isn't it the case that the current `BlockTemplate` becomes useless?