pull down to refresh
1688 sats \ 7 replies \ @Murch 4 May \ parent \ on: Quick questions about OP_RETURN? Quick answers here. bitcoin
Generally, a configuration option should be provided when one can provide recommendations when the configuration option should be used and how it should be adjusted. Historically, it looks like the vast majority of Bitcoin Core nodes use the default configuration. When at least about 10% of nodes accept a transaction, it propagates somewhat reliably to all nodes in the network that accept them.
This means that if the default configuration for the OP_RETURN limit were raised or removed altogether, such transactions would soon after the release reliably propagate and, perhaps a little later, also get mined by a larger proportion of the block authors. Node operators setting a lower limit would do so at their detriment: they would download the transactions after an announcement from their peers, reject adding it to their mempool, then download the same transactions again when a block includes them, incurring increased bandwidth and extra latency on the updating to the latest chain tip.
Some proponents of the increased limit argue that the configuration option should not have been added in the first place, as it is ineffective to locally configure a different limit, and that the configuration option is even less useful after dropping the limit. Other contributors argue that setting a lower limit only harms the node operator, and removing the configuration option takes away control needlessly.
With all due respect, I don't think you've answered the question.
Your make valid points for the justification of the increase in the limit and explain that individual nodes may be harming themselves, default settings are the norm and the transactions will be propagated anyway. You've even pointed out that the ability to configure this setting was debated anyway and some consider that it shouldn't have been added.
But the question asks something different, something I am wondering also. As a sovereign node runner in an open permissionless network, why does this PR propose to remove the ability for me to configure the mempool settings on my own node?
If I make a decision that harms myself and doesn't make any difference to the propagation of transactions, isn't that for me to decide and bear the consequences of?
It's like re-using addresses, commonly accepted as poor for privacy but there is no rule in the protocol that permits it. It's up to me to understand and accept the consequences.
reply
If I make a decision that harms myself and doesn't make any difference to the propagation of transactions, isn't that for me to decide and bear the consequences of?
It is arguably disingenuous for Core software to offer an option that has no impact. There may be users who believe it is meaningful when it isn't. It also can reduce the performance of their node. If users use the option thinking they're helping the network when they're actually harming their own node, and they eventually learn this, they may become angry at Core devs for tricking them.
reply
With all due respect, I don't think you've answered the question.
You are right, thanks for bringing this up.
[…] why were these options taken away?
At this time, the configuration option has not been removed. There is a pull request that proposes to increase the limit and to remove the configuration option, but several reviewers have argued that the two changes should be separated or that only the limit should be changed without dropping the configuration option. I would consider this part of the pull request to be still in question.
But the question asks something different, something I am wondering also. As a sovereign node runner in an open permissionless network, why does this PR propose to remove the ability for me to configure the mempool settings on my own node?
Originally, I was in favor of dropping the configuration option, because I consider it harmful and cannot come up with a situation in which I would recommend its use to a node runner, but after talking about this with several people (including one that consulted a psychologist!), I now support leaving the configuration option in the upcoming release, although I would still prefer that it be deprecated and removed eventually.
You are asking the obvious questions, and that there don't seem to be super-compelling answers should set off alarm bells. Of course, the real answer is that OP_RETURN limits in fact DO hinder spam. For the parent post to claim that "node operators setting a lower limit...do so at their detriment" is incredibly myopic and imo misleading. In fact, when viewed in the context of a spam transaction, the node being forced to redownload the transaction after it has been added to a block, is an anti-spam FEATURE, not a bug (see below).
I invite you to check out this post here (which is pro-Knots):
as well as the parent (which is pro-Core):
and the followup (which is again pro-Knots):
If you have difficulty following the logic, I think this presentation (which is pro-Core), does a good job of explaining the big picture:
And you can read the response (which is pro-Knots):
reply
reply