💬 sr-gi commented on pull request "net: Add new permission `forceinbound` to evict a random unprotected connection if all slots are otherwise full":
(https://github.com/bitcoin/bitcoin/pull/27600#issuecomment-1877748000)
I feel like this makes sense conceptually, but I have similar concerns to @stickies-v @mzumsande and @naumenkogs with it.
If we could approach this without the need to introduce an additional permission I'd be happier, since it seems a big change for a narrow use case with a potential workaround by just accepting more than 38 total connections (plus `N` for the nobans). I also wonder how this plays out with #27114, given this would be an `in` only permission.
Given this only triggers und
...
(https://github.com/bitcoin/bitcoin/pull/27600#issuecomment-1877748000)
I feel like this makes sense conceptually, but I have similar concerns to @stickies-v @mzumsande and @naumenkogs with it.
If we could approach this without the need to introduce an additional permission I'd be happier, since it seems a big change for a narrow use case with a potential workaround by just accepting more than 38 total connections (plus `N` for the nobans). I also wonder how this plays out with #27114, given this would be an `in` only permission.
Given this only triggers und
...
💬 LarryRuane commented on pull request "bitcoin-cli help detail to show full help for all RPCs":
(https://github.com/bitcoin/bitcoin/pull/29163#issuecomment-1877751909)
> Concept NACK on the top commit: having each one in a separate file is nice.
I can remove it, but may I ask why, I assume that the purpose of the test writing to the files is in case something goes wrong in the formatting of the strings (and the test fails), the files might help the developer identify the problem. (Otherwise why not just write to `/dev/null`, which would still test the string formatting?) When the test completes successfully, all these files are deleted anyway.
If this PR
...
(https://github.com/bitcoin/bitcoin/pull/29163#issuecomment-1877751909)
> Concept NACK on the top commit: having each one in a separate file is nice.
I can remove it, but may I ask why, I assume that the purpose of the test writing to the files is in case something goes wrong in the formatting of the strings (and the test fails), the files might help the developer identify the problem. (Otherwise why not just write to `/dev/null`, which would still test the string formatting?) When the test completes successfully, all these files are deleted anyway.
If this PR
...
💬 achow101 commented on pull request "wallet: Keep track of the wallet's own transaction outputs in memory":
(https://github.com/bitcoin/bitcoin/pull/27286#discussion_r1442251493)
Good catch, fixed.
(https://github.com/bitcoin/bitcoin/pull/27286#discussion_r1442251493)
Good catch, fixed.
💬 achow101 commented on pull request "wallet: Keep track of the wallet's own transaction outputs in memory":
(https://github.com/bitcoin/bitcoin/pull/27286#discussion_r1442251567)
Done
(https://github.com/bitcoin/bitcoin/pull/27286#discussion_r1442251567)
Done
💬 brunoerg commented on pull request "p2p: Allow whitelisting outgoing connections":
(https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1442254458)
I don't think so because it's expected to not modify `nLocalServices`. Doesn't it?
```cpp
/**
* Services this node offers.
*
* This data is replicated in each Peer instance we create.
*
* This data is not marked const, but after being set it should not
* change.
*
* \sa Peer::our_services
*/
ServiceFlags nLocalServices;
```
(https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1442254458)
I don't think so because it's expected to not modify `nLocalServices`. Doesn't it?
```cpp
/**
* Services this node offers.
*
* This data is replicated in each Peer instance we create.
*
* This data is not marked const, but after being set it should not
* change.
*
* \sa Peer::our_services
*/
ServiceFlags nLocalServices;
```
💬 brunoerg commented on pull request "p2p: Allow whitelisting outgoing connections":
(https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1442254695)
I will address it in the next push.
(https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1442254695)
I will address it in the next push.
💬 brunoerg commented on pull request "p2p: Allow whitelisting outgoing connections":
(https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1442255302)
I don't think so because some tests rely on `-whitelist` for other purposes.
(https://github.com/bitcoin/bitcoin/pull/27114#discussion_r1442255302)
I don't think so because some tests rely on `-whitelist` for other purposes.
💬 hebasto commented on pull request "refactor: Make CWalletTx sync state type-safe":
(https://github.com/bitcoin/bitcoin/pull/21206#discussion_r1442259732)
As for Clang, this explicit deduction guide can be dropped for versions >=17 only, unfortunately.
(https://github.com/bitcoin/bitcoin/pull/21206#discussion_r1442259732)
As for Clang, this explicit deduction guide can be dropped for versions >=17 only, unfortunately.
📝 luke-jr opened a pull request: "RPC/Blockchain: scanblocks: Accept named param for filter_false_positives"
(https://github.com/bitcoin/bitcoin/pull/29184)
Possibly due to a silent cross-merge, `scanblocks` was left out of 96233146dd31c1d99fd1619be4449944623ef750
(https://github.com/bitcoin/bitcoin/pull/29184)
Possibly due to a silent cross-merge, `scanblocks` was left out of 96233146dd31c1d99fd1619be4449944623ef750
💬 sipa commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1877812112)
Concept NACK.
I do not believe this to be in the interest of users of our software. The point of participating in transaction relay and having a mempool is being able to make a prediction about what the next blocks will look like. Intentionally excluding transactions for which a very clear (however stupid) economic demand exists breaks that ability, without even removing the need to validate them when they get mined.
Of course, anyone is free to run, or provide, software that relays/keeps/
...
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1877812112)
Concept NACK.
I do not believe this to be in the interest of users of our software. The point of participating in transaction relay and having a mempool is being able to make a prediction about what the next blocks will look like. Intentionally excluding transactions for which a very clear (however stupid) economic demand exists breaks that ability, without even removing the need to validate them when they get mined.
Of course, anyone is free to run, or provide, software that relays/keeps/
...
💬 dzyphr commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1877852201)
>Intentionally excluding transactions for which a very clear (however stupid) economic demand exists breaks that ability, without even removing the need to validate them when they get mined.
I would agree on this point's premise however to me it is not clear that this PR attempts to do this, it applies the same standard of datacarrier cost to transactions that currently do not encounter it and makes exceeding the limit nonstandard which is a policy used to deter other kinds of unwanted transa
...
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1877852201)
>Intentionally excluding transactions for which a very clear (however stupid) economic demand exists breaks that ability, without even removing the need to validate them when they get mined.
I would agree on this point's premise however to me it is not clear that this PR attempts to do this, it applies the same standard of datacarrier cost to transactions that currently do not encounter it and makes exceeding the limit nonstandard which is a policy used to deter other kinds of unwanted transa
...
💬 achow101 commented on pull request "test: wallet rescan with reorged parent + IsFromMe child in mempool":
(https://github.com/bitcoin/bitcoin/pull/29179#issuecomment-1877879833)
Huh, looks like this behavior has been broken since it was introduced in #15652
(https://github.com/bitcoin/bitcoin/pull/29179#issuecomment-1877879833)
Huh, looks like this behavior has been broken since it was introduced in #15652
💬 achow101 commented on pull request "fuzz: rule-out too deep derivation paths in descriptor parsing targets":
(https://github.com/bitcoin/bitcoin/pull/28832#issuecomment-1877881661)
ACK a44808fb437864878c2d9696b8a96193091446ee
(https://github.com/bitcoin/bitcoin/pull/28832#issuecomment-1877881661)
ACK a44808fb437864878c2d9696b8a96193091446ee
🚀 achow101 merged a pull request: "fuzz: rule-out too deep derivation paths in descriptor parsing targets"
(https://github.com/bitcoin/bitcoin/pull/28832)
(https://github.com/bitcoin/bitcoin/pull/28832)
💬 achow101 commented on pull request "test: wallet rescan with reorged parent + IsFromMe child in mempool":
(https://github.com/bitcoin/bitcoin/pull/29179#issuecomment-1877892122)
ACK 1a52ca7619eeb1baafa5a32b364381126862b29d
(https://github.com/bitcoin/bitcoin/pull/29179#issuecomment-1877892122)
ACK 1a52ca7619eeb1baafa5a32b364381126862b29d
💬 eragmus commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1877957720)
> >Intentionally excluding transactions for which a very clear (however stupid) economic demand exists breaks that ability, without even removing the need to validate them when they get mined.
>
>
>
> I would agree on this point's premise however to me it is not clear that this PR attempts to do this, it applies the same standard of datacarrier cost to transactions that currently do not encounter it and makes exceeding the limit nonstandard which is a policy used to deter other kinds of unwan
...
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1877957720)
> >Intentionally excluding transactions for which a very clear (however stupid) economic demand exists breaks that ability, without even removing the need to validate them when they get mined.
>
>
>
> I would agree on this point's premise however to me it is not clear that this PR attempts to do this, it applies the same standard of datacarrier cost to transactions that currently do not encounter it and makes exceeding the limit nonstandard which is a policy used to deter other kinds of unwan
...
💬 BitcoinMechanic commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1877963374)
> To the extent that this is an attempt to not just not _see_ certain transactions, but also to _discourage_ their use, this will at best cause those transactions to be routed around nodes implementing this, or at worst result in a practice of transactions submitted directly to miners, which has serious risks for the centralization of mining. While non-standardness has historically been used to discourage burdensome practices, I believe this is (a) far less relevant these days where full blocks
...
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1877963374)
> To the extent that this is an attempt to not just not _see_ certain transactions, but also to _discourage_ their use, this will at best cause those transactions to be routed around nodes implementing this, or at worst result in a practice of transactions submitted directly to miners, which has serious risks for the centralization of mining. While non-standardness has historically been used to discourage burdensome practices, I believe this is (a) far less relevant these days where full blocks
...
💬 eragmus commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1877964372)
> >Intentionally excluding transactions for which a very clear (however stupid) economic demand exists breaks that ability, without even removing the need to validate them when they get mined.
>
>
>
> I would agree on this point's premise however to me it is not clear that this PR attempts to do this, it applies the same standard of datacarrier cost to transactions that currently do not encounter it and makes exceeding the limit nonstandard which is a policy used to deter other kinds of unwan
...
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1877964372)
> >Intentionally excluding transactions for which a very clear (however stupid) economic demand exists breaks that ability, without even removing the need to validate them when they get mined.
>
>
>
> I would agree on this point's premise however to me it is not clear that this PR attempts to do this, it applies the same standard of datacarrier cost to transactions that currently do not encounter it and makes exceeding the limit nonstandard which is a policy used to deter other kinds of unwan
...
💬 dzyphr commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1877974758)
"It only deterred it in the past, due to lack of economic demand. 36.2% of 2023's fees came from non-traditional txs, so we no longer live in the old era that lacked demand.
And the discount with segwit, if that's what you mean, does the opposite of creating incentive to increase the UTXO set."
You are again using the word demand completely ambitiously, there is little to no evidence that these are organic or sustainable flows of Bitcoin funding scam protocols. You are free to prove that
...
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1877974758)
"It only deterred it in the past, due to lack of economic demand. 36.2% of 2023's fees came from non-traditional txs, so we no longer live in the old era that lacked demand.
And the discount with segwit, if that's what you mean, does the opposite of creating incentive to increase the UTXO set."
You are again using the word demand completely ambitiously, there is little to no evidence that these are organic or sustainable flows of Bitcoin funding scam protocols. You are free to prove that
...
💬 luke-jr commented on pull request "datacarriersize: Match more datacarrying":
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1878045521)
> The point of participating in transaction relay and having a mempool is being able to make a prediction about what the next blocks will look like.
No, it is not and never has been. The closest it comes to that, is the point of *influencing* what the next blocks will look like, as you said yourself years ago to justify Compact Blocks.
Predicting the next block can only ever be a possibility if you assume a centralized mining ecosystem, something to actively work against.
>Of course, an
...
(https://github.com/bitcoin/bitcoin/pull/28408#issuecomment-1878045521)
> The point of participating in transaction relay and having a mempool is being able to make a prediction about what the next blocks will look like.
No, it is not and never has been. The closest it comes to that, is the point of *influencing* what the next blocks will look like, as you said yourself years ago to justify Compact Blocks.
Predicting the next block can only ever be a possibility if you assume a centralized mining ecosystem, something to actively work against.
>Of course, an
...