💬 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
💬 Retropex commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833669850)
@petertodd, if you genuinely want to promote OP_RETURN for the network’s health, this PR should include a similar filter like #28408.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833669850)
@petertodd, if you genuinely want to promote OP_RETURN for the network’s health, this PR should include a similar filter like #28408.
💬 petertodd commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833674318)
@Retropex Data publishing via unspendable UTXOs is undetectable. We can't block it without significant changes to the consensus protocol.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833674318)
@Retropex Data publishing via unspendable UTXOs is undetectable. We can't block it without significant changes to the consensus protocol.
💬 jlopp commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833680770)
Concept ACK.
It's time to come to terms with the fact that Bitcoin is desirable for some people to use as a data anchor and they will find a way to use it as such, thus we should be asking what the preferred means of data anchoring is and how to incentivize it over less preferable options.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833680770)
Concept ACK.
It's time to come to terms with the fact that Bitcoin is desirable for some people to use as a data anchor and they will find a way to use it as such, thus we should be asking what the preferred means of data anchoring is and how to incentivize it over less preferable options.
💬 polespinasa commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833682296)
I could cACK on removing those limits by default, but:
> Also removes the code to enforce those limits, including the `-datacarrier` and `-datacarriersize` config options.
Concept nack to this. The code is already there, I don't see the point of taking away users configuration options to their mempool policies.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833682296)
I could cACK on removing those limits by default, but:
> Also removes the code to enforce those limits, including the `-datacarrier` and `-datacarriersize` config options.
Concept nack to this. The code is already there, I don't see the point of taking away users configuration options to their mempool policies.