Bitcoin Core Github
44 subscribers
120K links
Download Telegram
πŸ’¬ ryanofsky commented on pull request "refactor / kernel: Move non-gArgs chainparams functionality to kernel":
(https://github.com/bitcoin/bitcoin/pull/26177#discussion_r1126506648)
In commit "Decouple RegTestChainParams from ArgsManager" (1cfccc38dd5d39a9e23a19b94d6ba1a7bc4c48dc)

string_view would work here, don't need a full string
πŸ’¬ ryanofsky commented on pull request "refactor / kernel: Move non-gArgs chainparams functionality to kernel":
(https://github.com/bitcoin/bitcoin/pull/26177#discussion_r1126541818)
In commit "Decouple RegTestChainParams from ArgsManager" (1cfccc38dd5d39a9e23a19b94d6ba1a7bc4c48dc)

I think this could say:

```c++
options.activation_heights[*maybe_dep] = height;
```

Would also suggest renaming `maybe_dep` to `buried_deployment`.

These are just style comments, but in general this the code in the first few commits of this PR seems a little bogged down in mechanics of optional and map types instead of fluently expressing application logic. This is c++ in 2023, not
...
πŸ’¬ ryanofsky commented on pull request "refactor / kernel: Move non-gArgs chainparams functionality to kernel":
(https://github.com/bitcoin/bitcoin/pull/26177#discussion_r1126666140)
In commit "Add factory functions for Main/Test/Sig/Reg chainparams" (2ec5cdb9e4884b75623a0cc4328ac78bd5d075c9)

I think this commit makes sense, but isn't explained very well. If the goal is to replace uses of `new` with `std::make_unique` you could do that without adding a bunch of factory methods. The reason new factory methods are needed is that the existing `CreateChainParams` factory method takes an `ArgsManager` parameter, so it can't be called by libbitcoin_kernel code. By constrast, th
...
πŸ’¬ ryanofsky commented on pull request "refactor / kernel: Move non-gArgs chainparams functionality to kernel":
(https://github.com/bitcoin/bitcoin/pull/26177#discussion_r1126623251)
In commit "Decouple RegTestChainParams from ArgsManager" (1cfccc38dd5d39a9e23a19b94d6ba1a7bc4c48dc)

Unnecessary diff here, somehow brace after `for` got moved to the next line. Could try using clang-format-diff to fix.
πŸ’¬ ryanofsky commented on pull request "refactor / kernel: Move non-gArgs chainparams functionality to kernel":
(https://github.com/bitcoin/bitcoin/pull/26177#discussion_r1126765676)
re: https://github.com/bitcoin/bitcoin/pull/26177#discussion_r980405199

In commit "split non/kernel chainparamsbase" (2f2216dee7a683638e6a3e966142f50f5de7df78)

I don't think it makes sense to have `BaseParams` in the kernel at all. `BaseParams` contains things like RPC port which are at a higher level than the kernel, and are used by things like `bitcoin-cli` code and `ArgsManager` code which shouldn't depend on the kernel (see https://github.com/bitcoin/bitcoin/blob/master/doc/design/libr
...
πŸ’¬ ryanofsky commented on pull request "refactor / kernel: Move non-gArgs chainparams functionality to kernel":
(https://github.com/bitcoin/bitcoin/pull/26177#discussion_r1126832163)
In commit "Split non/kernel chainparams" (4820450688e371a99d66cfad24714fa6e041e43e)

Is calling SetGlobalBaseParams() actually necessary here? I'm guessing something breaks if isn't added but it's not clear what. It'd be good drop the call or change the generic comment above "// SETUP: Misc Globals" into a specific comment about why it's needed currently, and maybe how it can go away in the future.
πŸ’¬ ryanofsky commented on pull request "refactor / kernel: Move non-gArgs chainparams functionality to kernel":
(https://github.com/bitcoin/bitcoin/pull/26177#discussion_r1126616994)
In commit "Decouple RegTestChainParams from ArgsManager" (1cfccc38dd5d39a9e23a19b94d6ba1a7bc4c48dc)

I think it would be better to change existing `UpdateActivationParametersFromArgs(args)` line to `UpdateActivationParametersFromOptions(options)` and have that function do this stuff, instead of moving more code into this giant constructor, especially when none of the other code in the constructor touches the options struct.
πŸ’¬ ryanofsky commented on pull request "refactor / kernel: Move non-gArgs chainparams functionality to kernel":
(https://github.com/bitcoin/bitcoin/pull/26177#discussion_r1126829031)
In commit "Split non/kernel chainparams" (4820450688e371a99d66cfad24714fa6e041e43e)

Existing `chainparams` variable is used exactly one place below so would suggest just writing `auto chainparams = CChainParams::Main();` and using it directly instead of having two similar variables.
πŸ’¬ dougEfresh commented on pull request "doc: Fixup remove 'omitted...' doc for rpc getrawtransaction when verbose is 2":
(https://github.com/bitcoin/bitcoin/pull/26968#issuecomment-1456693331)
@stickies-v I agree with your change, have pushed it to this PR.
Thanks
πŸ‘ hernanmarino approved a pull request: "Mask values on Transactions View"
(https://github.com/bitcoin-core/gui/pull/708)
Tested ACK 5fb3face477c30f576e14541550fcf64b17a94d6
πŸ’¬ Xekyo commented on pull request "Implement Mini version of BlockAssembler to calculate mining scores":
(https://github.com/bitcoin/bitcoin/pull/27021#discussion_r1126878745)
Yeah, the rename was meant to be in the first commit. Thanks
πŸ’¬ Xekyo commented on pull request "Implement Mini version of BlockAssembler to calculate mining scores":
(https://github.com/bitcoin/bitcoin/pull/27021#issuecomment-1456759368)
Moved rename of `GatherClusters(…)` to the right commit. Looking into the crash of the fuzzer.
πŸ’¬ stickies-v commented on pull request "doc: Fixup remove 'omitted...' doc for rpc getrawtransaction when verbose is 2":
(https://github.com/bitcoin/bitcoin/pull/26968#issuecomment-1456783035)
I think ci is failing because you didn't fully apply my commit:

<details>
<summary>git diff 3280c03 3ecb9458c05ac869bc2d77ea983bc85baf9baa07 -- src/rpc/rawtransaction.cpp</summary>

```diff
diff --git a/src/rpc/rawtransaction.cpp b/src/rpc/rawtransaction.cpp
index 21d49fda9..986e7c0cc 100644
--- a/src/rpc/rawtransaction.cpp
+++ b/src/rpc/rawtransaction.cpp
@@ -219,7 +219,7 @@ static RPCHelpMan getrawtransaction()
{RPCResult::Type::OBJ, "", "utxo bein
...
πŸ‘ john-moffett approved a pull request: "util: Use steady clock in SeedStrengthen, FindBestImplementation, FlushStateToDisk"
(https://github.com/bitcoin/bitcoin/pull/27189)
ACK fa1b4e5c3294fc9aec033892a4a4d7b5cfc015aa

Good conceptual change, as there's no reason for (eg) an NTP adjustment to affect these things.
πŸ’¬ furszy commented on pull request "Implement Mini version of BlockAssembler to calculate mining scores":
(https://github.com/bitcoin/bitcoin/pull/27021#discussion_r1126719573)
nit: this can just be `cluster.empty()`
πŸ’¬ furszy commented on pull request "Implement Mini version of BlockAssembler to calculate mining scores":
(https://github.com/bitcoin/bitcoin/pull/27021#discussion_r1126727129)
Could add above this line an early return:
```c++
if (txids.size > 500) return {};
```
πŸ’¬ furszy commented on pull request "Implement Mini version of BlockAssembler to calculate mining scores":
(https://github.com/bitcoin/bitcoin/pull/27021#discussion_r1126716115)
nit:
```c++
const txiter& tx_iter = clustered_txs.at(i);
for (const auto& entries : {tx_iter->GetMemPoolParentsConst(), tx_iter->GetMemPoolChildrenConst()}) {
for (const CTxMemPoolEntry& entry : entries) {
const auto entry_it = mapTx.iterator_to(entry);
if (!visited(entry_it)) {
clustered_txs.push_back(entry_it);
++to_process_count; // we still need to process this
}
}
}
```
πŸ’¬ furszy commented on pull request "Implement Mini version of BlockAssembler to calculate mining scores":
(https://github.com/bitcoin/bitcoin/pull/27021#discussion_r1126736075)
'outpoints' naming shadows the function's arg. Could
```c++
for (const auto& [txid, _] : m_requested_outpoints_by_txid) {
```
πŸ’¬ S3RK commented on pull request "wallet: group outputs only once, decouple it from Coin Selection":
(https://github.com/bitcoin/bitcoin/pull/25806#issuecomment-1456850195)
ReACK 6a302d4
Thanks for addressing feedback
πŸ“ amitiuttarwar opened a pull request: "p2p: Diversify automatic outbound connections with respect to networks"
(https://github.com/bitcoin/bitcoin/pull/27213)
This is joint work with mzumsande.

The current logic that makes automatic outbound connections doesn’t try to diversify with respect to reachable networks - the decision to connect to a particular address from `AddrMan` is based purely on the frequency of available addresses.

For instance, if `AddrMan` is populated primarily with IPv4 and IPv6 addresses and only a handful of onion addresses, it is likely that we won't establish any automatic outbound connections to Tor, even if we're cap
...