💬 pinheadmz commented on issue "Decouple datacarrier size and count limits (Draft PR)":
(https://github.com/bitcoin/bitcoin/issues/33595#issuecomment-3387885398)
I just don't understand the motivation. v30 users can set `-datacarriersize=83` to keep the previous policy.
(https://github.com/bitcoin/bitcoin/issues/33595#issuecomment-3387885398)
I just don't understand the motivation. v30 users can set `-datacarriersize=83` to keep the previous policy.
💬 sdaftuar commented on pull request "Cluster mempool implementation":
(https://github.com/bitcoin/bitcoin/pull/28676#discussion_r2418251935)
I took a stab at eliminating `-limitancestorsize` and `-limitdescendantsize`, emitting a warning if those command line options are used, and eliminating all usages of DEFAULT_ANCESTOR_SIZE and DEFAULT_DESCENDANT_SIZE in #33591.
(https://github.com/bitcoin/bitcoin/pull/28676#discussion_r2418251935)
I took a stab at eliminating `-limitancestorsize` and `-limitdescendantsize`, emitting a warning if those command line options are used, and eliminating all usages of DEFAULT_ANCESTOR_SIZE and DEFAULT_DESCENDANT_SIZE in #33591.
💬 andrewtoth commented on pull request "coins: fix `cachedCoinsUsage` accounting in `CCoinsViewCache`":
(https://github.com/bitcoin/bitcoin/pull/32313#discussion_r2418258249)
Yes. `coin` is an rvalue, so it is already moved out of the caller. `inserted` should always be true anyways.
(https://github.com/bitcoin/bitcoin/pull/32313#discussion_r2418258249)
Yes. `coin` is an rvalue, so it is already moved out of the caller. `inserted` should always be true anyways.
🤔 Yasararf reviewed a pull request: "Add warning and documentation for -bind with Tor hidden services (#33…"
(https://github.com/bitcoin/bitcoin/pull/33596#pullrequestreview-3321049048)
Previously, users who attempted to use --bind in combination with Tor hidden services did not receive any warning or reference to secure configuration practices.
This led to misconfiguration risks, such as exposing sensitive endpoints or incorrectly binding interfaces.
(https://github.com/bitcoin/bitcoin/pull/33596#pullrequestreview-3321049048)
Previously, users who attempted to use --bind in combination with Tor hidden services did not receive any warning or reference to secure configuration practices.
This led to misconfiguration risks, such as exposing sensitive endpoints or incorrectly binding interfaces.
🤔 Yasararf reviewed a pull request: "Add warning and documentation for -bind with Tor hidden services (#33…"
(https://github.com/bitcoin/bitcoin/pull/33596#pullrequestreview-3321052229)
This PR adds comprehensive documentation for integrating Datadog logging within the application. The new content provides step-by-step instructions to enable Datadog logging, configuration examples, and best practices for monitoring application performance and logs.
(https://github.com/bitcoin/bitcoin/pull/33596#pullrequestreview-3321052229)
This PR adds comprehensive documentation for integrating Datadog logging within the application. The new content provides step-by-step instructions to enable Datadog logging, configuration examples, and best practices for monitoring application performance and logs.
💬 miked348 commented on issue "Witness scripts being abused to bypass datacarriersize limit (CVE-2023-50428)":
(https://github.com/bitcoin/bitcoin/issues/29187#issuecomment-3387977140)
Concept ACK – Restricting MAX_OP_RETURN_RELAY reinforces Bitcoin’s monetary purpose and protects blockspace.
(https://github.com/bitcoin/bitcoin/issues/29187#issuecomment-3387977140)
Concept ACK – Restricting MAX_OP_RETURN_RELAY reinforces Bitcoin’s monetary purpose and protects blockspace.
💬 Dorex45 commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-3387986021)
@earonesty
That’s a valid perspective, and I agree that decentralization and censorship resistance are core to Bitcoin. My point is that restricting block size alone doesn’t necessarily strengthen those properties it just limits access and scalability. Sidechains like CoreDAO aren’t “ecosystems of tokens,” but extensions that maintain Bitcoin’s security assumptions while enabling additional functionality off-chain. This separation keeps Bitcoin lean as a settlement layer while allowing innovat
...
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-3387986021)
@earonesty
That’s a valid perspective, and I agree that decentralization and censorship resistance are core to Bitcoin. My point is that restricting block size alone doesn’t necessarily strengthen those properties it just limits access and scalability. Sidechains like CoreDAO aren’t “ecosystems of tokens,” but extensions that maintain Bitcoin’s security assumptions while enabling additional functionality off-chain. This separation keeps Bitcoin lean as a settlement layer while allowing innovat
...
💬 jotapea commented on issue "Decouple datacarrier size and count limits (Draft PR)":
(https://github.com/bitcoin/bitcoin/issues/33595#issuecomment-3387998723)
The **motivation** is respect the consensus. `-datacarriersize=83` isn't even the default any more.
The **usefulness** is control of the number of inputs separated from the size per input. Having both be one is sloppy. This is a new feature, which should be configurable.
The new config would be simple, seen from v30.1:
For same policy as v30.0 / Libre Relay
```conf
datacarrier=1
datacarriersize=0
datacarrierlimit=0
```
Defaults proposed for v30.1 (same result as historical consensus)
```con
...
(https://github.com/bitcoin/bitcoin/issues/33595#issuecomment-3387998723)
The **motivation** is respect the consensus. `-datacarriersize=83` isn't even the default any more.
The **usefulness** is control of the number of inputs separated from the size per input. Having both be one is sloppy. This is a new feature, which should be configurable.
The new config would be simple, seen from v30.1:
For same policy as v30.0 / Libre Relay
```conf
datacarrier=1
datacarriersize=0
datacarrierlimit=0
```
Defaults proposed for v30.1 (same result as historical consensus)
```con
...
💬 luke-jr commented on pull request "node: change a tx-relay on/off flag to enum":
(https://github.com/bitcoin/bitcoin/pull/33567#discussion_r2418346583)
Probably should use class enums for new things?
(https://github.com/bitcoin/bitcoin/pull/33567#discussion_r2418346583)
Probably should use class enums for new things?
💬 GrayHatGuy commented on pull request "node: change a tx-relay on/off flag to enum":
(https://github.com/bitcoin/bitcoin/pull/33567#discussion_r2418418837)
Keep your pron outta my money
(https://github.com/bitcoin/bitcoin/pull/33567#discussion_r2418418837)
Keep your pron outta my money
💬 GrayHatGuy commented on issue "Decouple datacarrier size and count limits (Draft PR)":
(https://github.com/bitcoin/bitcoin/issues/33595#issuecomment-3388173535)
This is a perfect paper trail for the litigious
(https://github.com/bitcoin/bitcoin/issues/33595#issuecomment-3388173535)
This is a perfect paper trail for the litigious
💬 GrayHatGuy commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-3388175078)
> @earonesty
>
> That’s a valid perspective, and I agree that decentralization and censorship resistance are core to Bitcoin. My point is that restricting block size alone doesn’t necessarily strengthen those properties it just limits access and scalability. Sidechains like CoreDAO aren’t “ecosystems of tokens,” but extensions that maintain Bitcoin’s security assumptions while enabling additional functionality off-chain. This separation keeps Bitcoin lean as a settlement layer while allowing i
...
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-3388175078)
> @earonesty
>
> That’s a valid perspective, and I agree that decentralization and censorship resistance are core to Bitcoin. My point is that restricting block size alone doesn’t necessarily strengthen those properties it just limits access and scalability. Sidechains like CoreDAO aren’t “ecosystems of tokens,” but extensions that maintain Bitcoin’s security assumptions while enabling additional functionality off-chain. This separation keeps Bitcoin lean as a settlement layer while allowing i
...
📝 sivamurugan90428 opened a pull request: "Change in argh.h"
(https://github.com/bitcoin/bitcoin/pull/33597)
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:
* Any test improvements or new tests that improv
...
(https://github.com/bitcoin/bitcoin/pull/33597)
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:
* Any test improvements or new tests that improv
...
📝 HARISHVIJAY006 opened a pull request: "notes"
(https://github.com/bitcoin/bitcoin/pull/33598)
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:
* Any test improvements or new tests that improv
...
(https://github.com/bitcoin/bitcoin/pull/33598)
<!--
*** Please remove the following help text before submitting: ***
Pull requests without a rationale and clear improvement may be closed
immediately.
GUI-related pull requests should be opened against
https://github.com/bitcoin-core/gui
first. See CONTRIBUTING.md
-->
<!--
Please provide clear motivation for your patch and explain how it improves
Bitcoin Core user experience or Bitcoin Core developer experience
significantly:
* Any test improvements or new tests that improv
...
✅ achow101 closed a pull request: "Change in argh.h"
(https://github.com/bitcoin/bitcoin/pull/33597)
(https://github.com/bitcoin/bitcoin/pull/33597)
✅ maflcko closed a pull request: "Add warning and documentation for -bind with Tor hidden services (#33…"
(https://github.com/bitcoin/bitcoin/pull/33596)
(https://github.com/bitcoin/bitcoin/pull/33596)
💬 maflcko commented on pull request "Add warning and documentation for -bind with Tor hidden services (#33…":
(https://github.com/bitcoin/bitcoin/pull/33596#issuecomment-3388399645)
Closing as a low-quality (and obviously wrong) LLM generated bot/spam patch, with an (obviously wrong) hallucinated explanation, without any test coverage or otherwise steps to test, and finally test failures in the existing tests.
If you wish to contribute in the future, please focus on creating high-quality, original content that demonstrates a clear understanding of the project's requirements and goals. Also, see the [contributing guidelines](https://github.com/bitcoin/bitcoin/blob/master/
...
(https://github.com/bitcoin/bitcoin/pull/33596#issuecomment-3388399645)
Closing as a low-quality (and obviously wrong) LLM generated bot/spam patch, with an (obviously wrong) hallucinated explanation, without any test coverage or otherwise steps to test, and finally test failures in the existing tests.
If you wish to contribute in the future, please focus on creating high-quality, original content that demonstrates a clear understanding of the project's requirements and goals. Also, see the [contributing guidelines](https://github.com/bitcoin/bitcoin/blob/master/
...
💬 maflcko commented on pull request "guix: Use UCRT runtime for Windows release binaries":
(https://github.com/bitcoin/bitcoin/pull/33593#discussion_r2418596746)
Is there a rationale why upstream guix does not offer ucrt?
(https://github.com/bitcoin/bitcoin/pull/33593#discussion_r2418596746)
Is there a rationale why upstream guix does not offer ucrt?
⚠️ maflcko opened an issue: "Intermittent CI network issue downloading assets.json from GitHub"
(https://github.com/bitcoin/bitcoin/issues/33599)
CI frequently fails lately intermittently due to a network issue: https://github.com/bitcoin/bitcoin/actions/runs/18389269290/job/52395485037?pr=33592#step:9:518
As the infra was changed to run on someone else's sever, I don't know how to debug this or how to fix it.
(https://github.com/bitcoin/bitcoin/issues/33599)
CI frequently fails lately intermittently due to a network issue: https://github.com/bitcoin/bitcoin/actions/runs/18389269290/job/52395485037?pr=33592#step:9:518
As the infra was changed to run on someone else's sever, I don't know how to debug this or how to fix it.
💬 maflcko commented on pull request "[WIP] doc: update Guix install instructions":
(https://github.com/bitcoin/bitcoin/pull/33574#issuecomment-3388445684)
> that this might be a bad indicator for the guix project overall?
The LWN article concludes that "Regular releases" are planned, so it is likely that the situation will improve and possibly make backporting bugfixes easier in the future. So in theory, the guix package could make its way back into Debian/Ubuntu.
(https://github.com/bitcoin/bitcoin/pull/33574#issuecomment-3388445684)
> that this might be a bad indicator for the guix project overall?
The LWN article concludes that "Regular releases" are planned, so it is likely that the situation will improve and possibly make backporting bugfixes easier in the future. So in theory, the guix package could make its way back into Debian/Ubuntu.