💬 hebasto commented on pull request "depends, doc: Learn `x86_64-w64-mingw32ucrt` host and document it":
(https://github.com/bitcoin/bitcoin/pull/33857#discussion_r2547970130)
Given that full UCRT-capable toolchains are not yet available across all major distributions, developers on Ubuntu, for example, may still want to build for `x86_64-w64-mingw32`.
(https://github.com/bitcoin/bitcoin/pull/33857#discussion_r2547970130)
Given that full UCRT-capable toolchains are not yet available across all major distributions, developers on Ubuntu, for example, may still want to build for `x86_64-w64-mingw32`.
💬 l0rinc commented on pull request "precalculate SipHash constant salt XORs":
(https://github.com/bitcoin/bitcoin/pull/30442#discussion_r2548060905)
Done
(https://github.com/bitcoin/bitcoin/pull/30442#discussion_r2548060905)
Done
💬 l0rinc commented on pull request "precalculate SipHash constant salt XORs":
(https://github.com/bitcoin/bitcoin/pull/30442#discussion_r2548060973)
Added some comments, please check them out
(https://github.com/bitcoin/bitcoin/pull/30442#discussion_r2548060973)
Added some comments, please check them out
💬 l0rinc commented on pull request "precalculate SipHash constant salt XORs":
(https://github.com/bitcoin/bitcoin/pull/30442#discussion_r2548061021)
Added something like this, thanks
(https://github.com/bitcoin/bitcoin/pull/30442#discussion_r2548061021)
Added something like this, thanks
💬 l0rinc commented on pull request "precalculate SipHash constant salt XORs":
(https://github.com/bitcoin/bitcoin/pull/30442#discussion_r2548061081)
Did something similar in a new commit, what do you think?
(https://github.com/bitcoin/bitcoin/pull/30442#discussion_r2548061081)
Did something similar in a new commit, what do you think?
💬 l0rinc commented on pull request "precalculate SipHash constant salt XORs":
(https://github.com/bitcoin/bitcoin/pull/30442#discussion_r2548061274)
Added the explanation to the commit message as well
(https://github.com/bitcoin/bitcoin/pull/30442#discussion_r2548061274)
Added the explanation to the commit message as well
📝 fjahr opened a pull request: "Export embedded ASMap RPC"
(https://github.com/bitcoin/bitcoin/pull/33920)
This depends on the embedded data PR itself (#28792), until merge this will remain in draft status. All commit but the last one are from there.
There has been interest in exporting the embedded data back into a file. This is implemented here with a simple `exportasmap` RPC which provides this functionality. The exported file can be used to verify the data integrity or statistical analysis using e.g. `contrib/asmap-tool.py`.
(https://github.com/bitcoin/bitcoin/pull/33920)
This depends on the embedded data PR itself (#28792), until merge this will remain in draft status. All commit but the last one are from there.
There has been interest in exporting the embedded data back into a file. This is implemented here with a simple `exportasmap` RPC which provides this functionality. The exported file can be used to verify the data integrity or statistical analysis using e.g. `contrib/asmap-tool.py`.
🤔 w0xlt reviewed a pull request: "argsman, cli: GNU-style command-line option parsing (allows options after non-option arguments)"
(https://github.com/bitcoin/bitcoin/pull/33540#pullrequestreview-3490620415)
Restructuring `ProcessOptionKey` as below seems to solve the problem of `./build/bin/bitcoin-cli --datadir=/tmp/btc1 --signet getblockhash 1000`.
```cpp
bool ArgsManager::ProcessOptionKey(std::string& key, std::optional<std::string>& val, std::string& error, const bool found_after_non_option) {
bool double_dash{false};
const std::optional<std::string> original_val{val};
std::string original_input{key};
if (val) original_input += "=" + *val;
// Normalize leading das
...
(https://github.com/bitcoin/bitcoin/pull/33540#pullrequestreview-3490620415)
Restructuring `ProcessOptionKey` as below seems to solve the problem of `./build/bin/bitcoin-cli --datadir=/tmp/btc1 --signet getblockhash 1000`.
```cpp
bool ArgsManager::ProcessOptionKey(std::string& key, std::optional<std::string>& val, std::string& error, const bool found_after_non_option) {
bool double_dash{false};
const std::optional<std::string> original_val{val};
std::string original_input{key};
if (val) original_input += "=" + *val;
// Normalize leading das
...
💬 glozow commented on pull request "Cluster mempool":
(https://github.com/bitcoin/bitcoin/pull/33629#issuecomment-3560795513)
ACK 3fb3c230c93
(https://github.com/bitcoin/bitcoin/pull/33629#issuecomment-3560795513)
ACK 3fb3c230c93
💬 glozow commented on pull request "Cluster mempool followups":
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2519792868)
I think these functions should actually require the lock to already be held. They are only called from `MemPoolAccept` so this is always true.
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2519792868)
I think these functions should actually require the lock to already be held. They are only called from `MemPoolAccept` so this is always true.
💬 glozow commented on pull request "Cluster mempool followups":
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2519723491)
cec26203732ce3883e7e014f954ccd73c3c0099d: The function signature in chain.h still calls this `descendants`
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2519723491)
cec26203732ce3883e7e014f954ccd73c3c0099d: The function signature in chain.h still calls this `descendants`
💬 glozow commented on pull request "Cluster mempool followups":
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2519646193)
Now that the feerate diagram outputs weight, the sanity check can be stronger:
```diff
diff --git a/src/txmempool.cpp b/src/txmempool.cpp
index 472ed581145..0be261ad964 100644
--- a/src/txmempool.cpp
+++ b/src/txmempool.cpp
@@ -418,6 +418,8 @@ void CTxMemPool::check(const CCoinsViewCache& active_coins_tip, int64_t spendhei
uint64_t checkTotal = 0;
CAmount check_total_fee{0};
+ CAmount check_total_modified_fee{0};
+ int32_t check_total_adjusted_weight{0};
uint
...
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2519646193)
Now that the feerate diagram outputs weight, the sanity check can be stronger:
```diff
diff --git a/src/txmempool.cpp b/src/txmempool.cpp
index 472ed581145..0be261ad964 100644
--- a/src/txmempool.cpp
+++ b/src/txmempool.cpp
@@ -418,6 +418,8 @@ void CTxMemPool::check(const CCoinsViewCache& active_coins_tip, int64_t spendhei
uint64_t checkTotal = 0;
CAmount check_total_fee{0};
+ CAmount check_total_modified_fee{0};
+ int32_t check_total_adjusted_weight{0};
uint
...
💬 glozow commented on pull request "Cluster mempool followups":
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2519846231)
Is this supposed to be the name of the param?
```suggestion
uint256 hash = ParseHashV(request.params[0], "txid");
```
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2519846231)
Is this supposed to be the name of the param?
```suggestion
uint256 hash = ParseHashV(request.params[0], "txid");
```
💬 glozow commented on pull request "Cluster mempool followups":
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2519835223)
nit: missing parens
Also, I wonder if it would be confusing that an RPC result named "weight" is adjusted in some RPCs but not in others... should we be calling this "adjusted_weight" ? Or perhaps "clusterweight" and "chunkweight" are enough to indicate that this is in the mempool context and thus not just BIP 141 weight.
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2519835223)
nit: missing parens
Also, I wonder if it would be confusing that an RPC result named "weight" is adjusted in some RPCs but not in others... should we be calling this "adjusted_weight" ? Or perhaps "clusterweight" and "chunkweight" are enough to indicate that this is in the mempool context and thus not just BIP 141 weight.
💬 glozow commented on pull request "Cluster mempool followups":
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2519515632)
```suggestion
// Use ChangeSet interface to check whether the cluster count
// limits would be violated. Note that the changeset will be destroyed
// when it goes out of scope.
```
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2519515632)
```suggestion
// Use ChangeSet interface to check whether the cluster count
// limits would be violated. Note that the changeset will be destroyed
// when it goes out of scope.
```
💬 glozow commented on pull request "Cluster mempool followups":
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2535383593)
57cb99c82504693601709eeb47eba9cd7ab7e387 requires that `GetCluster` output txns in a deterministic order, which could be worth documenting.
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2535383593)
57cb99c82504693601709eeb47eba9cd7ab7e387 requires that `GetCluster` output txns in a deterministic order, which could be worth documenting.
💬 sdaftuar commented on pull request "Cluster mempool":
(https://github.com/bitcoin/bitcoin/pull/33629#issuecomment-3560813571)
@glozow I actually have one concern around the value of POST_CHANGE_WORK; I think I'm going to suggest we drop it to `5 * ACCEPTABLE_ITERS` to avoid using too much CPU when encountering a cluster that our current linearization code cannot quickly find an optimal ordering.
(Likely this concern will go away completely with SFL (#32545), so I'm doing some benchmarks with and without that code to make sure things look good.)
(https://github.com/bitcoin/bitcoin/pull/33629#issuecomment-3560813571)
@glozow I actually have one concern around the value of POST_CHANGE_WORK; I think I'm going to suggest we drop it to `5 * ACCEPTABLE_ITERS` to avoid using too much CPU when encountering a cluster that our current linearization code cannot quickly find an optimal ordering.
(Likely this concern will go away completely with SFL (#32545), so I'm doing some benchmarks with and without that code to make sure things look good.)
💬 glozow commented on pull request "Cluster mempool followups":
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2548163119)
Some documentation that could be worth having in doc/policy/ ?
### Fee and Size Terminology in Mempool Policy
- Each transaction has a **weight** and virtual size as defined in BIP 141 (different from serialized size for witness
transactions as witness data is discounted and the value is rounded up to the nearest integer).
- In the RPCs, "weight" refers to the weight as defined in BIP 141.
- A transaction has a **sigops size**, defined as its sigop cost multiplied by the node's
...
(https://github.com/bitcoin/bitcoin/pull/33591#discussion_r2548163119)
Some documentation that could be worth having in doc/policy/ ?
### Fee and Size Terminology in Mempool Policy
- Each transaction has a **weight** and virtual size as defined in BIP 141 (different from serialized size for witness
transactions as witness data is discounted and the value is rounded up to the nearest integer).
- In the RPCs, "weight" refers to the weight as defined in BIP 141.
- A transaction has a **sigops size**, defined as its sigop cost multiplied by the node's
...
⚠️ byLAEV opened an issue: "Maximum Bitcoin price based on LAEV "
(https://github.com/bitcoin-core/gui/issues/912)
@gregwebs @ldenman @casey @eklitzke @rion @diegoviola @diegoviola @richardkiss @Empact @lian @petertodd @Sjors @witten @nothingmuch @vegard @takinbo
It's very simple, the electronic banking money system has a functional basis and worldwide adoption.Bitcoin was created to be electronic money exactly like traditional bank money with the only difference bein
...
(https://github.com/bitcoin-core/gui/issues/912)
@gregwebs @ldenman @casey @eklitzke @rion @diegoviola @diegoviola @richardkiss @Empact @lian @petertodd @Sjors @witten @nothingmuch @vegard @takinbo
It's very simple, the electronic banking money system has a functional basis and worldwide adoption.Bitcoin was created to be electronic money exactly like traditional bank money with the only difference bein
...
⚠️ byLAEV opened an issue: "100k Bitcoin price: compelling fundamentals "
(https://github.com/bitcoin-core/gui/issues/913)
@gregwebs @ldenman @casey @eklitzke @rion @diegoviola @diegoviola @richardkiss @Empact @lian @petertodd @Sjors @witten @nothingmuch @vegard @takinbo
)
It's very simple, the electronic banking money system has a functional basis and worldwide adoption.Bitcoin was created to be electronic money exactly like traditional bank money with the only difference being that it prevents double spending and is decentralized.Therefore, the value of the satoshi should not be linked to values like 0.001 or 0.
...
(https://github.com/bitcoin-core/gui/issues/913)
@gregwebs @ldenman @casey @eklitzke @rion @diegoviola @diegoviola @richardkiss @Empact @lian @petertodd @Sjors @witten @nothingmuch @vegard @takinbo
)
It's very simple, the electronic banking money system has a functional basis and worldwide adoption.Bitcoin was created to be electronic money exactly like traditional bank money with the only difference being that it prevents double spending and is decentralized.Therefore, the value of the satoshi should not be linked to values like 0.001 or 0.
...