The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage

For detailed information about the code coverage, see the test coverage report.

Reviews

See the guideline for information on the review process.

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

No conflicts as of last run.

Concept ACK; CI is failing, probably need to update some tests.

I'm not aware of any legitimate usage of bare multisig, so this should be a costless way to filter more spam. Knots has had this policy for years.

Concept ACK. Long overdue.

Concept ACK.

Bare multisig has not been used for doing multisig transactions in ages. Today their only known use is embedding arbitrary data in transactions that nodes cannot prune from the UTXO set, bloating it forever¹. Moreover turning off permitbaremultisig does not prevent spending actually spendable bare multisig UTXOs, so it won't freeze any funds.

Bare multisig should be treated as an attack vector on Bitcoin nodes, like other constructs that were deemed unsafe and disabled soon after the inception of Bitcoin.

This change only affects P2P not blockchain. If bare multisig has no use case, why does it even exist in Bitcoin?

No transaction on the Bitcoin network is spam, what a bunch of censorshipnists..

This is not Bitcoin..

Concept ACK

Very important step to close this attack vector.

Concept ACK.

Please more of such simple suggestions to make life of those who abuse the blockchain harder! That we cannot stop them completely does not mean that we cannot make it less attractive to them.

"It would also promote the adoption of best practices."

Best practices in accordance with whom?

Bare multisig has one advantage over redeem/witness/leaf script multisig in that it's not necessary to backup all public keys/xpubs in order to reconstruct the spending script, the threshold number of private keys/xprvs is enough to recover funds.

Additionally, I don't think this change would really affect spam, as anyone determined to store raw data in unprunable outputs (as opposed to OP_RETURN or unused script branches) can just switch to a different standard output type while only sacrificing a little bit of encoding efficiency.

Bare multisig has one advantage over redeem/witness/leaf script multisig in that it's not necessary to backup all public keys/xpubs in order to reconstruct the spending script, the threshold number of private keys/xprvs is enough to recover funds.

Additionally, I don't think this change would really affect spam, as anyone determined to store raw data in unprunable outputs (as opposed to OP_RETURN or unused script branches) can just switch to a different standard output type while only sacrificing a little bit of encoding efficiency.

That's true, but I think that there is a way with Taproot (ex. Frost) to get those benefits (see Jimmy Song's talk about taproot on youtube).

can just switch to a different standard output type

Yes, that's a good thing because standard output types don't bloat the UTXO set as much as the current spam attacks do.

Yes, that's a good thing because standard output types don't bloat the UTXO set as much as the current spam attacks do.

I admit I don't know the specifics of how the UTXO set is stored, but how does storing 96 bytes in one 3-of-3 bare multisig bloat it more than say storing it in 3 P2TR outputs?

Best practices in accordance with whom?

With my node that has been constantly spammed for seven months with catastrophic consequences on the UTXOs set.

Size of Serialized UTXO Set.

Stamps.

The vast majority of the recent UTXO set size increase (which mostly happened in the last four months, not seven) comes not from bare multisig but from BRC-20. Bare multisig peaked in April, barely crossing 10k unspent outputs a day, and currently adds only a few hundred daily, while BRC-20 still keeps adding over 50k unspent outputs every day.

Note that this is largely irrelevant as it's not possible to meaningfully restrict arbitrary data storage without restricting normal transactions as well, I just wanted to clear it up that bare multisig isn't actually contributing much to the current spam.

The vast majority of the recent UTXO set size increase (which mostly happened in the last four months, not seven) comes not from bare multisig but from BRC-20. Bare multisig peaked in April, barely crossing 10k unspent outputs a day, and currently adds only a few hundred daily, while BRC-20 still keeps adding over 50k unspent outputs every day.

I know it, unfortunately no mempool option for inscriptions is available at the moment, so even if Baremultisig is less used it remains spam for my node.

NACK, zero data to back-up PR claim that disallowing non-multisig p2sh would reduce spam, pure conjecture. A quick review of block data shows insignificant amount of non-multisig p2sh usage (not spam). If they pay the fee, it's not spam.

NACK, zero data to back-up PR claim that disallowing non-multisig p2sh would reduce spam, pure conjecture. A quick review of block data shows insignificant amount of non-multisig p2sh usage (not spam). If they pay the fee, it's not spam.

with respect, I think there is historical data AND precedent to suggest that default policies can reduce the amount of onchain spam. (ie the reduction in counterparty spam after the OP-RETURN limit was added (ironic that this limit is being considered for removal as we speak here #28130...it's almost as if these issues are related!)

The question is, does Core have a current mandate to make this policy change, and the political will do deal with the blowback?

At the moment, I believe they not only have the mandate, but the responsibility.

But do they have the will to deal with the drama of this?

From what I have seen, not so much (and I totally get why!).

Concept ACK

Concept NACK; trying to discourage vandalism via policy incentivizes the emergence of mempool alternatives which could have quiet nasty consequences down the line.

Concept NACK; trying to discourage vandalism via policy incentivizes the emergence of mempool alternatives which could have quiet nasty consequences down the line.

ie. MAYBE some spammers pay out of band more, raising the cost in UX, time and sats for this kind of unwanted behavior.

I'm ok with that.

Because maybe a good chunk of them just stop altogether.

hmm i sense a serious lack of adversarial thinking. let's see if anyone can figure out what the real problem is?

Leaning towards Concept ACK

Bare multisigs are generally unusable to the vast majority of wallet software, if not all of them. They do not have an address type so the vast majority of users are completely unable to send to them. Sending to such requires specialized software and quite a bit of communication in order to get the script right. It requires some technical knowhow on the sender side to do correctly.

Arguably the same should be done for P2PK outputs as well for the same reasons.

Note that this change (and any future proposal to do the same for P2PK) only affects new outputs. Spending existing outputs is still standard and allowed so as to avoid any potential confiscation of funds. Only transactions that create new bare multisig outputs would be considered non-standard.

disallowing non-multisig p2sh would reduce spam, pure conjecture.

This PR has nothing to do with non-multisig P2SH. Did you perhaps misread or mistype non-P2SH multisig? Scripts within P2SH, P2WSH, and P2TR contexts are irrelevant to this discussion. This is about output scripts that are literally multisig scripts.

NACK, zero data to back-up PR claim that disallowing non-multisig p2sh would reduce spam, pure conjecture. A quick review of block data shows insignificant amount of non-multisig p2sh usage (not spam). If they pay the fee, it's not spam.

with respect, I think there is historical data AND precedent to suggest that default policies can reduce the amount of onchain spam. (ie the reduction in counterparty spam after the OP-RETURN limit was added (ironic that this limit is being considered for removal as we speak here #28130...it's almost as if these issues are related!)

The question is, does Core have a current mandate to make this policy change, and the political will do deal with the blowback?

At the moment, I believe they not only have the mandate, but the responsibility.

But do they have the will to deal with the drama of this?

From what I have seen, not so much (and I totally get why!).

Concept ACK

This propaganda needs to stop. OP_RETURN is not bad. In case you forgot it's inspcriptions that have led to the largest blocks ever on bitcoin, not bare p2sh.

If we followed the logic proposed in your response we should also roll back taproot and replace the limit on the script sigs. Spam from taproot lifting the limit on scriptsigs far exceeds the legitimate uses of all p2sh usage. Lifting the script sig without validating the input is a bug no one wants to admit exists. I can decode a hex scriptsig to ASCII which clearly prints "Adobe Lightroom" meta tags because it's NOT A SCRIPT SIG. That is a bug as it doesn't validate the content is a scriptsig.

Like you said Core has the responsibility to protect against this attack vector.

Concept ACK

I've heard similar arguments from many people, and I have to say I disagree. The miners need to follow the will of the users (especially the holders), or bitcoin cannot survive long-term. Mining pools are highly attuned to short-term interests, generally at the expense of long-term considerations. This is understandable given the competitive and unpredictable nature of proof-of-work pooled mining. A pool operator who tries to be a good citizen and caretake bitcoin's long-term interests will most likely find itself at an economic disadvantage with respect to other mining pools (unless a majority of the hashrate agrees to the new behavior). So they must heed the will of the user community when the users express preferences, because this is the only way for miners to protect everyone's (including their own!) long-term interests. That is, the miners need us to tell them what we think is best for bitcoin's long-term health, and they need to trust our judgment on this, except in extreme circumstances.

You're basically making an argument to altruism. If that argument was robust, we would not need the blocksize limit.

Secondly, if your argument was correct, miners would already be setting -permitbaremultisig=0. Other than Ocean, I'm not aware of any miner who does that. Meanwhile my own campaign to get miners to set -mempoolfullrbf=1, a setting that earns them more money in the short term, has succeeded: now that Foundry USA has turned on full-rbf, roughly 70% of hash power is mining it even though Bitcoin Core defaults it to off.

The crazy thing is, it's very easy for us to do something about it.

It's not. As long as miners are uninterested in setting -permitbaremultisig=0, changing this default in Bitcoin Core will just fuel the growth of alternative transaction relay mechanisms. Heck, we've already seen this happen with full-RBF, as it needed my full-RBF peering fork to reliably get full-RBF replacements to get to miners, particularly initially.

If a mutually beneficial arrangement cannot be arrived at, then you start using threats of force, and then if that doesn't work, you actually use force.

That you are describing this change as "force" is exactly why so many people call this censorship: you are trying to prevent transactions from getting to miners who would happily mine them.

I would strongly suggest that rather going down this path, you first convince more hash power to set -permitbaremultisig=0. You'd have a much better argument if, say, a majority of hash power wasn't mining those transactions.

The issue with (I hope) accidental conflation of "miners" with "pool operators" as you are doing @petertodd is that it makes a trivial task (getting a dozen people to flip a 1 to a 0) seem insurmountable by implying that we are dealing with miners in general. We aren't.

As you point out, it is extremely easy to get three or four entities to do something like mempoolfullrbf=1.

The difference here is we aren't trying to route around network defaults, we are trying to have them be set correctly in the first place.

The issue with (I hope) accidental conflation of "miners" with "pool operators" as you are doing @petertodd is that it makes a trivial task (getting a dozen people to flip a 1 to a 0) seem insurmountable by implying that we are dealing with miners in general. We aren't.

If it's so trivial, you should do that first: get a majority of hash power to set -permitbaremultisig=0. If you can, then you'd have a much better argument for this pull-req.

As you point out, it is extremely easy to get three or four entities to do something like mempoolfullrbf=1.

Full-RBF earns miners more money. And indeed, pools didn't start adopting it on a larger scale until a lot more full-RBF replacements started happening, and more services like mempool.space made it easy to see that those full-RBF replacements were happening.

The difference here is we aren't trying to route around network defaults, we are trying to have them be set correctly in the first place.

Full-RBF routes around network defaults too. It mostly doesn't work unless you can get full-RBF replacements to miners, which requires full-RBF peering nodes.

The real difference here is you are trying to prevent miners from getting data they want to learn about, censorship. Full-RBF and Libre Relay does the opposite: it helps miners learn about data they're interested in mining.

If it's so trivial, you should do that first: get a majority of hash power to set -permitbaremultisig=0. If you can, then you'd have a much better argument for this pull-req.

Lobbying mining pools in order to backwards-rationalize and shoehorn changes in to bitcoin core itself is perhaps more efficient in that you get to take advantage of the awful centralization issue we have with pools currently, but is clearly not the correct way to go about things.

If you're going to assert that the correct approach of making bitcoin core's nodes have sensible defaults is "censorship" then it remains "censorship" if we get pools to do it too. More credibly so because - again - we'd be taking advantage of only having to work with a tiny group of people.

Full-RBF earns miners more money

True, but that is not the sole reason for its adoption. It also is good for bitcoin generally - as is minimizing non-monetary use of the blockchain and egregious bloating of the UTXO set.

Full-RBF routes around network defaults too.

Agreed, I don't think you understood what I wrote there.

The real difference here is you are trying to prevent miners from getting data they want to learn about, censorship. Full-RBF and Libre Relay does the opposite: it helps miners learn about data they're interested in mining.

As a node, I am not placed under some obligation to provide miners with TXs they are interested in for fear that if I do not they will start soliciting transactions out-of-band. Clearly the case which is why pools generally respect not just consensus, but standard policy also.

This has been a fundamental misunderstanding that has permeated the general discourse in conversations on this topic. Miners must not operate in a fashion that harms the network as indicated by nodes.

If you do not understand this then you have no defence in scenarios where miners are making money but acting maliciously in order to do so.

If the network cannot assert itself in such a scenario (which is incidentally exactly the scenario we are in) then that ultimately hurts miners too for obvious reasons.

@petertodd You appear not to have read my message at all. I'm used to your arguments being well reasoned, so this low-effort response is quite disappointing.

You're basically making an argument to altruism.

No, I'm not. I'm appealing to long-term self-interest for all involved. Altruism involves accepting harm to oneself so that others may benefit. Following a default mempool policy of permitbaremultisig=0 would involve miners sacrificing short-term profits in order to boost long-term profits. Please note that, on the contrary, what you are suggesting involves altruism on the part of the user community, as putting up with the spam harms the users' ability to use bitcoin as money, so that miners can continue senselessly packing blocks with garbage to bolster their short-term profits (but hurting their long-term profits). I don't think anyone needs to sacrifice themselves for anyone else here. We can all benefit if we work together.

If that argument was robust, we would not need the blocksize limit.

You're proving my point again. I'm sure you haven't forgotten this, but the miners tried to hardfork to a larger blocksize limit in 2017 in order to bolster short-term profits; luckily, the user community was there to stop them. The block size limit exists to make sure that miners don't let short-term profits get in the way of bitcoin's long-term survival. The default mempool policy serves a similar purpose. Can miners circumvent these limits? Absolutely, but there are harsh consequences, and ultimately miners' interests are much better served by simply playing by the rules.

Secondly, if your argument was correct, miners would already be setting -permitbaremultisig=0.

No, they wouldn't xD. You did not read my message. Please note this part:

Mining pools are highly attuned to short-term interests, generally at the expense of long-term considerations. This is understandable given the competitive and unpredictable nature of proof-of-work pooled mining. A pool operator who tries to be a good citizen and caretake bitcoin's long-term interests will most likely find itself at an economic disadvantage with respect to other mining pools (unless a majority of the hashrate agrees to the new behavior).

And this part:

Mining pools can't read our minds, nor can they safely concern themselves with bitcoin's long-term success without support from the user community, and we are bad actors if we expect them to.

And this part:

this will allow miners to stop hurting bitcoin and start helping, without giving an asymmetric advantage to any one mining pool refusing to filter these profitable but harmful transactions.

I said it three times but still somehow you missed it, so I'll say it a fourth time: without support from the user community or a majority of hashrate, miners cannot be good citizens and caretake bitcoin's long-term survival without extreme risk to their businesses. Given this, it is not surprising in the least that almost no miners have chosen to set permitbaremultisig to a value different from Core's default.

Other than Ocean, I'm not aware of any miner who does that.

Exactly. Ocean Mining is taking a huge risk by trying to do the right thing, as this likely puts them at an economic disadvantage versus their competition, at least in the short term. They are the only mining pool that appears to be playing the long game, and should be commended for their efforts to steer bitcoin in the right direction. For the record, Ocean has three different templates, only one of which disables p2ms.

Meanwhile my own campaign to get miners to set -mempoolfullrbf=1, a setting that earns them more money in the short term, has succeeded: now that Foundry USA has turned on full-rbf, roughly 70% of hash power is mining it even though Bitcoin Core defaults it to off.

I'm not sure why you think campaigning to help miners increase their short-term profits is relevant to the current conversation. I hope you can see that mempoolfullrbf is entirely different from permitbaremultisig because it allows any miner activating it to have an asymmetric advantage over those running the core defaults since rbf transactions, by definition, include a higher fee than txs they replace, and almost no one is hostile to fullrbf (because it's not harmful), and if they were, there would not even be a way to disable it via consensus rules. Personally, I'm with you on mempoolfullrbf; it honestly makes no sense that it's not enabled by default in core. But that's a separate conversation.

Conversely, with permitbaremultisig, any miner disabling it is not only going against the user community's stated wishes, but it is also forgoing a marginal amount of short-term profits from abusive txs that exploit this vector. So that's a double-whammy, whereas with mempoolfullrbf, going against the user community is only a single-whammy. So, of course lobbying for miners to increase their short-term profits (without support from the user community) will succeed, while lobbying for miners to decrease their short-term profits (without support from the user community) will obviously fail. Make sense?

(In both cases, the user community is misrepresenting its preferences and this should be rectified.)

The crazy thing is, it's very easy for us to do something about it.

It's not. As long as miners are uninterested in setting -permitbaremultisig=0, changing this default in Bitcoin Core will just fuel the growth of alternative transaction relay mechanisms.

Peter, you really missed my entire argument, didn't you? Maybe my comment was too long? Anyway the gist is that we should not automatically assume without evidence that miners are hostile, wait until the spam gets so bad that bitcoin no longer functions as money, then suddenly blindside the miners with a fork. This makes us the bad actors. Instead, we should first try reasoning with them like adults, by way of the default policy. If they ignore our completely reasonable and mutually beneficial request, then we can consider them hostile and take appropriate action. I see no reason to think that miners would not simply be rational and comply with our request. Yes, it may harm their profits in the short term, but at least no mining pool will have an advantage over any other in this regard. And furthermore, in the long term, bitcoin can continue experiencing healthy growth and functioning properly as the internet's preferred money, which of course all non-hostile miners want anyway.

Heck, we've already seen this happen with full-RBF, as it needed my full-RBF peering fork to reliably get full-RBF replacements to get to miners, particularly initially.

Yes. See my above comment above on fullrbf. That is a different situation.

If a mutually beneficial arrangement cannot be arrived at, then you start using threats of force, and then if that doesn't work, you actually use force.

That you are describing this change as "force" is exactly why so many people call this censorship: you are trying to prevent transactions from getting to miners who would happily mine them.

This is the exact opposite of what I said. Please re-read my comment until it sinks in. I'm specifically not calling this change force. I'm calling it "speaking". Speech is not force. Did you read any of my comment?

I would strongly suggest that rather going down this path, you first convince more hash power to set -permitbaremultisig=0. You'd have a much better argument if, say, a majority of hash power wasn't mining those transactions.

"Convincing more hash power to set -permitbaremultisig=0" is precisely what I'm doing right now, by lobbying for this PR to be merged into bitcoin core. Sitting on our hands and pretending like the user community's voice carries no weight will certainly not change anything. I can't think of a more effective way to convince a large percentage of hashpower to disable p2ms. Can you?

@1440000bytes

The default mempool policy serves a similar purpose. Can miners circumvent these limits? Absolutely, but there are harsh consequences, and ultimately miners' interests are much better served by simply playing by the rules.

What are the harsh consequences of changing mempool policies in a permissionless network?

For example, Mara pool when they mined OFAC-compliant blocks. This was clearly a hostile move, and was clearly done for short-term profit. They were almost immediately forced to stop because they knew hashers would move to other pools.

Also F2Pool, same deal.

"Convincing more hash power to set -permitbaremultisig=0" is precisely what I'm doing right now, by lobbying for this PR to be merged into bitcoin core. Sitting on our hands and pretending like the user community's voice carries no weight will certainly not change anything.

Are the people who disagree with this pull request part of the user community?

Assuming they're users of bitcoin, of course they are. However, I don't know anyone who disagrees with this pull request because they think the spam is a good thing. Even the spammers themselves say it's "toxic waste". The only reason I've heard as to why we shouldn't merge this PR is that "it won't work", including from yourself. You never said the spam was a good thing, and I'd be very surprised if you thought that. So why not just tell the miners what you think and see what they do? Maybe they'll ignore us or maybe they won't, but asking for their help with rate-limiting the spam can't hurt.

These are the examples for excluding some transactions. permitbaremultisig=1 does not exclude but include bare multisig transactions.

I don't see how this is relevant. Default mempool policy can either exclude or include certain classes of transactions. Altering these defaults is defying the user community's explicitly stated wishes.

Ocean is a good example of following a different mempool policy for some templates which excludes some transactions. Although it seems irrational but the pool may continue to work at least for a few years.

I expect Ocean to last a long time because they appear to be actually concerned with the long-term viability of bitcoin, and users do mostly seem to think the transactions they filter are harmful, with the possible exception of some types of transactions from Samourai, which as I understand was not intentional on Ocean's part. I hope they are working on a solution to this. Anyway, this won't be relevant if they succeed in delegating template creation to their hashing operators.

The kind of tracking US government is doing for locating miners raises some concerns about regulations. It will be sad but won't surprise me if some pools exclude OFAC transactions in their blocks but continue to work with enough hashrate.

I would be very surprised if any mining pool could manage this for long.

I don't consider these transactions spam. It's a different way to use money(bitcoin) that some people do not agree with and follows consensus rules.

I'm curious: what would you consider spam, or an inappropriate/abusive use of bitcoin? Are you really trying to say that no amount of non-monetary usage of bitcoin is inappropriate? If 100% of transactions are for storing data on-chain, while 0% are for sending money, would you not consider that abuse?

An alternative way to convince miners to exclude some transactions would be to use permitbaremultisig=0 for your nodes, document arguments for/against and contact mining pools directly.

This is clearly not a serious suggestion. My node, by itself, has no influence on what gets mined, and it's very unlikely that any mining pool would volunteer to forgo short term profits if no other mining pools were doing this, and the user community was explicitly saying "sure, go ahead it's fine, mine the spam" as our default policy is doing currently. Again, Ocean is a special case because they committed from the start not to mine spam.

Note: Some mining pools use bitcoin core with patches and don't mind changing default policies if it maximizes fees, no security issues etc.

Right, and what I'm saying is that, insofar as the default mempool policy is an accurate reflection of the user community's wishes, mining pools altering it for short-term gain can be seen as a hostile move, and should be dealt with as such. Since the current default policy is not an accurate reflection of our preferences, this damages miners' respect for the user community and makes them much more likely to just do whatever they prefer, which, as explained above, can only result in short-term interests becoming increasingly dominant over time.

@chrisguida

For example, Mara pool when they mined OFAC-compliant blocks. This was clearly a hostile move, and was clearly done for short-term profit. They were almost immediately forced to stop because they knew hashers would move to other pools.

(emphasis mine)

Why do you think Mara was mining OFAC compliant blocks for short-term profit? They were leaving fees on the table, and I'm unaware of any short term financial incentive they had to to block those transactions. Rather, I would call that an example of them doing something for long-term gains, eg, not risking being shut down by the US government in the long run.

Most likely a combination of outrage and less risk-adverse legal advice convinced them that the long term gains weren't really worth the short term risk of losing hash power. Which is the opposite scenario of the point you were trying to make.

@petertodd

Why do you think Mara was mining OFAC compliant blocks for short-term profit? They were leaving fees on the table, and I'm unaware of any short term financial incentive they had to to block those transactions.

I would think this is obvious. Filtering OFAC-sanctioned transactions costs a mining pool at most a few hundred dollars per day, while maintaining a good ESG score allows them to raise much more capital from investors. In fiat world, the most profitable strategy is usually to simply out-raise your competitors, and not to worry as much about revenues from clients / users.

Rather, I would call that an example of them doing something for long-term gains, eg, not risking being shut down by the US government in the long run.

Right, but there's an even longer-term consideration here: the survival and proper functioning of the bitcoin network. Bitcoin operates on very long time scales, and any individual action a miner takes to increase their profit at the expense of bitcoin's systemic health, is putting short-term interests ahead of long-term interests.

Most likely a combination of outrage and less risk-adverse legal advice convinced them that the long term gains weren't really worth the short term risk of losing hash power. Which is the opposite scenario of the point you were trying to make.

No, this is exactly the point I'm making. In this scenario there are various timescales to consider:

1. Fees. These are the shortest timescale, and also the least significant factor (~$100/day?)
2. Hashpower. Short-to-medium timescale, very significant risk, as we both agree:

The default mempool policy serves a similar purpose. Can miners circumvent these limits? Absolutely, but there are harsh consequences, and ultimately miners' interests are much better served by simply playing by the rules.

3. Investment Capital. Medium-to-long-term, risk varies a lot depending on who their expected investors are. Obviously Mara, being a public company, is much more sensitive to things like ESG, whereas other pools are not.
4. Regulatory entanglements. Medium-to-long-term. Very significant risk.
5. Reputation within the bitcoin community. Can vary on short timescales and long timescales. Very significant risk.
6. Bitcoin's survival and proper functioning. This is the longest-term concern, without which none of the other things ultimately matter.

People are going to make them because they've been tricked into thinking they're unpruneable by scammers, they can always make slightly less efficient spam other ways that are just as bad. That's even assuming miners would leave this money on the table.

concept NACK

@instagibbs thanks for the response! I'd like to understand your concerns a bit more here, because it appears there is a disconnect here between the concerns of some devs and the concerns of users. What is the negative outcome that you are trying to avoid by nacking this PR? I'd like to understand the damage you think this PR will cause.

I believe I've already stated my case about the negative outcomes I'd like to avoid in my comment above. Please give it a read if you're interested in hearing my side.

wish to change my feedback to Approach NACK, it might be more appropriate to express how i see this whole thing.

Okay, so it looks like Stamps is migrating to a different format, so this seems like a good opportunity to merge this now while no one is using it, right?

Shouldn't be "controversial" anymore, right?

Concept NACK

It looks like a decent amount of P2MS outputs are still being created by users (https://transactionfee.info/charts/inputs-and-outputs-p2ms/).

If we change the default, we'll therefore likely end up degrading compact block relay, as miners would still be incentivised to mine these transactions while (presumably) most of the network wouldn't change the default.

Relaying anything by default that demonstrably only gets used for malicious purposes (which in this case was openly stated by the perpetrator) remains perplexing and embarrassing.

@dergoegge Think longer-term. It's a terrible precedent to say "oh, scam token protocols are using some old tx format that no one uses anymore because it's extremely inefficient, but we can't disable it because the scammers are paying miners tx fees". Following that precedent to its logical conclusion, bitcoin will eventually become only scam token protocols because gullible "investors" can always afford much more in miner fees than legitimate users if they think their $100 tx fee will lead to their scam token attaining a value of $1M someday.

Also,

If we change the default, we'll therefore likely end up degrading compact block relay, as miners would still be incentivised to mine these transactions while (presumably) most of the network wouldn't change the default.

...the dust filter works exactly as you describe, and yet miners do not mine dust transactions very often. This is because demand for scam token protocols that use dust has diminished practically to zero, because of the filters bitcoin core implemented years ago to mitigate this abuse. It's a fallacy, easily contradicted by history, to assume that demand for such protocols will remain strong as the price of confirming their transactions skyrockets due to proper filtering.

Closing as this lacks conceptual support and is still obviously controversial.