💬 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.
💬 luke-jr commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833682866)
>Data publishing via unspendable UTXOs is undetectable. We can't block it without significant changes to the consensus protocol.
This is false. It would require invasive changes to the address format (and disabling old address formats), but there are no consensus changes required.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833682866)
>Data publishing via unspendable UTXOs is undetectable. We can't block it without significant changes to the consensus protocol.
This is false. It would require invasive changes to the address format (and disabling old address formats), but there are no consensus changes required.
💬 petertodd commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833689061)
> This is false. It would require invasive changes to the address format (and disabling old address formats), but there are no consensus changes required.
You are referring to standardness rules, which can be [easily](https://geyser.fund/project/librerelay) [bypassed](https://slipstream.mara.com/) Consensus changes are required to have any hope of actually preventing the publication of data.
Besides, deprecating old address formats to "fight spam" --- an enormously costly ecosystem wide ch
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833689061)
> This is false. It would require invasive changes to the address format (and disabling old address formats), but there are no consensus changes required.
You are referring to standardness rules, which can be [easily](https://geyser.fund/project/librerelay) [bypassed](https://slipstream.mara.com/) Consensus changes are required to have any hope of actually preventing the publication of data.
Besides, deprecating old address formats to "fight spam" --- an enormously costly ecosystem wide ch
...
💬 petertodd commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833689739)
@polespinasa
> I don't see the point of taking away users configuration options to their mempool policies.
We did exactly that with Full-RBF, because the policies of individual nodes are unable to prevent profitable transactions from being broadcast and mined. Full-RBF reached ~100% miner adoption before Bitcoin Core even released a version with it enabled by default.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833689739)
@polespinasa
> I don't see the point of taking away users configuration options to their mempool policies.
We did exactly that with Full-RBF, because the policies of individual nodes are unable to prevent profitable transactions from being broadcast and mined. Full-RBF reached ~100% miner adoption before Bitcoin Core even released a version with it enabled by default.
💬 nsvrn commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833691547)
> Anyway, this kind of non-technical discussion seems off-topic for this pull-req. Best to do it on the mailing list. And furthermore, people have choice - Knots exists. If they wish to enforce these limits on their own nodes they're welcome to run Knots. There's no reason why Bitcoin Core should be forced to take on the maintenance burden of maintaining arbitrary limits that we believe are ineffective, and even harmful.
Concept NACK
There are certainly users who are using these config opt
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833691547)
> Anyway, this kind of non-technical discussion seems off-topic for this pull-req. Best to do it on the mailing list. And furthermore, people have choice - Knots exists. If they wish to enforce these limits on their own nodes they're welcome to run Knots. There's no reason why Bitcoin Core should be forced to take on the maintenance burden of maintaining arbitrary limits that we believe are ineffective, and even harmful.
Concept NACK
There are certainly users who are using these config opt
...
💬 jesterhodl commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833693049)
Removing an easy way for bitcoin users to precisely express their preference as to how their node works is like trying to centrally plan an economic system. It will end up in suboptimal results, which nobody will be happy od except non-monetary applications and related beneficiaries.
ML talk references Citrea. The PR seems to anticipate some company's mere intent. Are we now shapeshifting bitcoin to whatever people publish they might be doing on Bitcoin? Bitcoin has a purpose and it's not appea
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833693049)
Removing an easy way for bitcoin users to precisely express their preference as to how their node works is like trying to centrally plan an economic system. It will end up in suboptimal results, which nobody will be happy od except non-monetary applications and related beneficiaries.
ML talk references Citrea. The PR seems to anticipate some company's mere intent. Are we now shapeshifting bitcoin to whatever people publish they might be doing on Bitcoin? Bitcoin has a purpose and it's not appea
...
💬 libertyluminary commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833707895)
This literally advocates for a reduction in sovereignty of node runners to choose how to config their node. Why do so many people hate freedom?
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833707895)
This literally advocates for a reduction in sovereignty of node runners to choose how to config their node. Why do so many people hate freedom?
💬 pinheadmz commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833709249)
This is apparently a controversial issue and so this thread will be watched closely for moderation. Please make sure all comments are technical in nature, and on topic: the topic is the title, description, and code changes of this pull request. References to people will result in 24 hour ban, to start.
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833709249)
This is apparently a controversial issue and so this thread will be watched closely for moderation. Please make sure all comments are technical in nature, and on topic: the topic is the title, description, and code changes of this pull request. References to people will result in 24 hour ban, to start.
💬 Christewart commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833757218)
concept ACK
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833757218)
concept ACK
💬 benthecarman commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833840397)
huge concept ack removing the incentive to bloat the utxo set is definitely needed
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833840397)
huge concept ack removing the incentive to bloat the utxo set is definitely needed
💬 chrisguida commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833932824)
Concept NACK
The proper response to a spam attack is not to cave to the spammers. This will only embolden them. If our rationale for loosening the restrictions is "a bunch of degenerates want to gamble on the blockchain, so that means there's lots of economic demand for such transactions", then that will become a self-fulfilling prophecy... indeed it already has. Thus the spammers' claim to using bitcoin as a dump-bucket for their altcoin Ponzis will only become stronger over time, while peop
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2833932824)
Concept NACK
The proper response to a spam attack is not to cave to the spammers. This will only embolden them. If our rationale for loosening the restrictions is "a bunch of degenerates want to gamble on the blockchain, so that means there's lots of economic demand for such transactions", then that will become a self-fulfilling prophecy... indeed it already has. Thus the spammers' claim to using bitcoin as a dump-bucket for their altcoin Ponzis will only become stronger over time, while peop
...
💬 wizkid057 commented on pull request "Remove arbitrary limits on OP_Return (datacarrier) outputs":
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2834012756)
Concept NACK
OP_RETURN was only ever made standard at all as a tolerated form of data carrying to prevent more harmful forms of data carrying (fake pubkeys/script hashes/bare multisig/etc). To serve that purpose, it only needs to be ~40 bytes. The ~80 byte allowance is beyond sufficient for its intended purpose.
Arbitrary data in transactions was never an intended use case of the network, the resources of nodes, etc.
We should be a) leaving this as-is for now, b) fixing standardness po
...
(https://github.com/bitcoin/bitcoin/pull/32359#issuecomment-2834012756)
Concept NACK
OP_RETURN was only ever made standard at all as a tolerated form of data carrying to prevent more harmful forms of data carrying (fake pubkeys/script hashes/bare multisig/etc). To serve that purpose, it only needs to be ~40 bytes. The ~80 byte allowance is beyond sufficient for its intended purpose.
Arbitrary data in transactions was never an intended use case of the network, the resources of nodes, etc.
We should be a) leaving this as-is for now, b) fixing standardness po
...