🚀 fanquake merged a pull request: "p2p: do not make automatic outbound connections to addnode peers"
(https://github.com/bitcoin/bitcoin/pull/28895)
(https://github.com/bitcoin/bitcoin/pull/28895)
🚀 fanquake merged a pull request: "depends: bump libmultiprocess to fix capnproto deprecation warnings"
(https://github.com/bitcoin/bitcoin/pull/28907)
(https://github.com/bitcoin/bitcoin/pull/28907)
💬 ajtowns commented on pull request "Use serialization parameters for CTransaction":
(https://github.com/bitcoin/bitcoin/pull/28438#discussion_r1401931286)
If the issue is the separation between the `CNetAddr::SerParams` declaration and the `MultiSerParams(..,CNetAddr::V2,..)` use, could instead make it:
```c++
class MultiSerParam
{
public:
template<typename T>
operator T&() const { return T::GetIPCSerParams(); }
};
constexpr MultiSerParam INTERNAL_SER_PARAMS;
class CNetAddr {
struct SerParams {
const Encoding enc;
static SerParams GetIPCSerParams() { return {Encoding::V2}; }
SER_PARAMS_OPFUNC
...
(https://github.com/bitcoin/bitcoin/pull/28438#discussion_r1401931286)
If the issue is the separation between the `CNetAddr::SerParams` declaration and the `MultiSerParams(..,CNetAddr::V2,..)` use, could instead make it:
```c++
class MultiSerParam
{
public:
template<typename T>
operator T&() const { return T::GetIPCSerParams(); }
};
constexpr MultiSerParam INTERNAL_SER_PARAMS;
class CNetAddr {
struct SerParams {
const Encoding enc;
static SerParams GetIPCSerParams() { return {Encoding::V2}; }
SER_PARAMS_OPFUNC
...
💬 fanquake commented on pull request "ci: Avoid toolset ambiguity that MSVC can't handle":
(https://github.com/bitcoin/bitcoin/pull/28905#issuecomment-1822634582)
Added to #28872 for backporting.
(https://github.com/bitcoin/bitcoin/pull/28905#issuecomment-1822634582)
Added to #28872 for backporting.
💬 fanquake commented on pull request "p2p: do not make automatic outbound connections to addnode peers":
(https://github.com/bitcoin/bitcoin/pull/28895#issuecomment-1822635615)
Added the fix to #28872 for backporting.
(https://github.com/bitcoin/bitcoin/pull/28895#issuecomment-1822635615)
Added the fix to #28872 for backporting.
👍 hebasto approved a pull request: "[26.x] Changes for rc3"
(https://github.com/bitcoin/bitcoin/pull/28872#pullrequestreview-1744270748)
ACK 740a85ce5f25f2282e32f148d61f92301bef7179, I've verified backports locally, also reviewed changes related to the `-par` option and `rc2` --> `rc3` as well.
(https://github.com/bitcoin/bitcoin/pull/28872#pullrequestreview-1744270748)
ACK 740a85ce5f25f2282e32f148d61f92301bef7179, I've verified backports locally, also reviewed changes related to the `-par` option and `rc2` --> `rc3` as well.
💬 hebasto commented on pull request "[26.x] Changes for rc3":
(https://github.com/bitcoin/bitcoin/pull/28872#discussion_r1401975084)
nit:
```suggestion
- The transaction list in the GUI no longer provides a special category for "payment to yourself". Now transactions that have both inputs and outputs that affect the wallet are displayed on separate lines for spending and receiving. (gui#119)
```
I apologize for the wrong Grammar in my initial suggestion.
(https://github.com/bitcoin/bitcoin/pull/28872#discussion_r1401975084)
nit:
```suggestion
- The transaction list in the GUI no longer provides a special category for "payment to yourself". Now transactions that have both inputs and outputs that affect the wallet are displayed on separate lines for spending and receiving. (gui#119)
```
I apologize for the wrong Grammar in my initial suggestion.
📝 willcl-ark opened a pull request: "rpc: add 'getnetmsgstats' RPC"
(https://github.com/bitcoin/bitcoin/pull/28926)
This picks up #27534 with a rebase and a few fixups, unsquashed for consideration. See #27534 for more background information.
Considerations from the previous draft:
> Should we allow dimensions to be rearraged?
>
> When it comes time to gather up the RPC results, @vasild has provided an [alternate implementation](https://github.com/vasild/bitcoin/commits/getnetmsgstats) that uses an array instead of the MultiMap structure. This results in two changes:
>
>> using the stack over the
...
(https://github.com/bitcoin/bitcoin/pull/28926)
This picks up #27534 with a rebase and a few fixups, unsquashed for consideration. See #27534 for more background information.
Considerations from the previous draft:
> Should we allow dimensions to be rearraged?
>
> When it comes time to gather up the RPC results, @vasild has provided an [alternate implementation](https://github.com/vasild/bitcoin/commits/getnetmsgstats) that uses an array instead of the MultiMap structure. This results in two changes:
>
>> using the stack over the
...
👍 TheCharlatan approved a pull request: "Fee Estimator updates from Validation Interface/CScheduler thread"
(https://github.com/bitcoin/bitcoin/pull/28368#pullrequestreview-1744286806)
Re-ACK 91504cbe0de2b74ef1aa2709761aaf0597ec66a2
(https://github.com/bitcoin/bitcoin/pull/28368#pullrequestreview-1744286806)
Re-ACK 91504cbe0de2b74ef1aa2709761aaf0597ec66a2
💬 Sjors commented on pull request "wallet: batch all individual spkms setup db writes in a single db txn":
(https://github.com/bitcoin/bitcoin/pull/28894#issuecomment-1822850560)
re-utACK f05302427386fe63f4929a7198652cb1e4ab3bcc
CI failure seems spurious
(https://github.com/bitcoin/bitcoin/pull/28894#issuecomment-1822850560)
re-utACK f05302427386fe63f4929a7198652cb1e4ab3bcc
CI failure seems spurious
💬 maflcko commented on pull request "blockstorage: XOR blocksdir *.dat files":
(https://github.com/bitcoin/bitcoin/pull/28052#issuecomment-1822887374)
rebased
(https://github.com/bitcoin/bitcoin/pull/28052#issuecomment-1822887374)
rebased
💬 dergoegge commented on pull request "multiprocess: Add basic type conversion hooks":
(https://github.com/bitcoin/bitcoin/pull/28921#discussion_r1401997881)
I'm gonna try to summarize my understanding of this to make sure I actually got it right.
We want this specialization of `CustomBuildField` for (most) of our serializable types. So we can either define it manually for each type or we can make use of sfinae (like you do here) to automatically only create the specialization for each of the required serializable types.
We also want to be able to further overload `CustomBuildField` for serializable types that can't use this generic specializat
...
(https://github.com/bitcoin/bitcoin/pull/28921#discussion_r1401997881)
I'm gonna try to summarize my understanding of this to make sure I actually got it right.
We want this specialization of `CustomBuildField` for (most) of our serializable types. So we can either define it manually for each type or we can make use of sfinae (like you do here) to automatically only create the specialization for each of the required serializable types.
We also want to be able to further overload `CustomBuildField` for serializable types that can't use this generic specializat
...
⚠️ quakemmo opened an issue: "importing a wallet containing an hdseed overwrites target wallet hdseed"
(https://github.com/bitcoin/bitcoin/issues/28927)
### Is there an existing issue for this?
- [X] I have searched the existing issues
### Current behaviour
My basic idea was to have two nodes running with the same keys, if one fails, I can just rescan the blockchain on the other one and failover to it seamlessly.
I made a wallet on Node1, generated a few thousands addresses, saved the dumpwallet. Now I want to import the same keys to Node2, but I want it to be an HD wallet from the same seed, to avoid the headache of sendtoaddress, when
...
(https://github.com/bitcoin/bitcoin/issues/28927)
### Is there an existing issue for this?
- [X] I have searched the existing issues
### Current behaviour
My basic idea was to have two nodes running with the same keys, if one fails, I can just rescan the blockchain on the other one and failover to it seamlessly.
I made a wallet on Node1, generated a few thousands addresses, saved the dumpwallet. Now I want to import the same keys to Node2, but I want it to be an HD wallet from the same seed, to avoid the headache of sendtoaddress, when
...
🤔 vasild reviewed a pull request: "rpc: add 'getnetmsgstats' RPC"
(https://github.com/bitcoin/bitcoin/pull/28926#pullrequestreview-1744577141)
Concept ACK
I was looking at this recently, and got some ideas how to simplify and better organize this, will share here. Thanks for taking charge!
(https://github.com/bitcoin/bitcoin/pull/28926#pullrequestreview-1744577141)
Concept ACK
I was looking at this recently, and got some ideas how to simplify and better organize this, will share here. Thanks for taking charge!
💬 vasild commented on pull request "rpc: add 'getnetmsgstats' RPC":
(https://github.com/bitcoin/bitcoin/pull/28926#discussion_r1402168125)
All these plus the `NUM_NET_MESSAGE_TYPES` constant can be avoided if the list of all message types is turned into a `std::array`. Consider this:
<details>
<summary>[patch] make the list of known message types a compile time constant</summary>
```diff
diff --git a/src/net.cpp b/src/net.cpp
index a2f80cbcf7..133abae117 100644
--- a/src/net.cpp
+++ b/src/net.cpp
@@ -3670,13 +3670,13 @@ CNode::CNode(NodeId idIn,
nLocalHostNonce{nLocalHostNonceIn},
m_recv_flood_size{node_
...
(https://github.com/bitcoin/bitcoin/pull/28926#discussion_r1402168125)
All these plus the `NUM_NET_MESSAGE_TYPES` constant can be avoided if the list of all message types is turned into a `std::array`. Consider this:
<details>
<summary>[patch] make the list of known message types a compile time constant</summary>
```diff
diff --git a/src/net.cpp b/src/net.cpp
index a2f80cbcf7..133abae117 100644
--- a/src/net.cpp
+++ b/src/net.cpp
@@ -3670,13 +3670,13 @@ CNode::CNode(NodeId idIn,
nLocalHostNonce{nLocalHostNonceIn},
m_recv_flood_size{node_
...
💬 kevkevinpal commented on pull request "mempool / rpc: followup to getprioritisedtransactions and delete a mapDeltas entry when delta==0":
(https://github.com/bitcoin/bitcoin/pull/28885#discussion_r1402210346)
updated the commit message in [9a918a4](https://github.com/bitcoin/bitcoin/pull/28885/commits/9a918a4720ee091344a16dcd703d169ebdb7938e)
I also fixed the other ones that had refactor in the commit message since they weren't really refactors either
(https://github.com/bitcoin/bitcoin/pull/28885#discussion_r1402210346)
updated the commit message in [9a918a4](https://github.com/bitcoin/bitcoin/pull/28885/commits/9a918a4720ee091344a16dcd703d169ebdb7938e)
I also fixed the other ones that had refactor in the commit message since they weren't really refactors either
💬 kevkevinpal commented on pull request "mempool / rpc: followup to getprioritisedtransactions and delete a mapDeltas entry when delta==0":
(https://github.com/bitcoin/bitcoin/pull/28885#discussion_r1402215512)
thanks! fixed in [e3f2fc0](https://github.com/bitcoin/bitcoin/pull/28885/commits/e3f2fc026a705148221de1bd0ecb37a26c3a4b36)
(https://github.com/bitcoin/bitcoin/pull/28885#discussion_r1402215512)
thanks! fixed in [e3f2fc0](https://github.com/bitcoin/bitcoin/pull/28885/commits/e3f2fc026a705148221de1bd0ecb37a26c3a4b36)
👍 pablomartin4btc approved a pull request: "coins: make sure PoolAllocator uses the correct alignment"
(https://github.com/bitcoin/bitcoin/pull/28913#pullrequestreview-1744665014)
Tested ACK d5b4c0b69e543de51bb37d602d488ee0949ba185
<details>
<summary>Reproduced the issue on <code>master</code> using emulated ARM 32 getting the OOM at height
318617.</summary>
```
2023-11-22T08:24:03Z UpdateTip: new best=00000000000000001771de0c2dc0ff95d619943d4160308c93f9184fcee8d5f8 height=318617 version=0x00000002 log2_work=80.467750 tx=45766401 date='2014-09-01T14:44:48Z' progress=0.049383 cache=107.7MiB(14296037txo)
[44951.075682] b-addcon invoked oom-killer: gfp_mask=0x140cc
...
(https://github.com/bitcoin/bitcoin/pull/28913#pullrequestreview-1744665014)
Tested ACK d5b4c0b69e543de51bb37d602d488ee0949ba185
<details>
<summary>Reproduced the issue on <code>master</code> using emulated ARM 32 getting the OOM at height
318617.</summary>
```
2023-11-22T08:24:03Z UpdateTip: new best=00000000000000001771de0c2dc0ff95d619943d4160308c93f9184fcee8d5f8 height=318617 version=0x00000002 log2_work=80.467750 tx=45766401 date='2014-09-01T14:44:48Z' progress=0.049383 cache=107.7MiB(14296037txo)
[44951.075682] b-addcon invoked oom-killer: gfp_mask=0x140cc
...
💬 ryanofsky commented on pull request "multiprocess: Add basic type conversion hooks":
(https://github.com/bitcoin/bitcoin/pull/28921#discussion_r1402240033)
> As I understand it, this comment implies that (without `&& std::is_same_v<LocalType, std::remove_cv_t<std::remove_reference_t<LocalType>>>`) the following would not take precedence, even though it has `Priority<2>`?
>
> ```c++
> template <typename LocalType, typename Output>
> void CustomBuildField(TypeList<LocalType>, Priority<2>, InvokeContext& invoke_context, const CTransaction& value, Output&& output)
> ```
Yes that's right, but it would be more correct to say "would not *reliably
...
(https://github.com/bitcoin/bitcoin/pull/28921#discussion_r1402240033)
> As I understand it, this comment implies that (without `&& std::is_same_v<LocalType, std::remove_cv_t<std::remove_reference_t<LocalType>>>`) the following would not take precedence, even though it has `Priority<2>`?
>
> ```c++
> template <typename LocalType, typename Output>
> void CustomBuildField(TypeList<LocalType>, Priority<2>, InvokeContext& invoke_context, const CTransaction& value, Output&& output)
> ```
Yes that's right, but it would be more correct to say "would not *reliably
...
🤔 pablomartin4btc reviewed a pull request: "getrawtransaction implementation"
(https://github.com/bitcoin-core/gui/pull/777#pullrequestreview-1744793504)
Concept ACK
As @luke-jr perhaps we can create a separate menu item like "Tools" or "Utils" with this feature in it (and would be more suitable if we need to add for example other features as @willcl-ark [mentioned](https://github.com/bitcoin-core/gui/pull/777#issuecomment-1810068057)).
Light CR.
(https://github.com/bitcoin-core/gui/pull/777#pullrequestreview-1744793504)
Concept ACK
As @luke-jr perhaps we can create a separate menu item like "Tools" or "Utils" with this feature in it (and would be more suitable if we need to add for example other features as @willcl-ark [mentioned](https://github.com/bitcoin-core/gui/pull/777#issuecomment-1810068057)).
Light CR.