pull down to refresh
346 sats \ 6 replies \ @hgw39 5 May \ parent \ on: Quick questions about OP_RETURN? Quick answers here. bitcoin
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.
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