set DEFAULT_PERMIT_BAREMULTISIG to false
#28217
Conversation
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee 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. ConflictsNo 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 forever1. Moreover turning off 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. Footnotes |
|
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.. |
Retropex
changed the title
DEFAULT_PERMIT_BAREMULTISIG to false
|
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. |
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). |
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? |
With my node that has been constantly spammed for seven months with catastrophic consequences on the UTXOs set. |
|
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. |
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. |
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. |
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? spoilerevil mempool is among the largest existential threats to bitcoin and we absolutely have no way to stop it from coming into existence. in fact unnecessarily restrictive mempool policy naturally incentivizes it's emergence.people attempting to effectively filter economically motivated, paying market for block space will most likely result in perverse outcomes that may hurt the security assumptions badly. basically opens the door for reorg markets because it solves the whole coordination problem. |
|
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.
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. |
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 |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
|
I keep reading ideological points and no one insists on a very basic thing:
An example: On the contrary, the default for bare multisig is true, even if they have been overcome by BIP16, so the user has to manually switch to false to disable this feature. This is not coherent. So, the users should have always the ability to activate such features by changing the nodes' policies, but the default status should be false. ACK. |
|
@theDavidCoen "Default off everything" is not at all how Bitcoin Core development works. If it did, the node would by default not communicate with the network ( How it actually (usually) works is the default parameters are changed when there is consensus to change them. If there isn't, the status quo holds. For example, I don't doubt that |
I got your point but I didn't mention "Default off everything". In this specific case, bare multisig were useful before P2SH. I edited the previous comment to make it more clear. |
|
I think the discussion on this PR is so spirited because it speaks to a more fundamental question of how to make changes to the bitcoin network. Please let me know if there is a more appropriate forum for this discussion, I'm happy to take this elsewhere.
@petertodd Thanks for the clarification... this is a totally different point from your original nack, but let's address it as well. 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. Many miners, of course, are users themselves, and of course they don't want to see bitcoin's blocks polluted with such a high volume of spam that it starts to drown out real monetary use cases, nor are they interested in seeing bitcoin's utxoset ballooning so rapidly in size that it prices most individuals out from ever being able to run and use their own node. Almost no one that I've talked to thinks the spam is a good thing. Even the people who disagree with changing the default mempool policy mostly agree that the spam is bad and if something could be done about it, they'd be all for it. The crazy thing is, it's very easy for us to do something about it. All we need to do is find our voice as a user community and state our preferences loudly and clearly. The default mempool policy in bitcoin core is historically how we have achieved this, because it's the supermajority client of choice, and its default policy is unambiguous and impossible to misinterpret. It is our voice. Right now, that voice is telling miners "hey, it's fine if you confirm spammy transactions, we don't care." This is incorrect. Again, almost no one I've talked to thinks that the spam is a good thing. We'd all prefer for the miners to help us rate limit this type of abuse if they can, because that's good for everyone. So when our voice is saying that it's okay for miners to confirm abusive transactions, our voice is lying. Not only that, but the longer we lie, the more difficult it will be for us to justify a reversal in our position later. Generally when you have a dispute with someone, the first thing you do is describe how you would like the other party to change their behavior and politely request that they do so. Often, it's no inconvenience to them, and so they immediately comply (unless they are a psychopath). In case they are inconvenienced by this, a negotiation can ensue. As long as both parties keep each other's interests in mind, it's usually fairly straightforward to arrive at an arrangement that is mutually beneficial (again, unless one party is a bad actor). 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. The vast majority of people I've talked to who are against changing the default mempool policy are in support of some kind of soft fork to invalidate blocks that don't filter sufficiently, once the spam gets bad enough, because "a consensus change is the only thing that will be effective". This position is incoherent. This is tantamount to suggesting that, if someone harms you in some way (whether they are aware of the harm or not), you should just stay silent and allow them to continue harming you until you can't take it anymore, and then suddenly you punch them in the face out of the blue. This is the worst possible strategy, as it almost certainly leads to a long, drawn-out, mutually destructive conflict, when you could have just said "hey, can you stop that?" right at the beginning, and that probably would have been the end of it. Once we make our preferences known in a polite and unambiguous way, I expect the miners to simply comply with our request, as this is in everyone's long-term interests, including theirs. Again, the only reason the miners would ignore a clear and polite request from the user community and run their own clients instead is if they are bad actors who don't care about the long-term success of bitcoin. I don't think mining pool operators are bad actors. But if they are, we can only find out after communicating our preferences, by watching how they react. 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. Merging this PR will send a clear signal to the mining community that we do not approve of these spam transactions and would like them to be rate-limited. Yes, of course mining pools may choose to mine a nonstandard transaction here and there, and that's fine; the purpose is not to totally ban such transactions; the purpose is only to reduce harm to users who are trying to use bitcoin as money, the way it was intended. So, let's stop lying and merge this PR, now. In all probability, the miners will be happy to oblige, as their success and bitcoin's success are intertwined. They will likely be relieved and maybe even grateful since 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. (As @BitcoinMechanic pointed out, hashing operators abandon hostile pools very quickly). The miners themselves have likely been feeling anxiety over our mixed messaging, and worrying about potentially repeating the events of 2017, which didn't go well for the mining pools who chose to be hostile. I doubt anyone is eager to repeat the events of 2017, but we can and will if that's what it comes to. But again, I don't think this is at all necessary or likely. The default mempool policy is our voice. It's time for us to speak. |
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
It's not. As long as miners are uninterested in setting
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 |
|
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 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. |
If it's so trivial, you should do that first: get a majority of hash power to set
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.
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. |
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.
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.
Agreed, I don't think you understood what I wrote there.
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. |
There was a problem hiding this comment.
ACK 8672721
ACK.
@theDavidCoen In your review #28217 (comment), per https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#code-review (and to be counted by DrahtBot and the merge script), your ACK would need to be followed by the commit hash. See above here or #28217 (review) for examples.
| P2P and network changes | ||
| ----------------------- | ||
|
|
||
| - Changing the default setting of -permitbaremultisig to false. Non-P2SH multisig transactions will no longer be relayed by default. (#28217) |
There was a problem hiding this comment.
Only if you need to repush, so as not to invalidate the current review ACKs, in commit 8672721 perhaps consider the following diff.
-P2P and network changes
------------------------
+Updated settings
+----------------
-- Changing the default setting of -permitbaremultisig to false. Non-P2SH multisig transactions will no longer be relayed by default. (#28217)
\ No newline at end of file
+- The default value of the `-permitbaremultisig` configuration option is changed
+ from true to false. Non-P2SH multisig transactions will be considered
+ non-standard by the node and no longer relayed by default. (#28217)
Its not necessary to run a separate client to achieve this (if required in future). A simple python script that works as a bitcoin core plugin could do it: https://gitlab.com/-/snippets/3645894 |
|
@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.
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
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.
No, they wouldn't xD. You did not read my message. Please note this part:
And this part:
And this part:
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
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.
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 Conversely, with (In both cases, the user community is misrepresenting its preferences and this should be rectified.)
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.
Yes. See my above comment above on fullrbf. That is a different situation.
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?
"Convincing more hash power to set |
What are the harsh consequences of changing mempool policies in a permissionless network?
Are the people who disagree with this pull request part of the user community? |
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.
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. |
Note: Some mining pools use bitcoin core with patches and don't mind changing default policies if it maximizes fees, no security issues etc. |
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.
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.
I would be very surprised if any mining pool could manage this for long.
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?
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.
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. |
(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. |
It is relevant and I have edited the comment to make the difference more clear. There is another technical difference in excluding and including. You just need a small percentage of nodes and miners for some transactions to be included. While excluding requires almost everyone to follow the same policy.
Ocean mining pool is not using defaults for some of their templates. User community has different opinions. Unfortunately we can't change all defaults in core based on Ocean's preferences. |
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.
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.
No, this is exactly the point I'm making. In this scenario there are various timescales to consider:
|
|
After re-evaluating everything, I ACK this pull request. It makes bitcoin core policies or mempool useless. Apart from Libre Relay client, it is possible to do similar thing with a python script. Need to improve, because conf saved is used after relaunch. https://gitlab.com/-/snippets/3645894 This pull request should be merged so that some people can do political drama on twitter but bare multisig tx will be included in blocks. |
|
ACK 8672721 |
This comment was marked as abuse.
This comment was marked as abuse.
Sorry, something went wrong.
|
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. |
|
Related: https://archive.is/ieLKV |
|
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? |
The default activation of the
permitbaremultisig=0option proposes an enhancement for the Bitcoin network. By refusing non-P2SH multisignature transactions from the outset, this modification would contribute to reducing spam attempts and maintaining a healthy decentralization by discouraging undesirable activities.