💬 jesterhodl commented on pull request "[29.x] qt: 29.1 translations update":
(https://github.com/bitcoin/bitcoin/pull/32352#issuecomment-2833518903)
check_translations shouldn't complain for any polish labels as of now. Transifex is updated.
(https://github.com/bitcoin/bitcoin/pull/32352#issuecomment-2833518903)
check_translations shouldn't complain for any polish labels as of now. Transifex is updated.
💬 maflcko commented on pull request "[29.x] qt: 29.1 translations update":
(https://github.com/bitcoin/bitcoin/pull/32352#issuecomment-2833525020)
> check_translations shouldn't complain for any polish labels as of now. I ran it.
Thanks. Just for reference, the script doesn't *need* to report no complaints. Sometimes it complains about perfectly fine translations. Also, it may not even be deterministic if called several times with a cleared cache.
(https://github.com/bitcoin/bitcoin/pull/32352#issuecomment-2833525020)
> check_translations shouldn't complain for any polish labels as of now. I ran it.
Thanks. Just for reference, the script doesn't *need* to report no complaints. Sometimes it complains about perfectly fine translations. Also, it may not even be deterministic if called several times with a cleared cache.
💬 jesterhodl commented on pull request "[29.x] qt: 29.1 translations update":
(https://github.com/bitcoin/bitcoin/pull/32352#issuecomment-2833526071)
> > check_translations shouldn't complain for any polish labels as of now. I ran it.
>
> Thanks. Just for reference, the script doesn't _need_ to report no complaints. Sometimes it complains about perfectly fine translations. Also, it may not even be deterministic if called several times with a cleared cache.
OK. By the way I noticed it. It complained A should be B, and then B should be A. Neither form would make it happy. I opted for something else.
(https://github.com/bitcoin/bitcoin/pull/32352#issuecomment-2833526071)
> > check_translations shouldn't complain for any polish labels as of now. I ran it.
>
> Thanks. Just for reference, the script doesn't _need_ to report no complaints. Sometimes it complains about perfectly fine translations. Also, it may not even be deterministic if called several times with a cleared cache.
OK. By the way I noticed it. It complained A should be B, and then B should be A. Neither form would make it happy. I opted for something else.
📝 hebasto opened a pull request: "subprocess: Backport upstream changes"
(https://github.com/bitcoin/bitcoin/pull/32358)
Most of these changes were developed during work on https://github.com/bitcoin/bitcoin/pull/29868 and have since been upstreamed.
As they are now merged, this PR backports them to our `src/util/subprocess.h` header.
Required for https://github.com/bitcoin/bitcoin/pull/29868.
(https://github.com/bitcoin/bitcoin/pull/32358)
Most of these changes were developed during work on https://github.com/bitcoin/bitcoin/pull/29868 and have since been upstreamed.
As they are now merged, this PR backports them to our `src/util/subprocess.h` header.
Required for https://github.com/bitcoin/bitcoin/pull/29868.
💬 hebasto commented on pull request "Reintroduce external signer support for Windows":
(https://github.com/bitcoin/bitcoin/pull/29868#issuecomment-2833536931)
Rebased on https://github.com/bitcoin/bitcoin/pull/32358 and drafted until the latter is landed.
(https://github.com/bitcoin/bitcoin/pull/29868#issuecomment-2833536931)
Rebased on https://github.com/bitcoin/bitcoin/pull/32358 and drafted until the latter is landed.
📝 hebasto converted_to_draft a pull request: "Reintroduce external signer support for Windows"
(https://github.com/bitcoin/bitcoin/pull/29868)
Based on https://github.com/bitcoin/bitcoin/pull/32358.
Partially reverts:
- https://github.com/bitcoin/bitcoin/pull/28967
- https://github.com/bitcoin/bitcoin/pull/29489
After this PR, we can proceed to actually remove the [unused code](https://github.com/bitcoin/bitcoin/pull/28981#pullrequestreview-1991272752) from `src/util/subprocess.hpp`.
(https://github.com/bitcoin/bitcoin/pull/29868)
Based on https://github.com/bitcoin/bitcoin/pull/32358.
Partially reverts:
- https://github.com/bitcoin/bitcoin/pull/28967
- https://github.com/bitcoin/bitcoin/pull/29489
After this PR, we can proceed to actually remove the [unused code](https://github.com/bitcoin/bitcoin/pull/28981#pullrequestreview-1991272752) from `src/util/subprocess.hpp`.
📝 petertodd opened a pull request: "Remove arbitrary limits on OP_Return (datacarrier) outputs"
(https://github.com/bitcoin/bitcoin/pull/32359)
As per recent bitcoindev mailing list discussion.
Also removes the code to enforce those limits, including the `-datacarrier` and `-datacarriersize` config options.
These limits are easily bypassed by both direct submission to miner mempools (e.g. MARA Slipstream), and forks of Bitcoin Core that do not enforce them (e.g. Libre Relay). Secondly, protocols are bypassing them by simply publishing data in other ways, such as unspendable outputs and scriptsigs.
The *form* of datacarrier outp
...
(https://github.com/bitcoin/bitcoin/pull/32359)
As per recent bitcoindev mailing list discussion.
Also removes the code to enforce those limits, including the `-datacarrier` and `-datacarriersize` config options.
These limits are easily bypassed by both direct submission to miner mempools (e.g. MARA Slipstream), and forks of Bitcoin Core that do not enforce them (e.g. Libre Relay). Secondly, protocols are bypassing them by simply publishing data in other ways, such as unspendable outputs and scriptsigs.
The *form* of datacarrier outp
...
💬 luke-jr commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833642959)
As per ML discussion, firm Concept NACK.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833642959)
As per ML discussion, firm Concept NACK.
🤔 luke-jr reviewed a pull request: "Remove arbitrary limits on OP_Return (datacarrier) outputs"
(https://github.com/bitcoin/bitcoin/pull/32359#pullrequestreview-2797740640)
As per ML discussion, firm Concept NACK.
(https://github.com/bitcoin/bitcoin/pull/32359#pullrequestreview-2797740640)
As per ML discussion, firm Concept NACK.
🤔 darosior reviewed a pull request: "Remove arbitrary limits on OP_Return (datacarrier) outputs"
(https://github.com/bitcoin/bitcoin/pull/32359#pullrequestreview-2797742035)
Concept ACK.
(https://github.com/bitcoin/bitcoin/pull/32359#pullrequestreview-2797742035)
Concept ACK.
💬 BitcoinMechanic commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833646525)
Concept NACK. Hard to take this seriously. Those config options not having direct impact over what miners may put in blocks does not equate to users no longer having a choice over what ends up in their mempools.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833646525)
Concept NACK. Hard to take this seriously. Those config options not having direct impact over what miners may put in blocks does not equate to users no longer having a choice over what ends up in their mempools.
💬 Retropex commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833651452)
Concept NACK. If miners want larger datacarrier transactions, they can use these settings to do so.
There’s no reason to prevent miners and node runners from making this choice.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833651452)
Concept NACK. If miners want larger datacarrier transactions, they can use these settings to do so.
There’s no reason to prevent miners and node runners from making this choice.
💬 1ma commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833652880)
Again? https://github.com/bitcoin/bitcoin/pull/28130
Concept NACK.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833652880)
Again? https://github.com/bitcoin/bitcoin/pull/28130
Concept NACK.
💬 petertodd commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833653449)
@1ma Please read the relevant mailing list discussion first: https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ
There are good reasons why this is being brought up again.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833653449)
@1ma Please read the relevant mailing list discussion first: https://groups.google.com/g/bitcoindev/c/d6ZO7gXGYbQ
There are good reasons why this is being brought up again.
💬 1ma commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833656214)
Already did. I'm actually waiting for someone to add a new message so I can add mine with the data I gathered (just joined the mailing list).
If you care to actually look at the blockchain turns out no one is trying to get large OP_RETURNs mined: https://github.com/1ma/blockstats
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833656214)
Already did. I'm actually waiting for someone to add a new message so I can add mine with the data I gathered (just joined the mailing list).
If you care to actually look at the blockchain turns out no one is trying to get large OP_RETURNs mined: https://github.com/1ma/blockstats
💬 petertodd commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833660649)
@1ma As was discussed in the mailing list discussion, entities are using unspendable outputs in liu of OP_Return outputs. Precisely because of the size limit. This increases the UTXO set size unnecessarily, a harmful effect of having the arbitrary OP_Return output limitations. Your analysis does not take that kind of issue into account.
Rather than do a stream of incremental increases, wasting dev bandwidth, this pull-req simply removes those arbitrary limits.
Anyway, this kind of non-tech
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833660649)
@1ma As was discussed in the mailing list discussion, entities are using unspendable outputs in liu of OP_Return outputs. Precisely because of the size limit. This increases the UTXO set size unnecessarily, a harmful effect of having the arbitrary OP_Return output limitations. Your analysis does not take that kind of issue into account.
Rather than do a stream of incremental increases, wasting dev bandwidth, this pull-req simply removes those arbitrary limits.
Anyway, this kind of non-tech
...
💬 Rob1Ham commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833661697)
Concept ACK. Better to have provable unspendable outputs than dust outputs forever in the utxo set.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833661697)
Concept ACK. Better to have provable unspendable outputs than dust outputs forever in the utxo set.
💬 BitcoinMechanic commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833661758)
>entities are using unspendable outputs in liu of OP_Return outputs. Precisely because of the size limit.
Schrödinger's spamfilters. They work/don't work whenever is convenient for people trying to turn nodes into unpaid cloud storage.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833661758)
>entities are using unspendable outputs in liu of OP_Return outputs. Precisely because of the size limit.
Schrödinger's spamfilters. They work/don't work whenever is convenient for people trying to turn nodes into unpaid cloud storage.
💬 1ma commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833663795)
@petertodd @Rob1Ham Sounds like a new standardness rule is called for, not removing existing ones.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833663795)
@petertodd @Rob1Ham Sounds like a new standardness rule is called for, not removing existing ones.
💬 reardencode commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833663896)
utAck https://github.com/bitcoin/bitcoin/commit/cd7872ca543d31d20f419fd2203138b8301c2e68
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833663896)
utAck https://github.com/bitcoin/bitcoin/commit/cd7872ca543d31d20f419fd2203138b8301c2e68