Bitcoin Core Github
44 subscribers
121K links
Download Telegram
⚠️ badergithub opened an issue: "Only"
(https://github.com/bitcoin/bitcoin/issues/29135)
hebasto closed an issue: "Only"
(https://github.com/bitcoin/bitcoin/issues/29135)
:lock: hebasto locked an issue: "."
(https://github.com/bitcoin/bitcoin/issues/29135)
💬 murchandamus commented on pull request "Add Gutter Guard Selector":
(https://github.com/bitcoin/bitcoin/pull/28977#discussion_r1435289402)
I combined the two loops
🤔 murchandamus reviewed a pull request: "Add Gutter Guard Selector"
(https://github.com/bitcoin/bitcoin/pull/28977#pullrequestreview-1794849255)
Addressed comments by @achow101
💬 murchandamus commented on issue "fuzz, coinselection: Assertion 'result_bnb->GetChange(coin_params.m_cost_of_change, CAmount{0}) == 0' failed":
(https://github.com/bitcoin/bitcoin/issues/28918#issuecomment-1868003060)
I think that this should be fixed with the merge of #28372
dergoegge closed an issue: "fuzz, coinselection: Assertion 'result_bnb->GetChange(coin_params.m_cost_of_change, CAmount{0}) == 0' failed"
(https://github.com/bitcoin/bitcoin/issues/28918)
💬 TheCharlatan commented on pull request "indexes: Stop using node internal types and locking cs_main, improve sync logic":
(https://github.com/bitcoin/bitcoin/pull/24230#issuecomment-1868061457)
Concept ACK
💬 conduition commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1868073814)
> I heard from a guy who runs various inscription businesses that he even tried to do it offchain, but users were not interested in saving money on the offchain tx fee by sacrificing the benefits of onchain; users were only interested when he did it onchain.

@eragmus Woah. That speaks volumes about the users who are paying these exorbitant fees. Thanks for that account.
👍 alfonsoromanz approved a pull request: "Fix: Ensure 'Transaction View' remains disabled if no wallet is selected"
(https://github.com/bitcoin-core/gui/pull/780#pullrequestreview-1795194240)
Tested ACK https://github.com/bitcoin-core/gui/pull/780/commits/b2e531e70a88f5c9e1c055ae7341520a3128e15d

![Screen Recording 2023-12-22 at 18 24 11](https://github.com/bitcoin-core/gui/assets/19962151/0d60ca21-54bf-4a30-9814-bcc2be997275)
💬 maaku commented on pull request "Use hardened runtime on macOS release builds.":
(https://github.com/bitcoin/bitcoin/pull/29127#issuecomment-1868124202)
It's a step that only needs to be done once, on an Apple device. I'm not aware of any open source alternatives.
💬 maaku commented on issue "macOS App Notarization":
(https://github.com/bitcoin/bitcoin/issues/15774#issuecomment-1868125416)
> If so, how can it distinguish notarized+not_stapled vs not_notarized applications?

You've hit the nail on the head: notarized+not_stapled !notarized apps are bit-for-bit identical. It phones home for all applications being run, except those with stapled notary (maybe, this is disputed above).
💬 Farnoosh85 commented on issue "ci: failure in `wallet_basic.py --descriptors`":
(https://github.com/bitcoin/bitcoin/issues/29110#issuecomment-1868125550)
> https://cirrus-ci.com/task/5898005006516224?logs=ci#L2515:
>
> ```bash
>
> _20231218_134952/wallet_basic_259/node0/regtest/wallets/default_wallet/wallet.dat] SQLite Statement: ROLLBACK TRANSACTION
>
> node0 2023-12-18T13:53:29.193915Z [scheduler] [wallet/sqlite.cpp:400] [Close] SQLiteBatch: Batch closed unexpectedly without the transaction being explicitly committed or aborted
>
> node0 2023-12-18T13:53:29.194038Z [scheduler] [wallet/sqlite.cpp:53] [TraceSqlCallback] [/ci_container_bas
...
📝 achow101 opened a pull request: "wallet: `addhdkey` RPC to add just keys to wallets via new `void(KEY)` descriptor"
(https://github.com/bitcoin/bitcoin/pull/29136)
It is sometimes useful for the wallet to have keys that it can sign with but are not (initially) involved in any scripts, e.g. for setting up a multisig. Ryanofsky [suggested](https://github.com/bitcoin/bitcoin/pull/26728#issuecomment-1867721948) A `void(KEY)` descriptor which allows for a key to be specified, but produces no scripts. These can be imported into the wallet, and subsequently retrieved with `gethdkeys`. Additionally, `listdescriptors` will output these descriptors so that they can
...
🤔 ryanofsky reviewed a pull request: "wallet: Add `createwalletdescriptor` and `gethdkeys` RPCs for adding new automatically generated descriptors"
(https://github.com/bitcoin/bitcoin/pull/29130#pullrequestreview-1795206875)
Concept ACK 08b9b414d9f4b4b65bf5ec0ff875889997631a79. I think I'm maybe halfway through reviewing, but here are my comments so far.
💬 ryanofsky commented on pull request "wallet: Add `createwalletdescriptor` and `gethdkeys` RPCs for adding new automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/29130#discussion_r1435355508)
In commit "desc spkm: Add functions to retrieve specific private keys" (484711baa994d482110edaf510377181b8b2b465)

It looks like this function would be a little more flexible and efficient if took a CKeyID parameter instead of a CPubKey
💬 ryanofsky commented on pull request "wallet: Add `createwalletdescriptor` and `gethdkeys` RPCs for adding new automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/29130#discussion_r1435366492)
In commit "wallet, rpc: Add gethdkeys RPC" (5deafad2f61f626b50b6c173558ac7236cceff13)

Would suggest making these name-only parameters to avoid different bool options being confused with each other, and to leave room to add new positional parameters in the future. You could do this with:

```diff
--- a/src/rpc/client.cpp
+++ b/src/rpc/client.cpp
@@ -274,8 +274,9 @@ static const CRPCConvertParam vRPCConvertParams[] =
{ "logging", 1, "exclude" },
{ "disconnectnode", 1, "nodeid"
...
💬 ryanofsky commented on pull request "wallet: Add `createwalletdescriptor` and `gethdkeys` RPCs for adding new automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/29130#discussion_r1435368965)
In commit "wallet, rpc: Add gethdkeys RPC" (5deafad2f61f626b50b6c173558ac7236cceff13)

Note: This is better than what I suggested. I was originally thinking this default should be true, to make it more convenient to get active hd key and ignore other keys. But defaulting to false is actually better, because it's still easy to get the active hd key with an option, and it's probably more confusing to see missing keys than extra keys. Also this default makes `gethdkeys` output more consistent wit
...
💬 ryanofsky commented on pull request "wallet: Add `createwalletdescriptor` and `gethdkeys` RPCs for adding new automatically generated descriptors":
(https://github.com/bitcoin/bitcoin/pull/29130#discussion_r1435372329)
In commit "wallet, rpc: Add gethdkeys RPC" (5deafad2f61f626b50b6c173558ac7236cceff13)

This is just general style feedback, but I think where possible it's better to use `auto&` or `auto*` instead of bare `auto` because with bare `auto` in c++, you don't know if a potentially expensive object copy will happen without manually checking the type. With `auto&` or `auto*` you know there won't be an big copy without having to think about it. Up to you though if you prefer less verbosity instead