💬 ajtowns commented on issue "SENDTEMPLATE Tracking Issue":
(https://github.com/bitcoin/bitcoin/issues/33691#issuecomment-3612640676)
It looks like reusing compact block messages doesn't make sense -- including two blocks' worth of data seems pretty useful, but that could result in an ~8MB `blocktxns` data if your mempool was empty and the top of the mempool was full of inscriptions, which would in turn [exceed the 4MB maximum message size we have](https://github.com/bitcoin/bitcoin/pull/33191#pullrequestreview-3383627846). We could expand the maximum message size, but large messages can be a DoS vector, so splitting the templ
...
(https://github.com/bitcoin/bitcoin/issues/33691#issuecomment-3612640676)
It looks like reusing compact block messages doesn't make sense -- including two blocks' worth of data seems pretty useful, but that could result in an ~8MB `blocktxns` data if your mempool was empty and the top of the mempool was full of inscriptions, which would in turn [exceed the 4MB maximum message size we have](https://github.com/bitcoin/bitcoin/pull/33191#pullrequestreview-3383627846). We could expand the maximum message size, but large messages can be a DoS vector, so splitting the templ
...
💬 maflcko commented on pull request "util: generalize `util::Result` to support custom errors":
(https://github.com/bitcoin/bitcoin/pull/34005#issuecomment-3612682436)
> > So I think just porting a minimal `std::expected` seems easier?
> > So I did that in #34006
>
> Nice, that's more complicated than this PR, but not too bad. I don't have any particular preference between these two PR's. Either seem fine.
Yeah, it is a bit more code, but, the inner guts of `util::Expected` are mostly copy-pasted from the current `util::Result` in master, so it shouldn't be conceptually complicated.
(https://github.com/bitcoin/bitcoin/pull/34005#issuecomment-3612682436)
> > So I think just porting a minimal `std::expected` seems easier?
> > So I did that in #34006
>
> Nice, that's more complicated than this PR, but not too bad. I don't have any particular preference between these two PR's. Either seem fine.
Yeah, it is a bit more code, but, the inner guts of `util::Expected` are mostly copy-pasted from the current `util::Result` in master, so it shouldn't be conceptually complicated.
💬 pablomartin4btc commented on pull request "argsman, cli: GNU-style command-line option parsing (allows options after non-option arguments)":
(https://github.com/bitcoin/bitcoin/pull/33540#issuecomment-3612742963)
> > Restructuring `ProcessOptionKey` as below seems to solve the problem...
>
> Checking it... Thanks for the suggestion!
Ok, all tests pass...
First checked only the affected ones by my changes:
```
./build/test/functional/feature_config_args.py
./build/test/functional/tool_wallet.py
./build/test/functional/wallet_multiwallet.py
./build/test/functional/wallet_transactiontime_rescan.py
./build/bin/test_bitcoin --log_level=all --run_test=argsman_tests
```
Then I ran them al
...
(https://github.com/bitcoin/bitcoin/pull/33540#issuecomment-3612742963)
> > Restructuring `ProcessOptionKey` as below seems to solve the problem...
>
> Checking it... Thanks for the suggestion!
Ok, all tests pass...
First checked only the affected ones by my changes:
```
./build/test/functional/feature_config_args.py
./build/test/functional/tool_wallet.py
./build/test/functional/wallet_multiwallet.py
./build/test/functional/wallet_transactiontime_rescan.py
./build/bin/test_bitcoin --log_level=all --run_test=argsman_tests
```
Then I ran them al
...
💬 sedited commented on pull request "Add util::Expected (std::expected)":
(https://github.com/bitcoin/bitcoin/pull/34006#issuecomment-3612743633)
Concept ACK
(https://github.com/bitcoin/bitcoin/pull/34006#issuecomment-3612743633)
Concept ACK
💬 Sjors commented on pull request "Add util::Expected (std::expected)":
(https://github.com/bitcoin/bitcoin/pull/34006#issuecomment-3612759553)
Concept ACK
`FetchBlock()` is a good usage example.
(https://github.com/bitcoin/bitcoin/pull/34006#issuecomment-3612759553)
Concept ACK
`FetchBlock()` is a good usage example.
💬 fanquake commented on pull request "guix: use GCC 14.3.0 over 13.3.0":
(https://github.com/bitcoin/bitcoin/pull/33775#issuecomment-3612808384)
Minified a little more (https://github.com/fanquake/bitcoin/tree/repro_33775_minimal):
```cpp
#include <filesystem>
#include <string>
#include <vector>
#include <cstring> // Unused, but removing this makes it determinstic
namespace fs {
using namespace std::filesystem;
// Dummy class. Using "path = std::filesystem::path" makes it deterministic.
class path : public std::filesystem::path
{
public:
using std::filesystem::path::path;
path(std::filesystem::path path) :
...
(https://github.com/bitcoin/bitcoin/pull/33775#issuecomment-3612808384)
Minified a little more (https://github.com/fanquake/bitcoin/tree/repro_33775_minimal):
```cpp
#include <filesystem>
#include <string>
#include <vector>
#include <cstring> // Unused, but removing this makes it determinstic
namespace fs {
using namespace std::filesystem;
// Dummy class. Using "path = std::filesystem::path" makes it deterministic.
class path : public std::filesystem::path
{
public:
using std::filesystem::path::path;
path(std::filesystem::path path) :
...
💬 fanquake commented on issue "FUZZ=psbt in musig2, runs into uninitialized read":
(https://github.com/bitcoin/bitcoin/issues/33999#issuecomment-3612862383)
https://issues.oss-fuzz.com/issues/465913232.
(https://github.com/bitcoin/bitcoin/issues/33999#issuecomment-3612862383)
https://issues.oss-fuzz.com/issues/465913232.
💬 instagibbs commented on issue "RFC: when to drop testnet3":
(https://github.com/bitcoin/bitcoin/issues/31975#issuecomment-3612877414)
I'll steelman an even stronger suggestion: Don't drop testnet3?
What is the maintenance burden involved in keeping it around?
(https://github.com/bitcoin/bitcoin/issues/31975#issuecomment-3612877414)
I'll steelman an even stronger suggestion: Don't drop testnet3?
What is the maintenance burden involved in keeping it around?
💬 vasild commented on pull request "Broadcast own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2589593339)
Applied locally.
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2589593339)
Applied locally.
💬 vasild commented on pull request "Broadcast own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2589601292)
Applied locally.
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2589601292)
Applied locally.
💬 vasild commented on pull request "Broadcast own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2589631104)
I do not think so, but I cannot be 100% sure. What to do? Leave it as it is and revisit later if it ever becomes a problem?
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2589631104)
I do not think so, but I cannot be 100% sure. What to do? Leave it as it is and revisit later if it ever becomes a problem?
💬 mzumsande commented on issue "RFC: when to drop testnet3":
(https://github.com/bitcoin/bitcoin/issues/31975#issuecomment-3612930147)
> I'll steelman an even stronger suggestion: Don't drop testnet3?
>
> What is the maintenance burden involved in keeping it around?
I thought the hope was that it would deter scammers/shitcoiners from trying to establish a market for testnet coins when Bitcoin Core doesn't shy away from dropping support for the network.
(https://github.com/bitcoin/bitcoin/issues/31975#issuecomment-3612930147)
> I'll steelman an even stronger suggestion: Don't drop testnet3?
>
> What is the maintenance burden involved in keeping it around?
I thought the hope was that it would deter scammers/shitcoiners from trying to establish a market for testnet coins when Bitcoin Core doesn't shy away from dropping support for the network.
💬 maflcko commented on pull request "refactor: replace manual promise with SyncWithValidationInterfaceQueue":
(https://github.com/bitcoin/bitcoin/pull/33962#discussion_r2589784708)
Please just push the prior exact commit hash.
(https://github.com/bitcoin/bitcoin/pull/33962#discussion_r2589784708)
Please just push the prior exact commit hash.
💬 vasild commented on pull request "Broadcast own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2589789136)
Marking this as resolved as work on it continues at https://github.com/bitcoin/bitcoin/pull/33954
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2589789136)
Marking this as resolved as work on it continues at https://github.com/bitcoin/bitcoin/pull/33954
💬 vasild commented on pull request "Broadcast own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2589802670)
Was separated in a different commit.
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2589802670)
Was separated in a different commit.
👍 instagibbs approved a pull request: "chainparams: remove dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us"
(https://github.com/bitcoin/bitcoin/pull/33723#pullrequestreview-3540970909)
ACK b0c706795ce6a3a00bf068a81ee99fef2ee9bf7e
(https://github.com/bitcoin/bitcoin/pull/33723#pullrequestreview-3540970909)
ACK b0c706795ce6a3a00bf068a81ee99fef2ee9bf7e
🚀 fanquake merged a pull request: "chainparams: remove dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us"
(https://github.com/bitcoin/bitcoin/pull/33723)
(https://github.com/bitcoin/bitcoin/pull/33723)
💬 janb84 commented on pull request "depends: Propagate native C compiler to `sqlite` package":
(https://github.com/bitcoin/bitcoin/pull/33995#issuecomment-3613189801)
My Guix Build Output (matching)
**Host architecture:** `aarch64`
**Commit:** `710031ebef83`
```shell
5ea5588f1e2ee4e37f4b90313a8c32ec17474a39d1dff77d9d585ae9e106c761 guix-build-710031ebef83/output/aarch64-linux-gnu/SHA256SUMS.part
8d7b95ecb5950220f6d70c069d7fdf5add92f8135daee0d0acb9af753c9bab0c guix-build-710031ebef83/output/aarch64-linux-gnu/bitcoin-710031ebef83-aarch64-linux-gnu-debug.tar.gz
dd0f06c48c57e1243437298d02c219758ecd167c88d3a59be15a9051434a99cb guix-build-710031ebef83/
...
(https://github.com/bitcoin/bitcoin/pull/33995#issuecomment-3613189801)
My Guix Build Output (matching)
**Host architecture:** `aarch64`
**Commit:** `710031ebef83`
```shell
5ea5588f1e2ee4e37f4b90313a8c32ec17474a39d1dff77d9d585ae9e106c761 guix-build-710031ebef83/output/aarch64-linux-gnu/SHA256SUMS.part
8d7b95ecb5950220f6d70c069d7fdf5add92f8135daee0d0acb9af753c9bab0c guix-build-710031ebef83/output/aarch64-linux-gnu/bitcoin-710031ebef83-aarch64-linux-gnu-debug.tar.gz
dd0f06c48c57e1243437298d02c219758ecd167c88d3a59be15a9051434a99cb guix-build-710031ebef83/
...
💬 vasild commented on pull request "Broadcast own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2589857633)
I have not applied that patch back then. Looks like disconnecting early would unnecessary reveal the time when the originator received back the transaction from the network. So, leaving it as it as marking this as resolved. Feel free to comment if you disagree.
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2589857633)
I have not applied that patch back then. Looks like disconnecting early would unnecessary reveal the time when the originator received back the transaction from the network. So, leaving it as it as marking this as resolved. Feel free to comment if you disagree.
💬 vasild commented on pull request "Broadcast own transactions only via short-lived Tor or I2P connections":
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2589884418)
Marking as resolved, this code does not exist anymore.
(https://github.com/bitcoin/bitcoin/pull/29415#discussion_r2589884418)
Marking as resolved, this code does not exist anymore.