💬 laanwj commented on pull request "cmake: Add application manifests when cross-compiling for Windows":
(https://github.com/bitcoin/bitcoin/pull/32396#discussion_r2073462754)
Also mind that newer verions of LIEF completely reorganize these constants (it's called `lief.PE.ResourcesManager.TYPE.MANIFEST` now). Had to figure out what it was called for this version then it didn't even work as-is.
(https://github.com/bitcoin/bitcoin/pull/32396#discussion_r2073462754)
Also mind that newer verions of LIEF completely reorganize these constants (it's called `lief.PE.ResourcesManager.TYPE.MANIFEST` now). Had to figure out what it was called for this version then it didn't even work as-is.
💬 TheCharlatan commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2851053267)
Concept ACK
I think I'd prefer keeping the option until #32401 is addressed. Clearly there seems to be at least some demand for mining on charitable templates, if this is worth the additional code and maintenance is another discussion.
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2851053267)
Concept ACK
I think I'd prefer keeping the option until #32401 is addressed. Clearly there seems to be at least some demand for mining on charitable templates, if this is worth the additional code and maintenance is another discussion.
👍 TheCharlatan approved a pull request: "build: replace header checks with `__has_include`"
(https://github.com/bitcoin/bitcoin/pull/32405#pullrequestreview-2814879581)
ACK e1f543823b300b28c9edaf5d1a3e1e9badde471b
```
66d71c866bd111ffe65bc03b9e1653a95eb678f0b04451759c56af868bfc03d5 guix-build-e1f543823b30/output/aarch64-linux-gnu/SHA256SUMS.part
1a4130d801620a63d86c3069b1fbca39ebc963e610101451d3f48b1c191ca4b3 guix-build-e1f543823b30/output/aarch64-linux-gnu/bitcoin-e1f543823b30-aarch64-linux-gnu-debug.tar.gz
745adbc7767344a8cd0ebe1e7592239614d89f949558c9b6a2ae58f7b2602a32 guix-build-e1f543823b30/output/aarch64-linux-gnu/bitcoin-e1f543823b30-aarch64-lin
...
(https://github.com/bitcoin/bitcoin/pull/32405#pullrequestreview-2814879581)
ACK e1f543823b300b28c9edaf5d1a3e1e9badde471b
```
66d71c866bd111ffe65bc03b9e1653a95eb678f0b04451759c56af868bfc03d5 guix-build-e1f543823b30/output/aarch64-linux-gnu/SHA256SUMS.part
1a4130d801620a63d86c3069b1fbca39ebc963e610101451d3f48b1c191ca4b3 guix-build-e1f543823b30/output/aarch64-linux-gnu/bitcoin-e1f543823b30-aarch64-linux-gnu-debug.tar.gz
745adbc7767344a8cd0ebe1e7592239614d89f949558c9b6a2ae58f7b2602a32 guix-build-e1f543823b30/output/aarch64-linux-gnu/bitcoin-e1f543823b30-aarch64-lin
...
🤔 musaHaruna reviewed a pull request: "mining: rename gbt_force and gbt_force_name"
(https://github.com/bitcoin/bitcoin/pull/32386#pullrequestreview-2814893880)
ACK [5e87c3e](https://github.com/bitcoin/bitcoin/pull/32386/commits/5e87c3ec094d68a7a27dfb7ae665b225ff4dfdb6)
After reading [BIP9](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki#getblocktemplate-changes), I think variable rename from gbt_force to gbt_optional_rule makes the intent and purpose clear as it's stated in the specification
(https://github.com/bitcoin/bitcoin/pull/32386#pullrequestreview-2814893880)
ACK [5e87c3e](https://github.com/bitcoin/bitcoin/pull/32386/commits/5e87c3ec094d68a7a27dfb7ae665b225ff4dfdb6)
After reading [BIP9](https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki#getblocktemplate-changes), I think variable rename from gbt_force to gbt_optional_rule makes the intent and purpose clear as it's stated in the specification
💬 wizkid057 commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2851096930)
Concept NACK
Reasons outlined on mailing list and other PR
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2851096930)
Concept NACK
Reasons outlined on mailing list and other PR
💬 instagibbs commented on issue "rfc: separate relay from mining policy":
(https://github.com/bitcoin/bitcoin/issues/32401#issuecomment-2851104827)
If everyone relays but doesn't mine, this is also free relay, no? This is where sprinkling in some PoW helps like weak blocks.
(https://github.com/bitcoin/bitcoin/issues/32401#issuecomment-2851104827)
If everyone relays but doesn't mine, this is also free relay, no? This is where sprinkling in some PoW helps like weak blocks.
💬 Sjors commented on pull request "mining: rename gbt_force and gbt_force_name":
(https://github.com/bitcoin/bitcoin/pull/32386#issuecomment-2851110317)
@musaHaruna it looks like you checked an outdated hash.
(https://github.com/bitcoin/bitcoin/pull/32386#issuecomment-2851110317)
@musaHaruna it looks like you checked an outdated hash.
💬 BitcoinMechanic commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2851140070)
cNACK. Nodes have no incentive to become free relays between those who want to store arbitrary data and miners. Setting defaults to the opposite effect just results in distrust of Core and migration away from it (as we have witnessed over the last week - although of course no Sybil resistant seems genuine.)
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2851140070)
cNACK. Nodes have no incentive to become free relays between those who want to store arbitrary data and miners. Setting defaults to the opposite effect just results in distrust of Core and migration away from it (as we have witnessed over the last week - although of course no Sybil resistant seems genuine.)
💬 musaHaruna commented on pull request "mining: rename gbt_force and gbt_force_name":
(https://github.com/bitcoin/bitcoin/pull/32386#issuecomment-2851146353)
> @musaHaruna it looks like you checked an outdated hash.
Thanks. I have updated it
(https://github.com/bitcoin/bitcoin/pull/32386#issuecomment-2851146353)
> @musaHaruna it looks like you checked an outdated hash.
Thanks. I have updated it
💬 pinheadmz commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2851148728)
@BitcoinMechanic
> no incentive
Fee estimation and block propagation to name a few: https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ/m/3WVL60u6EQAJ
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2851148728)
@BitcoinMechanic
> no incentive
Fee estimation and block propagation to name a few: https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ/m/3WVL60u6EQAJ
💬 musaHaruna commented on pull request "mining: rename gbt_force and gbt_force_name":
(https://github.com/bitcoin/bitcoin/pull/32386#issuecomment-2851148905)
@Sjors Thanks. Updated to the latest hash
(https://github.com/bitcoin/bitcoin/pull/32386#issuecomment-2851148905)
@Sjors Thanks. Updated to the latest hash
💬 BitcoinMechanic commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2851165167)
> @BitcoinMechanic
>
> > no incentive
>
> Fee estimation and block propagation to name a few: https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ/m/3WVL60u6EQAJ
It does no harm to fee estimation or block propagation. Nodes can and do cache transactions they reject from their mempools making compact blocks just as quick to verify regardless of if some of their contents was filtered.
Fee estimation similarly does not require knowledge of "the" mempool and there can never be such a thi
...
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2851165167)
> @BitcoinMechanic
>
> > no incentive
>
> Fee estimation and block propagation to name a few: https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ/m/3WVL60u6EQAJ
It does no harm to fee estimation or block propagation. Nodes can and do cache transactions they reject from their mempools making compact blocks just as quick to verify regardless of if some of their contents was filtered.
Fee estimation similarly does not require knowledge of "the" mempool and there can never be such a thi
...
💬 Sjors commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2851168826)
Concept ACK. This adds a deprecation step to #32406, which seems fine from a technical point of view, and was requested by regular contributors as well.
It will re-invite the brigading when the actual code is removed, but it will be easier to point to earlier discussion.
Code looks reasonable at first glance, when compared to #32359, but will re-review it.
3ba7449f6c335026b752366c53f9c309f09e6c64 could be split between a commit that allows multiple outputs and one that switches the defa
...
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2851168826)
Concept ACK. This adds a deprecation step to #32406, which seems fine from a technical point of view, and was requested by regular contributors as well.
It will re-invite the brigading when the actual code is removed, but it will be easier to point to earlier discussion.
Code looks reasonable at first glance, when compared to #32359, but will re-review it.
3ba7449f6c335026b752366c53f9c309f09e6c64 could be split between a commit that allows multiple outputs and one that switches the defa
...
🚀 hebasto merged a pull request: "build: replace header checks with `__has_include`"
(https://github.com/bitcoin/bitcoin/pull/32405)
(https://github.com/bitcoin/bitcoin/pull/32405)
💬 Retropex commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2851173915)
Concept NACK.
For the same reasons mentioned in #32359.
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2851173915)
Concept NACK.
For the same reasons mentioned in #32359.
💬 andrewtoth commented on pull request "validation: write chainstate to disk every hour":
(https://github.com/bitcoin/bitcoin/pull/30611#issuecomment-2851174297)
@Sjors I just tested this by modifying the lines [here](https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L97-L98) to be `1min` and `2min`, deleted my `blocks`, `chainstate`, and `indexes` directories and ran `./build/bin/bitcoind -maxconnections=0 -addnode=<local_node> -debug=coindb`. I can confirm it flushes between 1 and 2 minutes after startup and continuously after, due to the change in `chainstate` directory size and the `coindb` logs.
(https://github.com/bitcoin/bitcoin/pull/30611#issuecomment-2851174297)
@Sjors I just tested this by modifying the lines [here](https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L97-L98) to be `1min` and `2min`, deleted my `blocks`, `chainstate`, and `indexes` directories and ran `./build/bin/bitcoind -maxconnections=0 -addnode=<local_node> -debug=coindb`. I can confirm it flushes between 1 and 2 minutes after startup and continuously after, due to the change in `chainstate` directory size and the `coindb` logs.
💬 pinheadmz commented on pull request "Extend signetchallenge to set target block spacing":
(https://github.com/bitcoin/bitcoin/pull/29365#issuecomment-2851176101)
What commit is that failure from?
(https://github.com/bitcoin/bitcoin/pull/29365#issuecomment-2851176101)
What commit is that failure from?
💬 nsvrn commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2851209816)
Concept NACK
If fee estimation, block propagation etc has issues with mempool diversity specially for defense against spam/DoS then the position of not fixing that or making a future economic judgement based on theoretical assumptions is a fallacy. This broad position of Bitcoin Core can clearly increase spam and centralization regardless of economic incentives of miners which are all speculations and projections to modify how Bitcoin works instead of being realistic about the end goal of Bit
...
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2851209816)
Concept NACK
If fee estimation, block propagation etc has issues with mempool diversity specially for defense against spam/DoS then the position of not fixing that or making a future economic judgement based on theoretical assumptions is a fallacy. This broad position of Bitcoin Core can clearly increase spam and centralization regardless of economic incentives of miners which are all speculations and projections to modify how Bitcoin works instead of being realistic about the end goal of Bit
...
💬 instagibbs commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2851218711)
FWIW I will not engage in meta discussion here. I will respond to any deficiencies in the code itself.
> https://github.com/bitcoin/bitcoin/commit/3ba7449f6c335026b752366c53f9c309f09e6c64 could be split between a commit that allows multiple outputs and one that switches the default.
Touching tests twice is kind of annoying, but I can do if it makes code history easier and others agree.
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2851218711)
FWIW I will not engage in meta discussion here. I will respond to any deficiencies in the code itself.
> https://github.com/bitcoin/bitcoin/commit/3ba7449f6c335026b752366c53f9c309f09e6c64 could be split between a commit that allows multiple outputs and one that switches the default.
Touching tests twice is kind of annoying, but I can do if it makes code history easier and others agree.
💬 pinheadmz commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2851220227)
@nsvrn this PR specifically enables users to have a divergent mempool. I don't understand the use case for that, but the proposal here addresses feedback on #32359 and adds a feature specifically for users who do not want their mempool to anticipate miner behavior.
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2851220227)
@nsvrn this PR specifically enables users to have a divergent mempool. I don't understand the use case for that, but the proposal here addresses feedback on #32359 and adds a feature specifically for users who do not want their mempool to anticipate miner behavior.