set `DEFAULT_PERMIT_BAREMULTISIG` to false

Retropex commented at 6:37 pm on August 4, 2023: none

The default activation of the permitbaremultisig=0 option 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.

DrahtBot commented at 6:37 pm on August 4, 2023: contributor

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.

Type	Reviewers
ACK	chrisguida, TheCharlatan, nsvrn, 1ma, jonatack, 1440000bytes
Concept NACK	coinables, vostrnad, ghost, mikeinspace, pajasevi, samouraiwallet, dplusplus1024, owenstrevor, russeree, eragmus, petertodd, totient, instagibbs
Concept ACK	luke-jr, RobinLinus, Sun0fABeach, HenrikJannsen, achow101, Symphonic3, Semisol, M-BTC, viresinnumeris-1, ChrisMartl, Fiach-Dubh, BitcoinMechanic, desi-bitcoiner, RicYashiroLee, theDavidCoen
Approach NACK	moonsettler

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.

luke-jr commented at 7:07 pm on August 4, 2023: member

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.

RobinLinus commented at 7:59 pm on August 4, 2023: none

Concept ACK. Long overdue.

1ma commented at 8:29 pm on August 4, 2023: none

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.

https://stampchain.io/ ↩︎

ghost commented at 9:54 pm on August 4, 2023: none

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

Crazyk031 commented at 9:57 pm on August 4, 2023: none

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

This is not Bitcoin..

Retropex renamed this:
~~set DEFAULT_PERMIT_BAREMULTISIG to false~~
set `DEFAULT_PERMIT_BAREMULTISIG` to false
on Aug 4, 2023

Sun0fABeach commented at 10:24 pm on August 4, 2023: none

Concept ACK

Very important step to close this attack vector.

HenrikJannsen commented at 11:02 pm on August 4, 2023: none

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.

linkinparkrulz commented at 0:12 am on August 5, 2023: none

“It would also promote the adoption of best practices.”

Best practices in accordance with whom?

vostrnad commented at 1:25 am on August 5, 2023: none

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.

DrahtBot added the label CI failed on Aug 5, 2023

in src/policy/policy.h:39 in 52b318811b outdated

35@@ -36,7 +36,7 @@ static constexpr unsigned int DEFAULT_INCREMENTAL_RELAY_FEE{1000};
36 /** Default for -bytespersigop */
37 static constexpr unsigned int DEFAULT_BYTES_PER_SIGOP{20};
38 /** Default for -permitbaremultisig */
39-static constexpr bool DEFAULT_PERMIT_BAREMULTISIG{true};
40+static constexpr bool DEFAULT_PERMIT_BAREMULTISIG{false};

jonatack commented at 2:39 am on August 5, 2023:

As a minimum, the tests would need to pass (if there is rough consensus on the change).

 0diff --git a/src/test/script_p2sh_tests.cpp b/src/test/script_p2sh_tests.cpp
 1index 739ab75de36..4e1225452fb 100644
 2--- a/src/test/script_p2sh_tests.cpp
 3+++ b/src/test/script_p2sh_tests.cpp
 4@@ -201,7 +201,7 @@ BOOST_AUTO_TEST_CASE(set)
 5     {
 6         SignatureData empty;
 7         BOOST_CHECK_MESSAGE(SignSignature(keystore, CTransaction(txFrom), txTo[i], 0, SIGHASH_ALL, empty), strprintf("SignSignature %d", i));
 8-        BOOST_CHECK_MESSAGE(IsStandardTx(CTransaction(txTo[i]), reason), strprintf("txTo[%d].IsStandard", i));
 9+        BOOST_CHECK_MESSAGE(i != IsStandardTx(CTransaction(txTo[i]), reason), strprintf("txTo[%d].IsStandard", i));
10     }
11 }
12 
13diff --git a/test/functional/mempool_dust.py b/test/functional/mempool_dust.py
14index f4e385a1123..e0c026207ae 100755
15--- a/test/functional/mempool_dust.py
16+++ b/test/functional/mempool_dust.py
17@@ -40,6 +40,7 @@ DUST_RELAY_TX_FEE = 3000  # default setting [sat/kvB]
18 class DustRelayFeeTest(BitcoinTestFramework):
19     def set_test_params(self):
20         self.num_nodes = 1
21+        self.extra_args = [['-permitbaremultisig']]
22 
23     def test_dust_output(self, node: TestNode, dust_relay_fee: Decimal,
24                          output_script: CScript, type_desc: str) -> None:
25@@ -101,7 +102,7 @@ class DustRelayFeeTest(BitcoinTestFramework):
26             else:
27                 dust_parameter = f"-dustrelayfee={dustfee_btc_kvb:.8f}"
28                 self.log.info(f"Test dust limit setting {dust_parameter} ({dustfee_sat_kvb} sat/kvB)...")
29-                self.restart_node(0, extra_args=[dust_parameter])
30+                self.restart_node(0, extra_args=[dust_parameter, "-permitbaremultisig"])
31 
32             for output_script, description in output_scripts:

Retropex commented at 10:47 am on August 5, 2023:

PR updated.

Your changes worked on my side.

jonatack commented at 5:01 pm on August 5, 2023:

PR updated.

You’ll need to squash the updates required for the tests to pass into the same commit as the code change.

Retropex commented at 10:22 am on August 7, 2023:

You’ll need to squash the updates required for the tests to pass into the same commit as the code change.

Done.

cesarmassri commented at 2:53 am on August 5, 2023: none

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).

RobinLinus commented at 2:59 am on August 5, 2023: none

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.

vostrnad commented at 10:11 am on August 5, 2023: none

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?

Retropex commented at 10:13 am on August 5, 2023: none

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.

vostrnad commented at 10:58 am on August 5, 2023: none

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.

DrahtBot removed the label CI failed on Aug 5, 2023

Retropex commented at 12:38 pm on August 5, 2023: none

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.

in src/test/script_p2sh_tests.cpp:204 in 6be3bad9a9 outdated

200@@ -201,7 +201,7 @@ BOOST_AUTO_TEST_CASE(set)
201     {
202         SignatureData empty;
203         BOOST_CHECK_MESSAGE(SignSignature(keystore, CTransaction(txFrom), txTo[i], 0, SIGHASH_ALL, empty), strprintf("SignSignature %d", i));
204-        BOOST_CHECK_MESSAGE(IsStandardTx(CTransaction(txTo[i]), reason), strprintf("txTo[%d].IsStandard", i));
205+        BOOST_CHECK_MESSAGE(i != IsStandardTx(CTransaction(txTo[i]), reason), strprintf("txTo[%d].IsStandard", i));

luke-jr commented at 4:52 pm on August 5, 2023:

??? this change makes no sense to me. i is an int, but IsStandardTx returns a bool…

luke-jr commented at 4:54 pm on August 5, 2023:

See b90ef78f7ab564fb5948583e7a5b5399f9798301 for how I fixed this in Knots

jonatack commented at 4:57 pm on August 5, 2023:

@luke-jr an int of 0 is false, 1 is true, and other integer values are equal to neither. The tests can be updated differently, of course. I was mainly curious to see which tests are affected by the change.

ajtowns commented at 0:01 am on August 11, 2023:

(i == 1) == IsStandardTx(..) would probably be clearer then?

ajtowns commented at 3:10 am on August 19, 2023:

With this current code, for i>1 it doesn’t matter what IsStandardTx returns, the BOOST_CHECK will succeed either way.

Here’s a patch that just tests both cases so it doesn’t depend on the value of DEFAULT_PERMIT_BAREMULTISIG: https://github.com/ajtowns/bitcoin/commit/1c139da6e8d697df419ca40642cb52ca17bdc526

ajtowns commented at 3:59 pm on September 5, 2023:

(Repeating this comment outside of the “resolved” conversation, since this code is buggy as is)

With this current code, for i>1 it doesn’t matter what IsStandardTx returns, the BOOST_CHECK will succeed either way.

Here’s a patch that just tests both cases so it doesn’t depend on the value of DEFAULT_PERMIT_BAREMULTISIG: https://github.com/ajtowns/bitcoin/commit/1c139da6e8d697df419ca40642cb52ca17bdc526

luke-jr changes_requested

coinables commented at 7:04 pm on August 5, 2023: contributor

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.

Fiach-Dubh commented at 7:37 pm on August 5, 2023: none

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

moonsettler commented at 8:21 pm on August 5, 2023: none

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

Fiach-Dubh commented at 8:43 pm on August 5, 2023: none

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.

moonsettler commented at 8:59 pm on August 5, 2023: none

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

achow101 commented at 10:04 pm on August 5, 2023: member

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.

coinables commented at 1:30 am on August 6, 2023: contributor

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.

Symphonic3 commented at 5:16 am on August 6, 2023: none

Concept ACK

1ma commented at 10:07 am on August 6, 2023: none

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.

This is a separate issue that is indeed more critical and should also be addressed, but the fact that a worse attack vector exists is not a valid reason to shrug other ones.

However, since you brought it up I want to point out that Taproot lifting the 10k limit on scripts has not been the main issue with inscriptions. Bloating the blocks with huge data streams is bad enough for full nodes, but bloating the UTXO set is worse and in the last 4 moths it has grown at an unprecedented 40%¹ due to a tidal wave of BRC-20 transactions that pay more fees than sats they move just to inscribe small json payloads that are well below 10k bytes².

Fortunately detecting these transactions does not involve decoding the script and looking for ASCII strings or some other patterns of data. It’s as simple as detecting the OP_0 OP_IF data envelope in the script, and an unofficial patch that does that has been circulating informally since early February³. I see no reason why a more refined version of this patch (with proper unit tests etc) should not make its way into Bitcoin Core eventually, as it’s the same kind of issue (and mitigation) we’re dealing in here.

https://statoshi.info/d/000000009/unspent-transaction-output-set?orgId=1&refresh=5s&from=now-1y&to=now&viewPanel=8 ↩︎
See for instance this transaction and its block, which is filled with other BRC-20 inscriptions. This particular transaction inscribed ord text/plain;charset=utf-8 OP_0 {"p":"brc-20","op":"mint","tick":"sats","amt":"100000000"}: ↩︎
https://gist.github.com/luke-jr/4c022839584020444915c84bdd825831 ↩︎

unknown changes_requested

unknown commented at 10:39 am on August 6, 2023: none

NACK

After reading recent discussion about standardness, I think we should relax some standardness rules in Bitcoin Core if P2P has to remain relevant for transaction relay of a censorship resistant network.

Even if false is made default in next version, there will be some nodes and miners allowing bare multisig and that’s all a normal user needs to use bare multisig.

1ma commented at 10:48 am on August 6, 2023: none

@zkfrio your statement is contradictory. If bare multisig inscribers can easily route around mempool policy then there’s no reason to oppose the change. If you ACK this proposal everyone can have their slice of pie.

vostrnad commented at 11:54 am on August 6, 2023: none

I ran the numbers on bare multisig usage between blocks 700,000 and 800,000 (approx. last two years). Because most of bare multisig activity is never spent outputs, I focused on bare multisig inputs and how old the spent coins are.

There were 940 bare multisig inputs during the analyzed period. 28% of them were spending coins created in the same block, while the median coin age was 224 blocks, and 90% of the coins were 14,599 blocks or fewer old. So while the actual usage of bare multisig for transactions is low, it’s not just people sweeping old wallets, and they would be negatively impacted by not being able to create new outputs.

So for now, assuming this change is adopted and the peer-to-peer network stops reliably relaying transactions creating bare multisig outputs, these appear to be the consequences:

People determined to store data in the UTXO set (which is a terrible idea, but they still do it) will move to a different output type (such as P2TR, or perhaps an unused 40-byte SegWit output type) with slightly lower encoding efficiency, with potentially worse consequences for the UTXO set size.
However, since the actual usage of bare multisig even for outputs is low, the actual consequences for the UTXO set are likely to be negligible either way.
A small minority of users who appear to actually be using bare multisig for transactions will be forced to move to a different output type.

As there don’t appear to be any benefits of this change, it’s a NACK from me.

Side note, a proposal to change the default policy really should be accompanied (I’d even say preceded) by a post to the bitcoin-dev mailing list.

Semisol commented at 1:56 pm on August 6, 2023: none

Concept ACK

I do not see the negative impact of this change, as there is a heavy incentive to use P2WSH or P2SH due to the cost savings and/or wallets not being able to send to bare multisigs easily.

This also has the additional benefit of encouraging adoption of more widely supported standards and preventing spam.

Could I also propose also disallowing P2PK?

ghost commented at 5:04 pm on August 6, 2023: none

@zkfrio your statement is contradictory. If bare multisig inscribers can easily route around mempool policy then there’s no reason to oppose the change. If you ACK this proposal everyone can have their slice of pie.

It is not contradictory if you understand how bitcoin works. This will create different mempool and P2P or incentivize a system that allows all transactions that follow consensus rules. It’s a slippery slope.

If you think bare multisig is bad for multisig for bitcoin. Share on mailing list and see outcome.

I want to see some transactions to be non standard? Would you do it?

Users can still “spam” so there is no reason to change default in core. You don’t even understand spam. Only being emotional and looking for attention.

Davidson-Souza commented at 5:23 pm on August 6, 2023: none

PSA (please don’t kill the messenger, I’m just adding context to the pr) this pr will likely break BIP47 payment codes, at least version 3. I’m not saying this is good or bad, but I think at least a “heads-up” will be a good practice if this goes through.

ghost commented at 6:21 pm on August 6, 2023: none

PSA (please don’t kill the messenger, I’m just adding context to the pr) this pr will likely break BIP47 payment codes, at least version 3. I’m not saying this is good or bad, but I think at least a “heads-up” will be a good practice if this goes through.

BIP 47 uses OP_RETURN

If anything else, we need their developers to comment else nobody cares about a project who is making money off other researchers.

1ma commented at 6:24 pm on August 6, 2023: none

PSA (please don’t kill the messenger, I’m just adding context to the pr) this pr will likely break BIP47 payment codes, at least version 3. I’m not saying this is good or bad, but I think at least a “heads-up” will be a good practice if this goes through.

This is IMO a valid objection. But to be precise BIP47 payment codes are not broken as they use OP_RETURN, and v3 has not been rolled out yet (?). Is there any reason the draft couldn’t be amended to build v3 on OP_RETURN, too?

Davidson-Souza commented at 6:53 pm on August 6, 2023: none

BIP 47 uses OP_RETURN

Version one does. Version two uses a 1 of 2 MS in a p2sh and version 3 uses p2ms.

This is IMO a valid objection. But to be precise BIP47 payment codes are not broken as they use OP_RETURN, and v3 has not been rolled out yet (?). Is there any reason the draft couldn’t be amended to build v3 on OP_RETURN, too?

This is not a draft, this is the final spec implemented by Samurai (I think Blue Wallet and Sparrow also does). They didn’t update BIP047 because of some disagreements between the developers and the BIPs repo. But this is not relevant here, the latest version, to my knowledge is v3 that uses p2ms.

ghost commented at 9:01 pm on August 6, 2023: none

This is not a draft, this is the final spec implemented by Samurai (I think Blue Wallet and Sparrow also does). They didn’t update BIP047 because of some disagreements between the developers and the BIPs repo. But this is not relevant here, the latest version, to my knowledge is v3 that uses p2ms.

Samourai- nobody cares about that project who is making money from others efforts.
None of them use P2MS, do some research.

Still NACK

samouraiwallet commented at 10:21 pm on August 6, 2023: none

Ignoring the unwarranted ad hominem.

I have no desire to wade into what appears to be a bunch of meddling with the code base for no good reason (bare multsig outputs are not the cause of the increased spam, as I am sure you know).

I will simply confirm that Samourai Wallet implements Version 1 of BIP47 which doesn’t use bare multsig but rather OP_RETURN. There are at least 200,000 BIP47 payment codes (that users have opted in to uploading to a public web directory) in the wild across three independent wallets - with more coming I am told.

Regarding version 3 payment codes, we have fully implemented Version 3 of BIP47 into our wallet library ExtLibJ for over a year. See test vectors here https://code.samourai.io/wallet/ExtLibJ/-/blob/develop/src/test/java/com/samourai/wallet/bip47/rpc/obpp05/TestVectorsOBPP_RFC05.java

I don’t think it is wise to assume that no one is using BIP47 Version 3, nor should it be expected that developers come pay homage and plead their case to the maintainers and contributors of this repository as was suggested earlier in the comments.

Thank you @Davidson-Souza and @1ma for thinking of BIP47 in the context of this PR

Concept NACK

Davidson-Souza commented at 10:32 pm on August 6, 2023: none

@samouraiwallet Thank you for your clarifications. I retract myself in claiming Samurai uses v3.

However, as noted:

I don’t think it is wise to assume that no one is using BIP47 Version 3

My comment still stands on, this is a valid additional context to reviewers.

russeree commented at 1:44 am on August 7, 2023: contributor

Concept NACK

This PR won’t stop utxo set bloat. This would not stop bloat of the UTXO set because P2PK still exists. P2MS is just P2PK with the ability to bake up to 2 more pubkeys to the chain even if those pubkeys don’t actually have known private keys.
Long term storage because of the nature of P2SH and P2WSH scripts for multisig. The user is responsible for not only their private keys but also the public keys to recreate the script to spend their funds. P2MS is an incredible alternative to this since the user is only responsible for the private keys since the script exists on chain.
Security P2MS offers 256*m bits of security which is higher than the 160bits of a P2SH script. It will in the future be easier to try to find hash collisions for a P2SH address than it will be to try to use pollard’s rho to factor the private key.
Reducing Dust / Fee planning Placing the scripts on chain reduces the cost to spend the UTXO since the script doesn’t have to be provided to spend. This reduces the amount of dust. An added benefit is that over time if/as fees rise users that used P2MS would actually get a discount when spending compared to script hash based methods.
Application Demand Over time users discover creative solutions to problems or add features. Just because something isn’t used often today. Doesn’t mean that it wont have prevalence tomorrow.
Slippery Slope and Moral Hazard Relay policies like this are a form of censorship in it’s own way. Just because we may not like the way one group is using something and none the less paying shouldn’t be a cause to implement these policies. Only if something is genuinely causing issues and reducing the value of the network should policies be considered.

Example. What happens if FALSE IF becomes contentious? Would we start to consider new relay policies then?

edit: penalization, disincentivization may be better terms than censorship. My brain just interprets this as a change to the incentive structure by making the cost of communication (relaying) higher for those that want to use P2MS.

mikeinspace commented at 1:48 am on August 7, 2023: none

Concept NACK but I would be very amused to see this get merged. We will engineer around it, of course.

We will go straight to mining pools if we have to (who LOVE to include our high fee transactions).

We will continue to use the permissionless Bitcoin protocol as we see fit. #FREEDOM

Fiach-Dubh commented at 2:58 am on August 7, 2023: none

Concept NACK

This PR won’t stop utxo set bloat. This would not stop bloat of the UTXO set because P2PK still exists. P2MS is just P2PK with the ability to bake up to 2 more pubkeys to the chain even if those pubkeys don’t actually have known private keys.

Long term storage because of the nature of P2SH and P2WSH scripts for multisig. The user is responsible for not only their private keys but also the public keys to recreate the script to spend their funds. P2MS is an incredible alternative to this since the user is only responsible for the private keys since the script exists on chain.

Security P2MS offers 256*m bits of security which is higher than the 160bits of a P2SH script. It will in the future be easier to try to find hash collisions for a P2SH address than it will be to try to use pollard’s rho to factor the private key.

Reducing Dust / Fee planning Placing the scripts on chain reduces the cost to spend the UTXO since the script doesn’t have to be provided to spend. This reduces the amount of dust. An added benefit is that over time if/as fees rise users that used P2MS would actually get a discount when spending compared to script hash based methods.

Application Demand Over time users discover creative solutions to problems or add features. Just because something isn’t used often today. Doesn’t mean that it wont have prevalence tomorrow.

Slippery Slope and Moral Hazard Relay policies like this are a form of censorship in it’s own way. Just because we may not like the way one group is using something and none the less paying shouldn’t be a cause to implement these policies. Only if something is genuinely causing issues and reducing the value of the network should policies be considered.

Example. What happens if FALSE IF becomes contentious? Would we start to consider new relay policies then?

Concept NACK but I would be very amused to see this get merged. We will engineer around it, of course.

We will go straight to mining pools if we have to (who LOVE to include our high fee transactions).

We will continue to use the permissionless Bitcoin protocol as we see fit. #FREEDOM

There’s something really ironic about ruseree claiming this would be censorship, with the stamp creators comment afterwards saying his degens will just pay out of band as a work around.

Which is fair, but also demonstrates this is not censorship.

Rather, it increases the cost in time, UX and sats for such unwanted spam.

Which is more than fair, warranted and the current goal.

To raise the cost.

Not stop. But raise the cost.

russeree commented at 3:23 am on August 7, 2023: contributor

There’s something really ironic about ruseree claiming this would be censorship, with the stamp creators comment afterwards saying his degens will just pay out of band as a work around.

Which is fair, but also demonstrates this is not censorship.

I would make the point that it could be considered a form of censorship. My analogy would be this is akin to the same way that social media platforms can make certain context and conversations incredibly difficult to propagate across their platforms. Instead of a conversation here we are discussing a transaction type.

Edit: Better use of language.

RobinLinus commented at 5:27 am on August 7, 2023: none

We will go straight to mining pools […] who include our high fee transactions

Making the spam attacks more costly is the rationale behind this change. And the guy who runs the attack is trying to stop this spam mitigation, (e.g. he’s protesting against it on Twitter), which is a strong indicator that he believes this change will be effective.

Edit: Also note that the spammer publicly states that this is an attack:

M-BTC commented at 7:29 am on August 7, 2023: none

Concept ACK. Bloating the UTXO set should be more costly, especially when the incentives are perfectly clear.

Sun0fABeach commented at 7:51 am on August 7, 2023: none

Concept NACK but I would be very amused to see this get merged. We will engineer around it, of course.

We will go straight to mining pools if we have to (who LOVE to include our high fee transactions).

Since you’re saying these changes won’t cause any issues for you, we can agree to move forward with the PR.

We will continue to use the permissionless Bitcoin protocol as we see fit. #FREEDOM

I’m sure you don’t have any spam filters on your e-mail inbox since that would be censoring a permissionless protocol.

russeree commented at 7:58 am on August 7, 2023: contributor

Making the spam attacks more costly is the rationale behind this change. And the guy who runs the attack is trying to stop this spam mitigation, which is a strong indicator that he believes this change will be effective.

What about P2PK then? It could still be used for the exact same purpose to bloat the UTXO set.

Even deeper this condemns all standard scripts to just be hashes of scripts to avoid users storing data encoded into the script.

RobinLinus commented at 8:08 am on August 7, 2023: none

used for the exact same purpose to bloat the UTXO set

It is more costly to bloat the UTXO set with P2PK. Raising the cost for spammers is exactly the intended purpose of this mitigation. Still, you’re right that it makes sense to open a second PR to make p2pk non-standard as well when it gets abused.

viresinnumeris-1 commented at 8:23 am on August 7, 2023: none

Concept ACK

Bare multisig has barely any non-spam use cases left.

russeree commented at 8:24 am on August 7, 2023: contributor

Alternative

What about reducing the standardness to only accept uncompressed format public keys thus reducing the capacity to spam due to cost. This would roughly double the amount of data that someone would have to include in their tx making the data overhead prohibitively expensive to spam. The efficiency of data storage would also decrease since only 50% of the pubkey data would be usable (the y component would not have valid data. ) Since a compressed point is equal to a uncompressed point P2MS would be functionally equivalent for any developer or users that want to use P2MS as their custody solution. I also doubt anyone creating a standard P2MS or P2PK TX for monetary exchange would have any issue paying the overhead for their tx which would be a maximum of 96 bytes.

Edit: This would not work since only size is checked as a part of is standard not validity of (x and Y) components of the pubkey.

Aside

Just scraped my UTXO set using https://github.com/in3rsha/bitcoin-utxo-dump and filtered my set for only p2ms keeping all row data and the total size is 278MB which is incredibly small even compared to P2PKH which sits at 1.9GB

Here are some sizes to show how little data has actually bloated the UTXO set using P2MS and P2PK, even P2PKH uses far more space at ~10x. *script is the size of the serialized data only

glozow added the label TX fees and policy on Aug 7, 2023

Retropex force-pushed on Aug 7, 2023

1ma commented at 3:43 pm on August 7, 2023: none

Thank you for your input @samouraiwallet.

I admit that when I gave my ACK I thought this change was a no-brainer (for the reasons @mikeinspace exposed above) and now I’m conflicted. I wasn’t aware of BIP47 v3, and in my personal opinion it is a valid use case. I’ve reviewed the extent of the work you and others have done on it in the last years and I’ve realized how extremely pissed you and the more privacy-focused Bitcoin community must be about this proposed change.

However, I have to say that as a full node runner I’m about equally pissed that you designed and implemented a legit use case for storing data onchain that I need to keep in the UTXO set, especially since BIP47 and Whirlpool’s Tx0 have always used OP_RETURN. If BIP47 v3 took off and there were tens of millions of BIP47 v3 notification transactions (which would arguably be a good thing for privacy) it would also contribute to worsen the UTXO set bloat problem for no good reason.

I’m afraid our main goals and time horizons are fundamentally at odds on this issue, so I maintain my ACK. You should have more leeway in 2023 to redesign BIP47 v3 on top of OP_RETURN than I’ll have in 2050 to run a full node if bare multisig data storage for legit use cases were to take off from here on.

To those who argue against the change on the grounds that bare multisig data storage is not so bad today, I’d say that it shows that not a lot of people have cared about it so far, and that it’s better to unstandardize it while that’s the case. On these grounds I also support @Semisol’s suggestion to unstandardize P2PK outputs.

I wasn’t aware of the technical advantages of P2MS over P2SH/P2WSH pointed out by @russeree and they also seem a valid objection to me, but still @vostrnad showed that bona fide P2MS seems to happen very rarely in practice, so given the downsides I don’t think they’re compelling enough for me.

In general, regarding data embedding onchain I think that 80-byte OP_RETURNs are the Schelling point that all camps find tolerable (here I’m excluding self-professed Bitcoin adversaries such as Mike).

Even a good chunk of the people who are opposed to adding new standardness rules claim to only do so because they fear unintended consequences, and because this feels like a never-ending “cat and mouse” game. However this is just one way to frame this situation.

Another way to frame the situation is that Mike, Casey et al are unsuspecting QA engineers working for Bitcoin Core for free, doing what essentially amounts to fuzz testing of the script interpreter. I don’t see why Core cannot freeride on the countless hours they spend looking for contrived ways to embed data onchain to timely maintain an evolving set of standardness rules that nudge users towards OP_RETURN. There surely are talented people that’d like to work on that. The next step in proactiveness would be setting up bounties for finding novel data envelopes that evade the latest spam filters and disclose them responsibly, so that they can be unstandardized before they explode like OP_0 OP_IF did. Maybe it’d be enough motivation for some of these spammers to turn white-hat and do their thing in testnet and signet instead of mainnet.

Finally, there’s the issue of potential full-on tidal wave of off-band spam with this approach. Personally I’m skeptical of the spammers’ ability to actually weaponize the miners against the system. For one, even if they are profit-driven they are also some of the most invested entities in Bitcoin’s success. For the other, if off-band spam really got to a point where it threatens the system I guess they’d jack up the off-band fees to a point where it evens out. However I can’t back this up, it’s just what seems more likely to me.

pajasevi commented at 11:49 pm on August 7, 2023: none

Sorry @1ma but I must correct you because your premise is wrong:

If BIP47 v3 took off and there were tens of millions of BIP47 v3 notification transactions (which would arguably be a good thing for privacy) it would also contribute to worsen the UTXO set bloat problem for no good reason.

v3 notification transactions do not bloat the UTXO set because they are meant to be spent after they are made. Citing from the OBPP5:

Alice’s wallet should spend the notification change output at the next appropriate opportunity.

Justus Ranvier designed it that way so that these notifications are more block space efficient and do not create any waste UTXOs on notification addresses like v1 does. He also thought about when these notification outputs should be created so that there really is no waste:

Wallets SHOULD prefer to create of notification outputs in any situation where a change output is required, if the wallet knows of the existence of any payment codes but has not yet sent a notification.

1ma commented at 7:46 am on August 8, 2023: none

Fair, I assumed they worked like v1 notifications. Then they don’t have the footprint I thought (and now I understand why it’s better than v1’s, like you told me on Twitter), but I hope my message conveyed that I’m not specifically concerned about BIP47 v3 (which I see as legit), but more generally about leaving the door open to easily embed data in the UTXO set:

You should have more leeway in 2023 to redesign BIP47 v3 on top of OP_RETURN than I’ll have in 2050 to run a full node if bare multisig data storage for legit use cases were to take off from here on.

I know me saying it doesn’t make any difference, but I have absolutely no desire to piss on your roof. As I said yesterday our main goals are at odds, and at the end of the day I care more about mitigating these loopholes and nudging data embedding towards OP_RETURN than I care about BIP47 v3, and the opposite goes for you.

pajasevi commented at 8:22 am on August 8, 2023: none

v3 payment codes to be redesigned on top OP_RETURN would just mean switching back to v1 scheme. You would understand that if you actually understood those specifications.

I didn’t come here to debate the nuances of “banning” certain transactions on P2P layer because, frankly, I don’t agree with the premise. I came here to refute the nonsense that was claimed by people who should know better. And since I don’t agree with the premise, the execution and the results, I totally NACK this.

ChrisMartl commented at 7:08 am on August 11, 2023: none

Concept ACK

jonatack commented at 5:55 pm on August 14, 2023: contributor

I think this change would also need a release note, though it could be done in a follow-up pull.

in doc/release-notes/release-notes-26.0.md:1 in 5e005460cd

Retropex commented at 9:47 pm on August 14, 2023:

@jonatack Do I have to add other elements?

jonatack commented at 10:28 pm on August 14, 2023:

The note should probably refer to the -permitbaremultisig configuration option, and the commit message something like Release note for changing -permitbaremultisig config default to false

Retropex commented at 11:18 pm on August 14, 2023:

Updated.

achow101 commented at 10:08 pm on August 14, 2023: member

Please see https://github.com/bitcoin/bitcoin/blob/master/doc/developer-notes.md#release-notes for how release notes should be added for a PR.

Retropex force-pushed on Aug 14, 2023

russeree commented at 0:47 am on August 15, 2023: contributor

The status of BIP0011 likely should be changed to obsolete or modified to reflect changes to enablement if or upon merge as well since it would no longer be applicable to Bitcoin as intended. Does a new BIP need to be constructed to obsolete BIP0011? My position remains as NACK; none the less just brining about some of my thoughts and how they pertain if there was a merge.

Edit: Digging deeper

Technically there is not a need to replace a BIP to obsolete it. Per BIP002 When a Final BIP is no longer relevant, its status may be changed to Replaced or Obsolete (which is equivalent to Replaced). This change must also be objectively verifiable and/or discussed.
There is no precedent for obsoleting an ‘active’ BIP before. only BIP0064 has moved from draft->obsolete.
The replaced option for the status of BIP0011 doesn’t make sense unless there is a replacement for BIP11 outlining the reasons removing BIP0011 form isStandard improves BitCoin. This doesn’t make much sense because it would be a negation BIP
The context of BIP11 explicitly adding bare-multisig to isStandard() would force a change of status of the BIP if this got merged.

A personal thought: A BIP obsoleting change should have a larger and more diverse set of community discussion. Possibly even running it through the mailing list first. As it stands the ACKs/NACKs ratio doesn’t even reach 2/3, currently at 64.5% ACK rate

Edit 2: Some additional thoughts and info

I ran some scripts against the stamps encoded P2MS transactions. Scraping the data of 74188 that were present at height 803187.

Figure_1e

Figure_1

Edit 3: For DraghtBot my stance is still NACK

Retropex commented at 10:26 am on August 15, 2023: none

A personal thought: A BIP obsoleting change should have a larger and more diverse set of community discussion. Possibly even running it through the mailing list first. As it stands the ACKs/NACKs ratio doesn’t even reach 2/3, currently at 64.5% ACK rate

Although there was a debate in particular with the BIP47, we must not forget that some people like Mike are there only to protect their business with the src-20 and stamps. They absolutely do not care about the decentralization of Bitcoin and the consequences it has on the nodes.

In addition, on your graph we see that the demand for stamps is much calmer, but absolutely nothing prevents a new wave of stamps. I think we must not wait for a new wave to act.

dplusplus1024 commented at 8:33 pm on August 15, 2023: contributor

NACK - Let’s keep mining decentralized.

russeree commented at 0:31 am on August 16, 2023: contributor

Primary Response

@Retropex The statement provided is fairly rife with fallacies. Noting a couple of them here with a solution at the bottom.

Although there was a debate in particular with the BIP47, we must not forget that some people like Mike are there only to protect their business with the src-20 and stamps. They absolutely do not care about the decentralization of Bitcoin and the consequences it has on the nodes.

Ad Hominem (Attacking a Person): Just because Mike has a business interest doesn’t automatically invalidate his statement. In addition do we actually know if mike has a ‘business’ that is of focus in the first place?

Hasty Generalization: The above statement seems to assume that people like Mike “absolutely do not care about the decentralization of Bitcoin and the consequences it has on the nodes” without presenting sufficient evidence to justify such a broad generalization.

In addition, on your graph we see that the demand for stamps is much calmer, but absolutely nothing prevents a new wave of stamps. I think we must not wait for a new wave to act.

Appeal to Fear: The above statement’s caution against waiting for a new wave to act is an attempt to persuade through fear rather than through logical conclusion.

Overall

This discussion should stay as objective as possible using data, analytics, and critical thinking, precedent, historical evidence, and or other useful insights whilst removing emotions and personal attacks.

Some additional corrections to the initial PRs content to avoid a double post.

By refusing non-P2SH multisignature transactions from the outset, […]

This is not true at all, firstly there are other types of multi-signature transactions such as P2WSH (segwit) and P2TR (taproot). The other element that is false would be stating “By refusing […] transactions from the outset”. This is not true at all since this would be a relay policy and only directs a node to how to handle a bare multisig transaction in terms of relaying and placing into it’s own mempool. Bare-multisig TXs at the block validation level would not be refused and refusing base-multisig from the UTXO set would require a softfork

RobinLinus commented at 7:56 am on August 16, 2023: none

@russeree, your response is a red herring because you’re distracting from the fact that Mike openly states that he’s “polluting the UTXO set” with “toxic waste”:

russeree commented at 8:49 am on August 16, 2023: contributor

“What if we do it in the worst way possible? What if we store it in the UTXO set?”

He is wrong about this, the worst way possible would be to use P2PK instead of P2MS since it would increase the number of outpoints per arbitrary data TX by 3x.

@russeree, your response is a red herring because you’re distracting from the fact that Mike openly states that he’s “polluting the UTXO set” with “toxic waste”:

This is actually a proper response, thanks citing sources and facts. My counter point is that it through evidence cited above regarding the type of ‘bloat’ (toxic waste) in the UTXO set. Using this line of thinking inscriptions should also be removed from isStandard becuase of the statements made at Bitcoin 2023 “The Great Ordinal Debate” “There is no value here … it’s like an objective crap” while referring to inscriptions.

“I’m ruining bitcoin”

This behavior was also demonstrated in the exact same piece reference above The Great Ordinal Debate - Bitcoin 2023 The act of proclaiming to break or tarnish Bitcoin is more a form of hubris rather than rooted in reality.

The effect of stamps bloat are minimal compared to inscriptions and ordinals in terms of the total number of items and amount data added to the UTXO set. This to me is likely because of the cost to use stamps instead of the discounted methods such as inscriptions. Stamps has largely been unused on a per block basis for nearly 10k blocks yet the UTXO set still has a historically high rate of growth. Meaning the sources of bloat are coming from other types of transactions. Do you have data to show otherwise?

A personal opinion. This is one person in all of Bitcoin. His statements may be bold and in some ways true but nonetheless there is context. Example when he discusses the ’toxic waste’ he seems to be saying it more to agitate the inscriptions crowd and almost personifying the community of people who don’t like inscriptions. As such if someone didn’t like inscriptions, yes stamps would be much worse when looked at through the lens of data storage. He also mentions pre segwit nodes in his statement, that is less than .3% of the network right now. Making something look much bigger and important than it is.

Technical Reasoning this is not the best means to solve the problem.

This PR as a measure to reduce the use of P2MS without the disabling of P2PK in the short term may cause even more bloat to the UTXO set in the short term as P2PK would likely be used as an alternative to P2MS and thus using 1 outpoint per pubkey instead of 1 outpoint per 3.

Since this is a relay rule and not an actual consensus rule. To get around this in a way would be to recompile Bitcoin Core net.h with static const unsigned int DEFAULT_MAX_PEER_CONNECTIONS = 9999; or some incredibly high number in order to broadcast your TX and give it a higher chance of hitting a miner. This would mean your node would occupy more slots centralizing node running to a degree.

RobinLinus commented at 9:07 am on August 16, 2023: none

Using P2PK costs more fees. Making the toxic waste more expensive is the objective of this PR.

However, it was stated here before that P2PK should be nonstandard too. Ideally, we would even do a softfork to cleanup all these exploitable quirks. Softforks are much harder though so it’s a good approach to simply make P2PK/P2MS nonstandard for now.

russeree commented at 9:25 am on August 16, 2023: contributor

Using P2PK costs more fees. Making the toxic waste more expensive is the objective of this PR.

It’s my belief that users committed to inflating the UTXO set via these mechanisms won’t find the overhead of using P2PK problematic when trying to embed persistent, unprunable data into the timechain. P2MS was originally selected because it offered a cost-effective method to achieve this. If P2MS becomes inefficient or difficult to relay, the next logical choice would be P2PK. This would lead to an even faster inflation of the UTXO set.

all these exploitable quirks

While definitions of what are ‘quirks’ are made with good intentions, they are not necessarily objective. Also setting precedent here for a cat and mouse game around which ‘quirks’ would likely be a fools errand.

1ma commented at 9:48 am on August 16, 2023: none

If P2MS becomes inefficient or difficult to relay, the next logical choice would be P2PK. This would lead to an even faster inflation of the UTXO set.

Then the next logical step is also making P2PK non-standard (preferably on the same release), as suggested by @Semisol in this thread.

RobinLinus commented at 9:49 am on August 16, 2023: none

won’t find the overhead of using P2PK problematic

P2PK is more costly, which reduces the toxic waste spammers can inscribe per Dollar. However, as said before, P2PK should be nonstandard too.

Retropex commented at 11:58 am on August 16, 2023: none

Using this line of thinking inscriptions should also be removed from isStandard becuase of the statements made at Bitcoin 2023 “The Great Ordinal Debate” “There is no value here … it’s like an objective crap” while referring to inscriptions.

Precisely I made the request via Bitcoin-dev and via an PR #27589 (I know the PR are not intended for that)

Unfortunately despite the fact that this is not an isolated request (almost) no developer has helped us on the subject.

petertodd commented at 2:42 pm on August 16, 2023: contributor

@luke-jr

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.

OpenTimestamps has previously used bare multisig for timestamp transactions, as it’s a bit more efficient than OP_Return. The current OpenTimestamps Server does not, as when I wrote it I was expecting bare multisig to be made non-standard. But as that didn’t happen, I should look into adding it again.

Concept NACK without another justification (eg ripping out sigop related code).

petertodd commented at 2:49 pm on August 16, 2023: contributor

@mikeinspace

We will go straight to mining pools if we have to (who LOVE to include our high fee transactions).

Relevant to this discussion and OP_Return: are there already agreements with mining pools in your community to get non-std txs mined on a regular basis? Eg do any run peerable nodes with non-std-accepting patches?

RicYashiroLee commented at 4:01 pm on August 16, 2023: none

Concept ACK - all iniciatives closing the circle on arbitrary data dumping and hash-anchoring to Bitcoin are part of an important step by step process I believe, by now that a lot of vulnerabilities have already been introduced by the BIP/PR mania, and ARE gates for massive exploits we have seen. And with more altcoiners wanting to use Bitcoin, as altcoin casinos destroy their wealth/savings, they still come invariably with their altcoining mindset into Bitcoin also. To have Bitcoin’s primary supposedly TINY SCOPE respected, and get it on track in the right path of correctly addressing its decentralization trilemma, is IMV a priority of every node operator (=client of Bitcoin=the only ones decentralizing Bitcoin and with zero conflict of interests).

russeree commented at 8:46 pm on August 16, 2023: contributor

@1ma

Then the next logical step is also making P2PK non-standard (preferably on the same release), as suggested by @Semisol in this thread.

Another vector that could be used to circumvent restrictions on p2ms or even p2pk relaying would be to use p2wsh. Using a p2wsh tx outpoint would allow users to embed up to 256 bits (32 bytes) of arbitrary data per. These outpoints would also be unprunable.

The usable data storage capabilities of p2wsh are equal to p2pk with 32 bytes per outpoint. This would increase the number of required outpoints by 3x compared to p2ms.

The existence of p2wsh in this context makes restricting p2pk relaying a moot point. Which has been discussed. The same would apply for taproot outpoints. @Retropex

Precisely I made the request via Bitcoin-dev and via an PR #27589 (I know the PR are not intended for that)

Sorry, for my lack of clarity. My intention was to show that by using this evidence against one type of use case in Bitcoin. That same logic could/would be applied to other use cases in Bitcoin. One could attack Bitcoin by being boastful and arrogant about the way that they use Bitcoin, cause community outrage as a from of gathering consensus to change Bitcoin in a way that overall makes everyone worse off on longer time horizons.

Unfortunately despite the fact that this is not an isolated request (almost) no developer has helped us on the subject.

The beauty is that you are the dev! In this PR you proposed code and an idea. Consensus is likely what you are truly after.

Retropex commented at 10:25 pm on August 16, 2023: none

@Russeree you seem obstinate in believing that I’m trying to force things, that’s not the case.

I am also not looking for the consensus that will come naturally or not depending on the relevance of the changes.

I just want to have tools to give nodes runner the choice. #27589

Unlike @petertodd who tried to remove a tool for nodes runner #28130, I want others to be implemented.

russeree commented at 10:43 pm on August 16, 2023: contributor

@Retropex

@russeree you seem obstinate in believing that I’m trying to force things, that’s not the case.

Sorry for misinterpreting your statement this is what threw me off…

Unfortunately despite the fact that this is not an isolated request (almost) no developer has helped us on the subject.

conveys a sense of bias or at least a perspective of disappointment. The term “unfortunately” connotes a negative view on the situation, implying that the outcome or response (or lack thereof) from developers is unfavorable or less than desirable.

Unlike @petertodd who tried to remove a tool for nodes runner #28130, I want others to be implemented.

His solution when compared to yours side by side are very similar since his is also a modification of the default behavior with an additional command line override including a zero length for those who do not want to relay OP_RETURN.

I just want to have tools to give nodes runner the choice.

The tools are already in Bitcoin Core, these changes are modifying preferences for the default behavior. Much like a video game has a settings screen with siders and values that change the experience.

Nothing new has been developed for created, merely debating the best position for the default sliders to be in.

RicYashiroLee commented at 0:33 am on August 17, 2023: none

@Retropex

@russeree you seem obstinate in believing that I’m trying to force things, that’s not the case.

Sorry for misinterpreting your statement this is what threw me off…

Unfortunately despite the fact that this is not an isolated request (almost) no developer has helped us on the subject.

conveys a sense of bias or at least a perspective of disappointment. The term “unfortunately” connotes a negative view on the situation, implying that the outcome or response (or lack thereof) from developers is unfavorable or less than desirable.

Unlike @petertodd who tried to remove a tool for nodes runner #28130, I want others to be implemented.

His solution when compared to yours side by side are very similar since his is also a modification of the default behavior with an additional command line override including a zero length for those who do not want to relay OP_RETURN.

I just want to have tools to give nodes runner the choice.

The tools are already in Bitcoin Core, these changes are modifying preferences for the default behavior. Much like a video game has a settings screen with siders and values that change the experience.

Nothing new has been developed for created, merely debating the best position for the default sliders to be in.

Although I agree with your last sentence, this is one more small attempt and step as I see it, of a node operator, to proactively DO SOMETHING that even if seamingly small, have an effect of tightening the circle around making hash-anchoring to Bitcoin a bit more CUMBERSOME, assuming NEW node operators will likely not be aware of what each default settings does at start. We all know that NEW node operators unfortunately are NOT popping up from everywhere every day, and only about 17.000 full nodes are currently supporting Bitcoin’s network, estimated 0.0002% of users. So for me this is by far definitely a great initiative and we need actually also the coding of more options for full node SW, so operators can to be the ones to DECIDE what really is CORE (=PRIMARY SCOPE) to Bitcoin, as Bitcoin’s decentralization is SUSTAINED by tyranically (Satoshi’s term) keeping that CORE=CENTRAL the tiniest possible. Not Devs (=service providers, in conflict of interests).

pcfreak30 commented at 3:13 am on August 17, 2023: none

This should summarize this whole debate which started from laser-eyed maxis Twitter accounts virtue signaling on Twitter and calling for miners to not mine ordinal transactions in Q1-Q2 this year.

Bitcoin for me, but not for thee. Respectfully, anyone who wants to dictate the right use of bitcoin for what I call frankly, the Church of Satoshi… needs to go and kindly… fuck off.

You are turning out to be no better than the central bankers you demonize in the process.

Innovation in BTC matters, but what we dictate as spam is no different than what the government considers dis-information or mis-information. Bitcoin is bitcoin, use it, or create your own CBDC with your morals & ethics in the code. We already have had many forks that have done so.

Sincerely,

A shitcoiner who actually respects Bitcoin for what it represents.

xiaobolei commented at 3:36 am on August 17, 2023: none

Some Bitcoin Politicians are real “SPAMS”

ChrisMartl commented at 4:59 am on August 17, 2023: none

This should summarize this whole debate which started from laser-eyed maxis Twitter accounts virtue signaling on Twitter and calling for miners to not mine ordinal transactions in Q1-Q2 this year.

Bitcoin for me, but not for thee. Respectfully, anyone who wants to dictate the right use of bitcoin for what I call frankly, the Church of Satoshi… needs to go and kindly… fuck off.

You are turning out to be no better than the central bankers you demonize in the process.

Innovation in BTC matters, but what we dictate as spam is no different than what the government considers dis-information or mis-information. Bitcoin is bitcoin, use it, or create your own CBDC with your morals & ethics in the code. We already have had many forks that have done so.

Sincerely,

A shitcoiner who actually respects Bitcoin for what it represents.

I hope, @russeree comment properly the opinion above.

owenstrevor commented at 7:15 am on August 17, 2023: none

NACK

This discussion is a waste of time that could be better spent on talking solutions that improve Bitcoin, like Utreexo.

The proposed solution does not stop these transactions, but is like locking the front door of your house when the window is wide open and anyone can jump through it. It merely gives the illusion of accomplishment. It’s theater.

Finally, these transactions will get priced out and go away if people actually use Bitcoin and the demand for blockspace reaches an actual sustainable level for the network to succeed in the long-term without a security subsidy.

ChrisMartl commented at 7:27 am on August 17, 2023: none

NACK

This discussion is a waste of time that could be better spent on talking solutions that improve Bitcoin, like Utreexo.

The proposed solution does not stop these transactions, but is like locking the front door of your house when the window is wide open and anyone can jump through it. It merely gives the illusion of accomplishment. It’s theater.

Finally, these transactions will get priced out and go away if people actually use Bitcoin and the demand for blockspace reaches an actual sustainable level for the network to succeed in the long-term without a security subsidy.

Could you please explain technically, how “Utreexo” will fix the original problem of exploiting the loose flexibility of script?

“these transactions will get priced out and go away if people actually use Bitcoin and the demand for blockspace reaches an actual sustainable level for the network to succeed in the long-term without a security subsidy.”

Please explain technically the rationale for your statement “Bitcoin Security Budget”.

RobinLinus commented at 7:42 am on August 17, 2023: none

The usable data storage capabilities of p2wsh are equal to p2pk with 32 bytes per outpoint.

You’re assuming that they would use p2pk with compressed keys. Uncompressed keys are cheaper though because they can store 64 bytes.

This would increase the number of required outpoints by 3x compared to p2ms.

The number of outpoints is irrelevant. Relevant is the per-byte cost of bloating the UTXO set.

russeree commented at 7:48 am on August 17, 2023: contributor

You’re assuming that they would use p2pk with compressed keys. Uncompressed keys are cheaper though because they can store 64 bytes.

uncompressed pubkeys dont work that way since Bitcoin Core checks to make sure the Y is valid for X. As such trying to attach arb. data to X and Y will cause that check to fail and the script won’t be considered standard. This is why stamps uses uncompressed public keys.

Validated that though stamps doesn’t use uncompressed public keys. P2MS uncompressed pubkeys are valid even if the X and Y point do not lie on the SECP256K1 curve. These outputs could be pruned safely from the UTXO set since they can not be signed for.

https://mempool.space/testnet/tx/46013539ea25c8a083c98d57dcbf6365611ed902acd91b8656a022e84ff8f0e7#flow=&vout=0

~~See my reply here. #28217 (comment)~~

Edit 1: After further digging neither p2pk or multisig checks for valid (x,y) components just a valid size. 😲 IMO this would be a much better place to start since there is no way any rational user would use an uncompressed public key with an invalid ‘Y’ component. Is there checking at a deeper level before the TX gets to the mempool that I am missing?

P2PK https://github.com/bitcoin/bitcoin/blob/60d3e4b0cd8716a6fe1be6b4d1b8237da8e56126/src/script/standard.cpp#L63-L75

P2MS https://github.com/bitcoin/bitcoin/blob/60d3e4b0cd8716a6fe1be6b4d1b8237da8e56126/src/script/standard.cpp#L112-L132

This function should do the job perfectly. https://github.com/bitcoin/bitcoin/blob/60d3e4b0cd8716a6fe1be6b4d1b8237da8e56126/src/pubkey.cpp#L297-L302

The number of outpoints is irrelevant. Relevant is the per-byte cost of bloating the UTXO set.

Not completely true, the more outpoints in the utxo set the longer the lookup time and the bigger the index gets also more disk write activity.

RobinLinus commented at 8:22 am on August 17, 2023: none

multisig checks only check for valid size and not valid (x,y) components

Yes, that’s what I had in mind.

Not completely true, the more outpoints in the utxo set the longer the lookup time and the bigger the index gets also more disk write activity.

Still, the relevant metric is the cost of “polluting the UTXO set”. If a spammer is just trying to maximize the number of UTXOs then the cheapest way is probably p2wkh.

RicYashiroLee commented at 9:28 am on August 17, 2023: none

This should summarize this whole debate which started from laser-eyed maxis Twitter accounts virtue signaling on Twitter and calling for miners to not mine ordinal transactions in Q1-Q2 this year.

Bitcoin for me, but not for thee. Respectfully, anyone who wants to dictate the right use of bitcoin for what I call frankly, the Church of Satoshi… needs to go and kindly… fuck off.

You are turning out to be no better than the central bankers you demonize in the process.

Innovation in BTC matters, but what we dictate as spam is no different than what the government considers dis-information or mis-information. Bitcoin is bitcoin, use it, or create your own CBDC with your morals & ethics in the code. We already have had many forks that have done so.

Sincerely,

A shitcoiner who actually respects Bitcoin for what it represents.

Completely confused argumentation. Bitcoin’s decentralization dependents solely on its user and voluntary supporters=node operators. They decentralize decision, and therefore not dictate. What you or Devs in obvious conflict of interests want is to exploit their full nodes and use Bitcoin for something it was clearly not made for since it’s decentralization dependents exactly of keeping its SCOPE PRIMARY AND TINY, and NOT become another CENTRALIZE DB. Node operators with their decentralized decision making, as the ONLY WITHOUT conflict of interests ARE the ones to be given option in their node operators to decide. This specific request is actually a very weak one, and just a tiny attempt to keep closing the circle to hash-anchoring (=stamping) to Bitcoin, something it CANNOT DO SIMULTANEOUSLY with STAYING DECENTRALIZED.

bitcoin locked this on Aug 17, 2023

bitcoin unlocked this on Aug 18, 2023

maflcko added the label Waiting for author on Aug 21, 2023

DrahtBot added the label CI failed on Sep 4, 2023

DrahtBot removed the label CI failed on Sep 5, 2023

DrahtBot added the label CI failed on Sep 22, 2023

DrahtBot commented at 7:39 am on September 27, 2023: contributor

Needs rebase if still relevant

maflcko removed the label Waiting for author on Oct 2, 2023

fanquake marked this as a draft on Oct 2, 2023

Retropex force-pushed on Oct 5, 2023

Retropex closed this on Oct 5, 2023

Retropex reopened this on Dec 16, 2023

Retropex force-pushed on Dec 16, 2023

DrahtBot removed the label CI failed on Dec 16, 2023

Retropex marked this as ready for review on Dec 16, 2023

Retropex commented at 5:21 pm on December 16, 2023: none

A substantial wave of P2MS txs containing false public keys are currently used for adding arbitrary data to the chain. They add significant amounts of data to the UTXOs set and thus make it expensive to execute a node without the possibility of pruning them.

theDavidCoen commented at 12:15 pm on December 18, 2023: none

Concept ACK.

These kind of parameters should default to false. Node operators should be active users and decide which feature they want to enable for their node.

In this specific case, permitbaremultisig should default to zero or nodes would add and broadcast unconventional multisig transactions by default, and include also public keys out of the Bitcoin spectrum (uncompressed keys that are not points on the secp256k1 curve), which cannot be other than spam. Node operators should be able to do so, but actively.

TheCharlatan commented at 12:25 pm on December 18, 2023: contributor

Concept ACK

ChrisMartl commented at 2:29 pm on December 18, 2023: none

Concept ACK

Database is a very important resource for the “Bitcoin”-System and its usage must be reserved exclusively for Sats endogenous monetary usage. Since the Bitcoin’s systemic flaw (https://github.com/bitcoin/bitcoin/issues/29089#issue-2043281653) is still unaddressed / unsolved, efforts to preserve the capability of already allocated storage devices resources in the network shall be considered and encouraged.

nsvrn commented at 4:02 pm on December 18, 2023: contributor

Concept ACK

a bare minimum default value change of an optional parameter makes lot of sense to increase the chances of keeping chainstate dataset clean

1440000bytes commented at 4:07 pm on December 18, 2023: none

Concept NACK

These kind of parameters should default to false. Node operators should be active users and decide which feature they want to enable for their node.

Disagree. All transactions should be relayed by default if they follow consensus rules. Only transactions affecting security of p2p network with DoS vectors should be non-standard. Users can always set it to false if they dont want to see bare multisig transactions in mempool.

Changing defaults in core to stop relaying some transactions incentivizes services like viabtc accelerator. Tried to accelerate a bare multisig tx with low fee rate from mempool for free and it was included in block 821783

Retropex commented at 4:38 pm on December 18, 2023: none

Only transactions affecting security of p2p network with DoS vectors should be non-standard.

Well, that’s precisely what happens, many TXs using a fake public key to add arbitrary data to the chain without the possibility of pruning.

They thus increase the cost of running a node, this can prevent people with the least computer resources from running a node and could, in the long term, seriously affect the decentralization of the network.

theDavidCoen commented at 4:45 pm on December 18, 2023: none

Concept NACK

These kind of parameters should default to false. Node operators should be active users and decide which feature they want to enable for their node.

Disagree. All transactions should be relayed by default if they follow consensus rules. Only transactions affecting security of p2p network with DoS vectors should be non-standard. Users can always set it to false if they dont want to see bare multisig transactions in mempool.

Changing defaults in core to stop relaying some transactions incentivizes services like viabtc accelerator. Tried to accelerate a bare multisig tx with low fee rate from mempool for free and it was included in block 821783

This is factually incorrect. Node operators constantly filter out transactions even if they follow the consensus rules as per Bitcoin Core defaults, for example, if OP_RETURN > 83 byte, if mempoolminfee and minrelaytxfee are < 0.00001000 BTC, if mempoolsize > 300 MB (and the minimum fee rises consequently).

This proposal has nothing to do with the Consensus layer. Defaulting on non-standard transactions, for example by passively broadcasting TXs with out of range uncompressed public keys, can become an issue for the decentralization of the network and should be avoided. Users that want to broadcast non-standard transactions should be allowed, if they follow the Consensus, and they stil can by setting permitbaremultisig to true.

RicYashiroLee commented at 4:50 pm on December 18, 2023: none

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

This is not Bitcoin..

Concept ACK. Censorship is clearly the favorite argument of altcoiners in Bitcoin when whichever measure makes arbitrary data more cumbersome to be added to full nodes. My reasoning for ACK: regarding full nodes, always by default ALLOW OPTIONS, AND NEVER IMPOSE POSITIVE DEFAULTS. THAT IS DICTATORSHIP DISGUISED. This is the difference between positivist doctrine law, where fiat thrives on, vs. the Non-Aggession Principle(NAP) correctly aligned with the Bitcoin principles, IMV.

1440000bytes commented at 5:59 pm on December 18, 2023: none

This is factually incorrect. Node operators constantly filter out transactions even if they follow the consensus rules as per Bitcoin Core defaults, for example, if OP_RETURN > 83 byte, if mempoolminfee and minrelaytxfee are < 0.00001000 BTC, if mempoolsize > 300 MB (and the minimum fee rises consequently).

OP_RETURN limits do not make sense. They might get removed in core or users can run binaries provided by @petertodd soon
mempoolminfee and minrelaytxfee exist to avoid DoS

uncompressed public keys, can become an issue for the decentralization of the network and should be avoided

It’s not an issue with decentralization, but the use of uncompressed keys is not considered safe.

Retropex commented at 6:27 pm on December 18, 2023: none

OP_RETURN limits do not make sense. They might get removed in core

However, it is very effective. Why will it make no sense?

Fiach-Dubh commented at 1:37 am on December 19, 2023: none

ACK

There is evidence that a majority of people do not like or want this behavior. Having it on by default for all node runners, seems contrary to what most node runners would choose as policy if they were consciously given a choice.

Reducing local RAM resource strain is also beneficial.

poll results

BitcoinMechanic commented at 2:01 am on December 26, 2023: none

Strong ACK.

It makes bloating the UTXO set trivial and this is being done with the recent “stamps” spam attack.
It’s a poor way to do multisig (and arguments for stateless multisig aren’t valid - it’s not the responsibility of users running nodes to store data only relevant to you.)

It makes sense for nodes to refuse to relay unnecessarily burdensome TXs.

desi-bitcoiner commented at 4:34 am on January 6, 2024: none

Concept ACK

DrahtBot added the label CI failed on Jan 12, 2024

DrahtBot removed the label CI failed on Jan 15, 2024

chrisguida commented at 10:36 pm on January 16, 2024: none

Concept ACK, what will it take to get this merged? Stamps are absolutely ravaging the UTXO set.

ajtowns commented at 3:53 am on January 17, 2024: contributor

Concept ACK, what will it take to get this merged? Stamps are absolutely ravaging the UTXO set.

Nobody’s given anything more than a concept ack, would be unusual to merge without some actual acks. Also the code should be rebased onto master (git rebase origin/master), at present there’s a merge commit, which would also be unusual to have merged.

luke-jr commented at 4:01 am on January 17, 2024: member

It needs a rebase, unless we’re going to be okay with merge commits now (I’m fine with it, but historically it’s been a blocker)

glozow commented at 10:50 am on January 17, 2024: member

Please rebase. See contributing guidelines https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#rebasing-changes.

Change `DEFAULT_PERMIT_BAREMULTISIG` to false 9bc554e3eb

Release note for changing `-permitbaremultisig` config default to false 8672721deb

Retropex force-pushed on Jan 17, 2024

Retropex commented at 11:02 am on January 17, 2024: none

Please rebase.

Rebased.

moonsettler commented at 11:17 am on January 17, 2024: none

Concept ACK, what will it take to get this merged? Stamps are absolutely ravaging the UTXO set.

what do we mean by ravaging? afaik the biggest unnecessary bloater of the UTXO set is the stacks protocol.

1440000bytes commented at 11:15 am on January 18, 2024: none

Concept ACK, what will it take to get this merged? Stamps are absolutely ravaging the UTXO set.

what do we mean by ravaging? afaik the biggest unnecessary bloater of the UTXO set is the stacks protocol.

Normally users only see what gets highlighted in famous explorers and discussed on twitter. I think the best way to “filter” everything is blocksonly=1 as suggested by a few other developers.

russeree commented at 11:28 am on January 18, 2024: contributor

I got to ask, as even a maintainer has brought this up. What is stopping the demand for P2MS from moving to P2PK? IMO this solution is ineffective due to a lack of comprehensiveness.

insert meme of gate with no fence

1440000bytes commented at 11:54 am on January 18, 2024: none

What is stopping the demand for P2MS from moving to P2PK?

Or P2WSH

russeree commented at 1:24 pm on January 18, 2024: contributor

What is stopping the demand for P2MS from moving to P2PK?

Or P2WSH

Or just just the script pubkey in general. I did a small test on testnet where I put a dickbutt.jpg into the hashes of a witness program.

https://mempool.space/testnet/tx/9382f1504e8381a09773a7eeb9fd2e52c454cdd7263db155f0417a97f7d77c52

Sun0fABeach commented at 2:21 pm on January 18, 2024: none

Of course there is always some other way of putting garbage on the chain, but looking at this problem through an exclusively technical lense will inevitably lead to nihilism. Closing this particular vector sends a message about what type of activity is welcome, which influences the social layer, which in turn influences how much VC money gets pumped into these projects, exacerbating the problem.

eragmus commented at 3:58 pm on January 18, 2024: none

Concept NACK.

Bitcoin moves value* through time + space.

*Value is subjective. (Value, in Bitcoin, is subjectively determined by the fee-rate of the tx.)

Bitcoin is a cypherpunk system. Bitcoin is based on crypto-anarchy. This is a colorful way of saying that Bitcoin is about freedom, including free markets.

Bitcoin’s anti-DoS mechanism is not about Bitcoin Core sending political messages to dictate to the economy what it should or should not do.

Bitcoin’s anti-DoS mechanism is based on fee-rate of txs.

Therefore, there should be no prejudice on the mempool layer, as far as which kind of value is “good” or “bad”, due to Bitcoin’s primary ethos being dedicated to freedom, permissionlessness, and censorship-resistance.

In the case of arbitrary data txs, this is even more critical due to financial incentive. In 2023, the free market already voted in favor of arbitrary data txs, with a total of 8,500 BTC paid in fees by arbitrary data buyers of block space to sellers of block space, which was more than 1/3 of total fees.

Thus, any attempt to interfere carries obvious and severe risks and unintended consequences, for both Bitcoin Core and Bitcoin:

It sends a message that Bitcoin Core is being political, by trying to interfere in free market activity on the network by censoring valid fee-paying txs. It also would not dissuade activity, rather it would invigorate the arbitrary data economy due to being able to credibly claim censorship attempt. Permissionlessness quality means Bitcoin users do not require permission, not from Bitcoin Core nor from any other. Bitcoin operates on financial incentives of free markets. We have already seen in 2023 that the arbitrary data economy was only motivated by attempts to restrict their activity. It created a counter-culture that seemed “cool”, in a rebellious “stick it to the man” sense.
The update to Bitcoin Core is very likely ineffective, just virtue signaling (which Bitcoin Core should not be in the business of doing, as it makes a mockery of Bitcoin Core to implement changes that lack efficacy), since to change the public mempool relay situation, you would need iirc 85-92% of nodes to update. This is very low probability, as a significant minority or more of nodes simply refuse to update, and others wait years before updating. Also, users of arbitrary data obviously have an incentive to respond by running nodes without the change.
Even if (2) is resolved in a low probability scenario, the arbitrary data economy can simply and quickly stop using the public mempool relay, and switch to miners’ private mempool relay, by sending txs directly to miners. (Remember, there is a very strong financial incentive to route around any attempted censorship by Bitcoin Core.) This splits the mempool into 2 pieces: public and decentralized vs. private and centralized. Even if miners made their own mempool public at some point, it would need to be trusted, cannot verify, which incentivizes miners to lie about the real state of the mempool to increase fees paid. Nothing about this is good. It can cause pressure to centralize mining.
As explained by others in recent comments, the arbitrary data can be easily switched to any number of different formats, with format chosen based on intended effect. STAMPS have the intended effect of being unable to be removed, so you can expect those particular txs to adapt accordingly, if they need to. It has various unintended consequences – It would make already-created STAMPS more valuable, as it makes their supply finite. It can cause new designs to be more disruptive, not less. It creates an inevitable cat and mouse game, where Bitcoin Core must waste its precious time and energy and other resources on a pointless virtue-signaling exercise, and in fact vice-signaling by trying to censor fee-paying txs.
As @petertodd mentioned, this activity represents a minuscule less than 1% of the UTXO set, yet trying to stop it creates technical risk, as always exists with any change to Bitcoin, and for that reason alone is unwise and not justified.
Various fear-mongering claims about the UTXO set are thrown around to artificially magnify the problem with scary words like “bloat the UTXO set” and “increase RAM usage”, but these claims are false or misleading. – As @achow101 said: “With current usage, even with the bare multisig protocols, I don’t think the effect on full nodes is particularly egregious. The UTXOs created for the arbitrary data are still small and bounded. I did a calculation a little while ago which suggested that the UTXO set growth due to bare multisigs is around a few MB. Compared to the rest of the UTXO set and the blockchain, that’s nothing. All that means is that the storage required goes up by that amount. It doesn’t have any effect on [RAM] memory usage, since there’s a fixed amount of cache. If the UTXOs are never spent, then they won’t be taking up any memory. – @murchandamus has said: “We load into the UTXO cache any UTXO that get referenced by transactions, and new UTXOs that get created. We flush the UTXO cache whenever it hits the limit, so UTXOs that haven’t been used in a long time are likely not in the RAM.” and “By default, Bitcoin Core limits the mempool datastructure to 300 MiB of memory (RAM).” and “When this limit is hit, nodes start to discard the transactions with the lowest “descendant set feerate”, i.e. the sum of fees divided by the sum of sizes of the transactions and its descendant transactions, until they are below the limit.” – @evoskuil has said: “The only necessary difference is prunability, as both must be retained for bootstrapping. Yet widespread pruning also isn’t good for bootstrapping, so really not an important distinction. Disk space is the cheapest computing resource. There is no good reason to be concerned about linear chain growth.”
Bitcoin’s governance is not a democracy. It is not about who can vote more in favor vs. against, on Github. It is about achieving rough consensus, where the primary objective is the precautionary principle of “do no harm” (Bitcoin is a conservatively operated network, not “move fast and break things”), and thus where objections have to be properly addressed. If lack of consensus, then no change.
Bitcoin Core developers do not control Bitcoin. Users, businesses, miners, etc. choose which node implementation to run. If someone does not like Bitcoin Core, Bitcoin Core has no obligation to disregard its principles of (7), bow to pressure, and make changes. Bitcoin Core follows its principles and provides software to the market. It is a free market actor. The rest of the free market’s actors then choose whether to accept that software, or fork it to create their own software to run.
Uneconomic lower fee-rate txs that are priced out (by economically-viable higher fee-rate txs) are not entitled to be able to be made on L1 Bitcoin with its highest censorship-resistant assurances. L2 networks like LN exist to be able to handle txs with lower economic value (txs with lower fee-rate), by allowing to amortize the cost of the L1 fee across many L2 txs. Really low economic value txs like coffee payments arguably do not need L1’s censorship resistance, and if for example they are not viable with L2 either due to fees, then arguably can use different layers: semi-decentralized federated networks like Liquid, or Fedimint, etc. Or, even non-decentralized custodial LN.
The other realistic solution besides (9) is to focus on improving Bitcoin’s L1 and L2 efficiency via consensus changes like CTV, for UTXO sharing to increase fee density and thus economic value of lower-value txs (to be better able to compete with higher-value economic txs), and to use CTV to be able to improve L2s like LN and Ark and Enigma.
One possible way to deal with arbitrary data txs, at its root, is to break Ordinal Theory, iiuc. This requires a fork, such as if Bitcoin implements Confidential Transactions. This too will need consensus, but it at least offers something valuable to many, in exchange for the lost fees: privacy (by default?) on L1 Bitcoin.

I realize the truth is often unpopular, and truth is a bitter pill to swallow sometimes when it conflicts with one’s ego, but nothing (not even ego) is more important than truth and reality.

1ma commented at 10:16 pm on January 18, 2024: none

tACK https://github.com/bitcoin/bitcoin/pull/28217/commits/8672721deb06e66854a085c9994e99c99160b8a1

1440000bytes commented at 11:33 pm on January 18, 2024: none

tACK

You can add the commit that you tested after tACK: https://github.com/bitcoin/bitcoin/pull/28217/commits/8672721deb06e66854a085c9994e99c99160b8a1

Or more details what exactly was tested and reasons to agree with pull request.

DrahtBot requested review from luke-jr on Jan 18, 2024

DrahtBot requested review from achow101 on Jan 18, 2024

DrahtBot requested review from TheCharlatan on Jan 18, 2024

1ma commented at 8:33 am on January 19, 2024: none

tACK

You can add the commit that you tested after tACK: 8672721

Or more details what exactly was tested and reasons to agree with pull request.

I already gave my reasons back in August, top of the thread. This isn’t Twitter, if you want to participate here make an effort to read everything through and through.

As for what was tested, obviously the full PR. I built @Retropex’s branch on my machine and swapped the bitcoind binary in one of my mainnet nodes. After the restart, a few unconfirmed bare multisig transactions that I had previously identified in my mempool using mempool.space’s new X-Ray feature went missing. Trying to force-feed these unconfirmed transactions again into the node with the sendrawtransaction command didn’t work either, until I added permitbaremultisig=1 in my bitcoin.conf and restarted the node again.

So tested ACK.

RicYashiroLee commented at 10:30 am on January 19, 2024: none

Concept NACK.

Bitcoin moves value* through time + space.

*Value is subjective. (Value, in Bitcoin, is subjectively determined by the fee-rate of the tx.)

Bitcoin is a cypherpunk system. Bitcoin is based on crypto-anarchy. This is a colorful way of saying that Bitcoin is about freedom, including free markets.

Bitcoin’s anti-DoS mechanism is not about Bitcoin Core sending political messages to dictate to the economy what it should or should not do.

Bitcoin’s anti-DoS mechanism is based on fee-rate of txs.

Therefore, there should be no prejudice on the mempool layer, as far as which kind of value is “good” or “bad”, due to Bitcoin’s primary ethos being dedicated to freedom, permissionlessness, and censorship-resistance.

In the case of arbitrary data txs, this is even more critical due to financial incentive. In 2023, the free market already voted in favor of arbitrary data txs, with a total of 8,500 BTC paid in fees by arbitrary data buyers of block space to sellers of block space, which was more than 1/3 of total fees.

Thus, any attempt to interfere carries obvious and severe risks and unintended consequences, for both Bitcoin Core and Bitcoin:

It sends a message that Bitcoin Core is being political, by trying to interfere in free market activity on the network by censoring valid fee-paying txs. It also would not dissuade activity, rather it would invigorate the arbitrary data economy due to being able to credibly claim censorship attempt. Permissionlessness quality means Bitcoin users do not require permission, not from Bitcoin Core nor from any other. Bitcoin operates on financial incentives of free markets. We have already seen in 2023 that the arbitrary data economy was only motivated by attempts to restrict their activity. It created a counter-culture that seemed “cool”, in a rebellious “stick it to the man” sense.

The update to Bitcoin Core is very likely ineffective, just virtue signaling (which Bitcoin Core should not be in the business of doing, as it makes a mockery of Bitcoin Core to implement changes that lack efficacy), since to change the public mempool relay situation, you would need iirc 85-92% of nodes to update. This is very low probability, as a significant minority or more of nodes simply refuse to update, and others wait years before updating. Also, users of arbitrary data obviously have an incentive to respond by running nodes without the change.

Even if (2) is resolved in a low probability scenario, the arbitrary data economy can simply and quickly stop using the public mempool relay, and switch to miners’ private mempool relay, by sending txs directly to miners. (Remember, there is a very strong financial incentive to route around any attempted censorship by Bitcoin Core.) This splits the mempool into 2 pieces: public and decentralized vs. private and centralized. Even if miners made their own mempool public at some point, it would need to be trusted, cannot verify, which incentivizes miners to lie about the real state of the mempool to increase fees paid. Nothing about this is good. It can cause pressure to centralize mining.

As explained by others in recent comments, the arbitrary data can be easily switched to any number of different formats, with format chosen based on intended effect. STAMPS have the intended effect of being unable to be removed, so you can expect those particular txs to adapt accordingly, if they need to. It has various unintended consequences – It would make already-created STAMPS more valuable, as it makes their supply finite. It can cause new designs to be more disruptive, not less. It creates an inevitable cat and mouse game, where Bitcoin Core must waste its precious time and energy and other resources on a pointless virtue-signaling exercise, and in fact vice-signaling by trying to censor fee-paying txs.

As @petertodd mentioned, this activity represents a minuscule less than 1% of the UTXO set, yet trying to stop it creates technical risk, as always exists with any change to Bitcoin, and for that reason alone is unwise and not justified.

Various fear-mongering claims about the UTXO set are thrown around to artificially magnify the problem with scary words like “bloat the UTXO set” and “increase RAM usage”, but these claims are false or misleading. – As @achow101 said: “With current usage, even with the bare multisig protocols, I don’t think the effect on full nodes is particularly egregious. The UTXOs created for the arbitrary data are still small and bounded. I did a calculation a little while ago which suggested that the UTXO set growth due to bare multisigs is around a few MB. Compared to the rest of the UTXO set and the blockchain, that’s nothing. All that means is that the storage required goes up by that amount. It doesn’t have any effect on [RAM] memory usage, since there’s a fixed amount of cache. If the UTXOs are never spent, then they won’t be taking up any memory. – @murchandamus has said: “We load into the UTXO cache any UTXO that get referenced by transactions, and new UTXOs that get created. We flush the UTXO cache whenever it hits the limit, so UTXOs that haven’t been used in a long time are likely not in the RAM.” and “By default, Bitcoin Core limits the mempool datastructure to 300 MiB of memory (RAM).” and “When this limit is hit, nodes start to discard the transactions with the lowest “descendant set feerate”, i.e. the sum of fees divided by the sum of sizes of the transactions and its descendant transactions, until they are below the limit.” – @evoskuil has said: “The only necessary difference is prunability, as both must be retained for bootstrapping. Yet widespread pruning also isn’t good for bootstrapping, so really not an important distinction. Disk space is the cheapest computing resource. There is no good reason to be concerned about linear chain growth.”

Bitcoin’s governance is not a democracy. It is not about who can vote more in favor vs. against, on Github. It is about achieving rough consensus, where the primary objective is the precautionary principle of “do no harm” (Bitcoin is a conservatively operated network, not “move fast and break things”), and thus where objections have to be properly addressed. If lack of consensus, then no change.

Bitcoin Core developers do not control Bitcoin. Users, businesses, miners, etc. choose which node implementation to run. If someone does not like Bitcoin Core, Bitcoin Core has no obligation to disregard its principles of (7), bow to pressure, and make changes. Bitcoin Core follows its principles and provides software to the market. It is a free market actor. The rest of the free market’s actors then choose whether to accept that software, or fork it to create their own software to run.

Uneconomic lower fee-rate txs that are priced out (by economically-viable higher fee-rate txs) are not entitled to be able to be made on L1 Bitcoin with its highest censorship-resistant assurances. L2 networks like LN exist to be able to handle txs with lower economic value (txs with lower fee-rate), by allowing to amortize the cost of the L1 fee across many L2 txs. Really low economic value txs like coffee payments arguably do not need L1’s censorship resistance, and if for example they are not viable with L2 either due to fees, then arguably can use different layers: semi-decentralized federated networks like Liquid, or Fedimint, etc. Or, even non-decentralized custodial LN.

The other realistic solution besides (9) is to focus on improving Bitcoin’s L1 and L2 efficiency via consensus changes like CTV, for UTXO sharing to increase fee density and thus economic value of lower-value txs (to be better able to compete with higher-value economic txs), and to use CTV to be able to improve L2s like LN and Ark and Enigma.

One possible way to deal with arbitrary data txs, at its root, is to break Ordinal Theory, iiuc. This requires a fork, such as if Bitcoin implements Confidential Transactions. This too will need consensus, but it at least offers something valuable to many, in exchange for the lost fees: privacy (by default?) on L1 Bitcoin.

I realize the truth is often unpopular, and truth is a bitter pill to swallow sometimes when it conflicts with one’s ego, but nothing (not even ego) is more important than truth and reality.

I think this view shows a twisted absolute ignorance of what Bitcoin is about. Different from “crypto”, Bitcoin is not an “all purpose DB” neither a ‘world computer’. Its scope must be instead, contrary to all the 10000 altcoining misconceptions, and be kept tyranically (Satoshi’s used term on this) TINY. Fees in Bitcoin are one of the measures against arbitrary data dumping, and Satoshi mentioned ‘OTHER THINGS’ that he could do to actually FIGHT it, NOT by any means EVER accept such misuse out-of-scope passively, which ultimately destroys his true invention, which is NOT a “crypto” shi*coin “project”.

So again, concept ACK.

1440000bytes commented at 12:54 pm on January 19, 2024: none

This isn’t Twitter, if you want to participate here make an effort to read everything through and through.

Exactly, this isn’t twitter so a detailed explanation with the ACK helps everyone and adds more weight to your comment.

eragmus commented at 10:54 pm on January 19, 2024: none

I think this view shows a twisted absolute ignorance of what Bitcoin is about. Different from “crypto”, Bitcoin is not an “all purpose DB” neither a ‘world computer’. Its scope must be instead, contrary to all the 10000 altcoining misconceptions, and be kept tyranically (Satoshi’s used term on this) TINY. Fees in Bitcoin are one of the measures against arbitrary data dumping, and Satoshi mentioned ‘OTHER THINGS’ that he could do to actually FIGHT it, NOT by any means EVER accept such misuse out-of-scope passively, which ultimately destroys his true invention, which is NOT a “crypto” shi*coin “project”.

You’re certainly entitled to your opinion about “what is bitcoin”. But, personally speaking, I’m not interested in having a religious conversation, where Satoshi is treated as God & his words from the white paper and forums are being quoted like scripture. I had enough of that last time around, during the block size civil war, with the bcashers. They behaved in a similar fashion, and were unable to deal with reality (instead dealt in ideology, based on cherry-picking what Satoshi said during how things worked in his time when ASICs were not really a thing and so on), and as a result became extremely radicalized and ended up forking off. Both then and now, I’m only interested in logic and reason, based on the reality of how bitcoin and bitcoin core works, bitcoin’s incentive system, and so on, which is what I tried to provide in my fairly comprehensive rebuttal to this topic.

RobinLinus commented at 3:08 am on January 20, 2024: none

to dictate to the economy what it should or should not do @eragmus your post reads as if you have missed that the spammer himself publicly states that they’re running a spam attack. Of course, one can question the effectiveness of the spam mitigation proposed in this PR, but it’s pretty absurd trying to argue that this spam would not be an attack even though the attacker is bragging about his attack in interviews.

eragmus commented at 4:37 am on January 21, 2024: none

to dictate to the economy what it should or should not do

@eragmus your post reads as if you have missed that the spammer himself publicly states that they’re running a spam attack. Of course, one can question the effectiveness of the spam mitigation proposed in this PR, but it’s pretty absurd trying to argue that this spam would not be an attack even though the attacker is bragging about his attack in interviews. @RobinLinus Hi Robin, first of all, I really admire your work on Bitcoin, and creativity and apparent intelligence and original and independent thinking.

As far as bitcoin and its incentives are concerned, which the consensus code is based on, I think it’s really important to emphasize that “spam” is best defined as something like: “any uneconomic tx that pays a fee-rate low enough that it does not get confirmed by miners”. “Spam” cannot be arbitrarily defined, it needs a neutral definition to reflect that Bitcoin is a neutral system that doesn’t moralize “good” and “bad” txs. If “spam” is arbitrarily defined to include certain tx types, yet there is economic incentive for miners to confirm those txs, then it creates an incentive to directly send those txs to the miners, and can weaken/break mempool fee estimation and further centralize mining (I talked about this in my longer post).

re: justifying it as an attack based on what @mikeinspace said in the interview, did you listen to the rest of the interview? I did know of the part that you highlighted, but upon your bringing it to my attention again, I listened to the entire 40 minutes. Twice! Taken in context, my analysis is @mikeinspace was trolling or shitposting or something like that, and that those words should not be taken literally. Totally stupid for him to say what he said though, since I’ve talked to him over the years sometimes, and I never thought he actually wants to attack bitcoin, nor that he doesn’t care about bitcoin. I think he cares, yet his words here were horribly chosen & just begging for people to misunderstand his intentions. Maybe he said it for free marketing (“no publicity is bad publicity” taken to the extreme)? I have no idea.

Some context –

Right before your quoted part:

“With ordinals, they did it in a very responsible way. They put it in this witness data, so that no one would get upset about it. And what happened? Well everyone got upset about it, and they want to get rid of the inscriptions because it’s terrible, and Luke is already putting together a filter, and they’re going to discard all this stuff.”

Right after your quoted part:

“So basically, the whole point of STAMPS is they’re immutable, they’re unprunable. If you want to do it the responsible way, you can do it the ordinals way, and Luke is going to wipe them all out, but STAMPS is going to be there forever.”

At 20:00 or so:

“During the block size war, Adam Back had a tweet where he was like ‘Someday we’ll be paying $100 bitcoin fees and that’s a great thing’. Okay, so now we’re creating this fee market for you, and everyone’s upset. ‘I can’t get my tx through at 1 sat/vb’, it’s like what do you want here? Do you want this to grow? Do you want it to just you know go down the drain? We are bringing use cases to bitcoin, we are paying the fees. The fact that anyone has a problem with that is unfathomable to me. It’s like, I don’t get it. This is good for you. We’re saving you. We’re creating this fee market that you thought was going to happen just on its own. No, you have to create use cases for it to happen. It’s not going to happen on its own.”

At 22:00 or so:

“The way I look at it is that even if you hate the use case, it’s drawing dev mindshare to bitcoin, and they’re building things, and other things will get built that are unrelated to STAMPS. But you’re drawing developers, and how can that be a bad thing?”

And he says at some point that in exchange for unprunability, the downside of STAMPS is they are much more expensive, so assumed it was only going to be a niche market limited to CounterParty users (@mikeinspace has history with CounterParty, and uses some CounterParty infrastructure to make STAMPS work, instead of relying on Ordinal Theory, as I understand it), so its growth beyond that was a surprise to him. And that he asked others what they thought about the idea of STAMPS, and they said it was stupid, but he still thought it made some sense so he did it.

BitcoinMechanic commented at 6:08 am on January 21, 2024: none

@eragmus MikeInSpace pontificating in a podcast to the tune of “hey, I helped with the fee market/security budget thing” is not a serious contribution to this discussion.

Visions for future revenue for miners never required invoking a broadening of use cases for bitcoin’s blockchain to become a more generic medium for data storage. Such usage of bitcoin has never been considered anything other than harmful and conversations that lead to OP_RETURN (a mechanism to at least mitigate some of the harm done by arbitrary data storage) were never sidetracked by people insisting otherwise.

Further, prevention of UTXO bloat has been the justification for uncontroversial decisions in the past such as heavily discounting witness data and there is no room for discussion as to whether or not bloating the UTXO set is harmful or not. By consensus, it is.

RobinLinus commented at 7:28 am on January 21, 2024: none

“spam” is arbitrarily defined

Right, the attacker says he is _“polluting the UTXO set [with] toxic waste”_.

The term toxic waste emphasizes that the problem isn’t just temporary but permanent. Important distinction.

eragmus commented at 8:33 am on January 21, 2024: none

MikeInSpace pontificating in a podcast to the tune of “hey, I helped with the fee market/security budget thing” is not a serious contribution to this discussion. @BitcoinMechanic Hello. There was more context than that. If the argument is to justify a change because this guy admitted to attacking bitcoin, yet that is based on a few cherry-picked horrendous lines out of a 40 minute podcast, that seems pretty silly. The goal should be to understand what he actually thinks.

Visions for future revenue for miners never required invoking a broadening of use cases for bitcoin’s blockchain to become a more generic medium for data storage. Such usage of bitcoin has never been considered anything other than harmful and conversations that lead to OP_RETURN (a mechanism to at least mitigate some of the harm done by arbitrary data storage) were never sidetracked by people insisting otherwise.

I got it, but that was 10-12ish years ago, in 2012-2014 or so. Times change. Gmax posted in 2017 that he was very happy that market activity produced fees > subsidy and explained his reasoning, yet in the 6+ years since then, fees have been pitiful and only spiked during short periods of bull markets… until 2023, when a new use case of gambling suddenly gained critical mass out of the blue. I know it’s not an ideal way to get fees, but “beggars can’t be choosers”, right? Normal monetary use hasn’t been able to do it.

Whoever disagrees with me on security (and I’ve talked to a lot of people) somehow just handwaves away the problem, assuming that any potential future security incident will surely only happen after mass monetary adoption whereby fees * price will be sufficiently high. Are we supposed to pretend that gmax was wrong and didn’t know what he was talking about re: fees’ importance even in 2017?

Or is it about sticking to the assumptions made 10-12 years ago, even if it means potentially having sufficient security in x years, yet a security incident in x-1 years? Are we all OK with bitcoin’s hard money narrative being seriously damaged, with confidence hurt, and people’s life savings in bitcoin being jeopardized? I’d imagine not.

Further, prevention of UTXO bloat has been the justification for uncontroversial decisions in the past such as heavily discounting witness data and there is no room for discussion as to whether or not bloating the UTXO set is harmful or not. By consensus, it is.

Agree that consensus currently agrees on this, via the witness discount. It doesn’t change the logic of what I pointed out in my quotes of various Bitcoin Core devs re: UTXO bloat. People make various UTXO bloat claims that are unsupported, so that was aimed at clarifying, primarily the RAM point that is often cited.

But yes, I do sympathize much more with this change, than with the other thread’s datacarrier change.

I raised various other points in my post here though, one of the main ones being a concern that others raised in this thread before me too: mempool split as a result of this change, if the economic incentive for tokens impacted by this change is sufficiently high for txs to be routed directly to miners.

crediblebytes commented at 2:16 pm on January 21, 2024: none

With all due respect the “rough consensus” thing is shifting from representing the users of bitcoin to who has the most marketing dollars. In software development this means you are no longer building the “right product”. The main use case is and always will be sound money. Not “freedom”, “cypherpunk system”, “database”, or a “marketplace”. This isn’t your latest tech stack to build on. No go to AWS for that. Bitcoin is hard money first. In a world of fiat, that use case alone has the biggest demand over anything else. It is the entire reason it was created as . No amount of bells and whistles can compensate for it. If anything is stopping people from moving money it is by definition a denial of service. Very clear here. And yes @eragmus reputation matters when building trust.

bitcoin locked this on Jan 21, 2024

achow101 commented at 5:06 pm on January 21, 2024: member

Keep discussion here civil or take your discussion somewhere else. Locking this as too heated for now.

bitcoin unlocked this on Jan 22, 2024

chrisguida commented at 7:12 pm on January 24, 2024: none

tACK 8672721deb06e66854a085c9994e99c99160b8a1

Steps to test:

Build and install master, sync to tip (for this test I used 207220ce8b767d8efdb5abf042ecf23d846ded73)
Go to mempool.space, click on the block to be confirmed next (get the block before that if you want a bit more time for the testing before it gets confirmed); hover over the block animation and click the goggles icon in the top left of the animation.
Select “Bare multisig” and then click any of the highlighted transactions
Scroll to the bottom of the transaction page and click on the link next to “Transaction hex”
Select the whole thing and run bitcoin-cli sendrawtransaction <paste tx hex> You should see the txid (I used https://mempool.space/tx/cb4dbd4cd5b0760a557739d5f6957efc77da20832c18e612c8f007bdd932d305). This means the tx has been accepted into your node’s mempool and is being relayed (of course, it’s probably already in your node’s mempool, but bitcoind doesn’t complain).
Rebuild the current PR’s branch (commit 8672721deb06e66854a085c9994e99c99160b8a1), install, and run.
Run the same command as before (bitcoin-cli sendrawtransaction <paste tx hex>). This time, the transaction is not accepted into your node’s mempool, and this error message appears instead:

0error code: -26
1error message:
2bare-multisig

I’d say this confirms that this PR works as designed!

chrisguida commented at 7:27 pm on January 24, 2024: none

Concept ACK, what will it take to get this merged? Stamps are absolutely ravaging the UTXO set.

what do we mean by ravaging? @moonsettler low-resource devices tend to struggle with IBD once the utxoset no longer fits in memory. My own experience with this comes from helping users sync Raspberry Pi 4 devices for a couple of years while working at Start9. (The Raspberry Pi is especially bad because the bridge connecting external USB disks to the CPU doesn’t work very well.) Once you hit your max dbcache, the utxoset starts being stored on disk, and IBD slows to a crawl. I started actively discouraging users from trying the 4GB Pi about a year ago because it now takes over a month to do IBD on those devices, whereas IBD took only a few days when the utxoset fit entirely in memory. As for the 8GB Pi, I haven’t tested it recently, but I’m guessing that since the utxoset has doubled in size over the last year, these devices too will soon start to become unviable.

The ballooning utxoset is a clear and present danger to bitcoin, as it is actively making it so that large numbers of low-resource computers can no longer sync the chain in a reasonable amount of time, which hurts decentralization in the long run.

afaik the biggest unnecessary bloater of the UTXO set is the stacks protocol.

Can you elaborate on this? If there are other protocols that are bloating the UTXO set that are even worse, I think it’s worth our time to look into seeing if such abuse can be mitigated. I’m currently unaware of how the stacks protocol is contributing to the problem.

1440000bytes commented at 10:05 pm on January 24, 2024: none

but I’m guessing that since the utxoset has doubled in size over the last year, these devices too will soon start to become unviable.

UTXO set has not doubled because of bare multisig: #28217 (comment)

Retropex commented at 10:07 pm on January 24, 2024: none

UTXO set has not doubled because of bare multisig

we 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.

chrisguida commented at 10:24 pm on January 24, 2024: none

but I’m guessing that since the utxoset has doubled in size over the last year, these devices too will soon start to become unviable.

UTXO set has not doubled because of bare multisig: #28217 (comment)

Yes, I know. Just because there isn’t a perfect solution for all utxoset abuse doesn’t mean we shouldn’t merge this and close this obvious spam vector. Incremental progress is better than no progress :muscle:

TheCharlatan approved

TheCharlatan commented at 10:30 pm on January 24, 2024: contributor

ACK 8672721deb06e66854a085c9994e99c99160b8a1

Close to the only current usage of P2MS is data embedding and meta protocols, of which the majority is through the Counterparty protocol. I am not familiar with the Counterparty protocol, so I might have gotten some points here wrong. The Bitcoin Stamps, which are mentioned throughout this pull request discussion, are built with Counterparty transactions. P2MS is one of three methods used by Counterparty to embed data. The other two documented and to an extent implemented methods are through OP_RETURN and P2SH transaction outputs. More recently there is also a proposal to enable data storage through P2WSH outputs. It seems likely that if p2ms transactions become difficult to broadcast, Counterparty would move to these wrapped data embedding methods with P2SH, or P2WSH.

From the P2MS Inputs and Outputs statistics on transactionfee.info, it is apparent that hardly any of the P2MS outputs are ever consumed, even though the Counterparty protocol was designed in a way to allow this by using 1-of-N multisig. The 1-of-N multisig technique was also mentioned as a mitigating factor by llanwj in the original 2014 PR #5231 (comment). It is now clear that this not an effective mechanism for cleaning up these data-laden outputs.

I was unable to detect paynym version 3 usage, though it is hard by design to form a good heuristic for them. I am not sure if there is a widely used implementation of it though. The #28217 (comment) Sparrow and Blue Wallet don’t seem to be using version 3 (if they are, maybe someone could link the code?).

Next to the data provided by transactionfee.info, I also checked for what I think “monetary” p2ms usage is. Again these are imperfect heuristics and I might have missed or wrongly classified some transactions. The heuristics I used disregard Counterparty outputs, as well as three other output patterns that seem to convey data and that I only found a couple of outputs each (outputs with consistent 1000 satoshi dust amounts, outputs alongside OP_RETURN outputs in the same transaction and dust amount outputs mixing compressed and uncompressed public keys). This seems to be the only “monetary” bare multisig transaction since block 800000: 01bb94bef0ee1f352531a367523f5ed318399f58e32cebf7ef57bae3946772a8. With this kind of volume support requests for migrating wallet setups and scripts to supported forms of multisig seem unlikely.

I also agree with achow101’s #28217 (comment) that the same could be done for P2PK outputs.

DoctorBuzz1 commented at 10:31 pm on January 24, 2024: none

UTXO set has not doubled because of bare multisig: #28217 (comment)

UTXO set has rapidly increased over the past year. It started with Inscriptions but is now primarily due to BRC-20 tokens. A static dust limit of 3 sat /vByte fees makes zero sense anymore, when those fees have only been seen like for a hot second since the spam started a year ago… https://statoshi.info/d/000000009/unspent-transaction-output-set?orgId=1&refresh=10m&from=now-1y&to=now&viewPanel=8

Variable dust limits are the way. (if Tx < TxFee) {isDust = True;}

MULTIPLE filters are necessary. Let’s all be honest about this. We CAN identify the many problems, and we CAN create the many solutions to these problems. The variable dust rate solution can even be modified to add parent & child Txs & TxFees together, I’m sure. LN’s peg to static dust rates should not be a Core problem… and should not be used as a basis for not solving Core’s own problems.

P.S. - This might seem “off-topic”, but then that view would admit that this PR is not “just a database where anything goes”. Anyone see where I’m going with this?

isDust

nsvrn commented at 10:48 pm on January 24, 2024: contributor

ACK 8672721deb06e66854a085c9994e99c99160b8a1

Tested locally, all unit and functional tests pass.

Transaction tested on mainnet using txid: 883b35fbd5a8b703574752b879a027ef81ae091b0bc61527309b0cf53760854f (which worked fine without this change and confirmed using getmempoolentry and getrawtransaction after doing sendrawtransaction while it was still in the mempool). Output of sendrawtransaction after compiling and running this PR:

0error code: -26
1error message:
2bare-multisig

Also I opened an issue for disallowing P2PK(bare pubkey) relays here: #29285 I would be happy to review and test the PR for that once someone is able to submit.

1440000bytes commented at 10:49 pm on January 24, 2024: none

Since DrahtBot has incorrectly assumed one of my previous comment as A-C-K, this comment is to correct it:

NACK

Reason: #28217 (comment)

Apart from the reason shared in linked comment, other reasons why this pull request makes no sense:

Some nodes will keep using older versions of core and this is enough to relay bare multisig txs for years.
Mining pools will accept such transaction out of band.
Full RBF is relayed to mining pools even if its disabled in core by default. Some nodes peering with each other similarly could always be used for propogation.
Stamps can move to other output types and continue to create dust outputs.

chrisguida commented at 1:37 am on January 25, 2024: none

@DoctorBuzz1 you should make an issue/PR formally proposing your idea, I would be happy to test and review. This PR discussion is probably not the best place. @ns-xvrn I’m also happy to help review and test any PR for #29285 @1440000bytes as was stated earlier, incremental progress is better than no progress. It sounds like you would only be happy with a perfect solution, which of course is impossible.

petertodd commented at 0:35 am on January 26, 2024: contributor

Relevant to this discussion: I’ve started a Bitcoin Libre Relay fork, that among other things does the following:

Peers with other Bitcoin Libre Relay nodes via a service bit (similar to my full-RBF peering fork).
Remove’s Bitcoin Core’s OP_Return limits.

The peering code is already sufficiently successful that multiple people have been able to get non-standard OP_Return outputs mined without interacting with miners directly. For example 6f660e9f1bbfcc8435593eb8ff70a501275ad6cdbaa536747bd9d55bdbeda65a was mined by F2Pool, which has manually removed Bitcoin Core’s op-return limits (F2Pool has also removed the limitation of one op-return per tx).

If Bitcoin Core merges this pull-req, I will be reverting it in future versions of Libre Relay. I’m sure that miners will continue to mine these transactions, and Libre Relay will make it easy to get them mined.

bitcoin deleted a comment on Jan 26, 2024

eragmus commented at 6:37 am on January 26, 2024: none

Relevant to this discussion: I’ve started a Bitcoin Libre Relay fork, that among other things does the following: @petertodd Thank you so much, Peter.

Some of us have made a series of (aligned with first principles reasoning, logic, bitcoin incentives and game theory) arguments, re: why this PR and other PRs of this nature: 1) do not make sense to achieve the goal (neither the original goal, nor the often-moved goalposts) + 2) can be counterproductive by having various negative effects. (i.e. the risk/reward of these PRs does not make sense.)

Unfortunately, the response from some others has been to invoke wishful thinking or magical thinking (perhaps cognitive defensive mechanisms to avoid directly engaging the arguments, perhaps as they challenge deeply-held beliefs about how bitcoin really works & thus what bitcoin actually is & so it threatens egos).

So, I hope your excellent work finally puts to bed at least some of the critics, who need to be shown & cannot or will not otherwise understand (“Some people need to be shown, not told”).

Congrats on the release!

RicYashiroLee commented at 11:54 am on January 26, 2024: none

Why was my last comment to Peter Todd’s comment, DELETED? Where can I find the reasoning for such deletion?

chrisguida commented at 3:24 pm on January 26, 2024: none

@luke-jr

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.

OpenTimestamps has previously used bare multisig for timestamp transactions, as it’s a bit more efficient than OP_Return. The current OpenTimestamps Server does not, as when I wrote it I was expecting bare multisig to be made non-standard. But as that didn’t happen, I should look into adding it again.

Concept NACK without another justification (eg ripping out sigop related code). @petertodd so let me get this straight: your justification for NACKing this PR is that, even though you’re not currently using bare multisig for OpenTimestamps (because you rightly expected it to become nonstandard), you could implement it… so we should just leave open this actively exploited vulnerability so that your one optional use case can, at some unknown future date, be implemented?

In that case, I think it’s totally fine for you to maintain a separate client in case miners would like to mine your potential future nonstandard transactions, and I wish you the best of luck in this endeavor.

achow101 commented at 6:53 pm on January 26, 2024: member

Why was my last comment to Peter Todd’s comment, DELETED? Where can I find the reasoning for such deletion?

Your comment was deleted because it was off topic, consisted of insults, and contributed nothing to the discussion. Continue to make such comments and you will be blocked from this repo.

bitcoin deleted a comment on Jan 26, 2024

petertodd commented at 6:52 am on January 28, 2024: contributor

@chrisguida Let me expand on my NACK: given how easy it is for miners to adopt profit-maximizing transaction policies, and how easy it is for people to relay profit-maximizing transactions to them, we should not try to filter out profitable transactions. That’ll just make life more difficult for smaller miners and encourage the growth of out-of-band transaction submission mechanisms that only large miners can realistically profit from.

We’d all be better off focusing our energy on technical improvements like utreexo that make UTXO growth less of a concern, rather than constantly adjusting mempool policy to block the latest provocation. And I say provocation for a reason: the fact ordinals/inscriptions/etc. are making people mad is definitely part of their marketing.

BitcoinMechanic commented at 7:34 am on January 28, 2024: none

@petertodd

we should not try to filter out profitable transactions

That is not what I or I believe others wish to do. The concern is the circumnavigating around sensible restrictions on arbitrary data storage, not presence of a relatively high fee.

That’ll just make life more difficult for smaller miners and encourage the growth of out-of-band transaction submission mechanisms

This is something that can only be offered by the larger pools which, as you point out can create centralization pressure. Historically miners and the network in general have rebuked pools engaging in behaviour widely considered harmful at the social level, regardless of profit. A prime example being Marapool abandoning “OFAC compliant block(s)”. Another hypothetical scenario being a pool making a tonne of money agreeing to engage in a more overt attack - deliberately mining empty blocks for example. Saying “hey, it’s more profitable for the pool and therefore their miners” ignores the inevitability of that pool collapsing.

Larger point being, if a pool were to do this in an environment where the wider network was treating harmful usage (or as you call it “profit-maximizing transactions”) for what they are and for what the creators of them declare them to be the pool would likely suffer a tremendous loss in hashrate which would certainly not be worth risking for the pittance in extra fees.

We’d all be better off focusing our energy on technical improvements like utreexo that make UTXO growth less of a concern

Improvements like utreexo and more trustless sharing of UTXOs while desirable, are not mutually exclusive with attempts to limit frivolous, provably unspendable bloat.

Provocation….is definitely part of their marketing.

This does not seem relevant beyond being a tacit admission that this stuff is not just “profit-maximizing transactions” but instead harmful and that simply the preferred “solution” is to ignore it in the hopes that the only thing sustaining it is outrage from those discussing how to mitigate the exploit.

This is wishful thinking. Zooming out, usage of the blockchain for unintended storage of data is trending in the wrong direction, and most likely due to the passive approach that is becoming increasingly intolerable given how trivial it is to implement new relay policies and how difficult it is to gain traction for new schemes that utilize new storage methods. Each “provocation” can take months and needs to achieve a certain threshold for it to become sustainable (i.e getting enough idiots to fall for the scam). Justifying to investors your latest circumnavigation of the data storage actually permitted by default policy becomes extremely difficult when you’re proposing using a network that has demonstrated its hostility vs using another more logical choice - some altcoin that actually solicits this stuff.

More simply, watching exploitation of this sort in any other system and simply hoping it will stop of its own volition is not a serious approach and demonstrably isn’t working.

totient commented at 10:17 am on January 28, 2024: none

@petertodd Is it your view that all PR’s should be ACK’d or NACK’d based on how much miners can profit from the PR?

given how easy it is for miners to adopt profit-maximizing transaction policies, and how easy it is for people to relay profit-maximizing transactions to them, we should not try to filter out profitable transactions.

There are a great many PR’s I could imagine to create an impact on miner profitability, but I don’t think the Core client development path should depend on whether the community decides at any given point in time to arbitrarily raise or lower miner profitability. Surely there must be a higher purpose here.

I don’t understand how debating Bitcoin miner P&L statements is germane to optimizing the Core client codebase. Perhaps we should focus on optimizing the client network for factors other than the financial/business interests of a specific subset of ecosystem participants.

As you correctly point out, if this PR is merged users and miners have other options to coordinate for transactions which the community writ large doesn’t want to have polluting their local mempool. It seems like your objective in the comments section of this PR isn’t really to (n)ACK the PR, but rather to lobby for your personal libre-relay branch to get merged instead (https://github.com/petertodd/bitcoin/tree/libre-relay-v26.0). I would encourage you to create a separate PR for that to be discussed on its own merits, rather than muddying this discussion with a debate over your unrelated branch.

petertodd commented at 11:20 am on January 28, 2024: contributor

On January 28, 2024 12:17:35 PM GMT+02:00, totient @.***> wrote:

@petertodd Is it your view that all PR’s should be ACK’d or NACK’d based on how much miners can profit from the PR?

Mining is a zero sum game, so PRs that increase or decrease profitability evenly usually don’t matter.

This PR however changes profitability unevenly, giving large miners an advantage by preventing small miners from getting access to profitable information: fee paying transactions that use bare multisig outputs.

That’s not good. That’s a centralization pressure that we should avoid.

I don’t understand how debating Bitcoin miner P&L statements is germane to optimizing the Core client codebase. Perhaps we should focus on optimizing the client network for factors other than the financial/business interests of a specific subset of ecosystem participants.

It’s germane because we want a decentralized mining ecosystem, where even small pools/solo miners can profit from transaction fees, ideally just as much as large pools/miners.

As you correctly point out, if this PR is merged users and miners have other options to coordinate for transactions which the community writ large doesn’t want to have polluting their local mempool.

There is no such thing as “polluting” a mempool. Transactions are just data. As long as miners are mining those transactions – and they will – you are going to eventually have that data on your node either way. Allowing it into your mempool rather than waiting for it to show up in a block is the most efficient way of processing that data due to compact blocks.

It seems like your objective in the comments section of this PR isn’t really to NACK the PR, but rather to lobby for your personal libre-relay branch to get merged instead (https://github.com/petertodd/bitcoin/tree/libre-relay-v26.0). I would encourage you to create a separate PR for that to be discussed on its own merits, rather than muddying this discussion with a debate over your unrelated branch.

For me personally, it’s much more interesting and potentially profitable if Bitcoin Core merges this pull-req and gives Libre Relay another reason to exist, and for people to pay me to develop Libre Relay further.

But ethically, I have to NACK this pull-req based on what is good for Bitcoin Core, and furthermore, Bitcoin.

nsvrn commented at 1:32 pm on January 28, 2024: contributor

@petertodd : I would suggest you to pay more attention to how Utreexo will work. It may not be as easy to alleviate the problems of UTXO bloat as you think. It might be good for mobile phone nodes if it successfully bootstraps via bridge nodes, assuming that entire network can transition to that quickly and securely might be a very bad assumption. It will also come at the cost of increased latency which you’re often concerned about but conveniently ignore here. We might have to do both i.e. worry about the current/future UTXO bloat and work on the Utreexo. I strongly request you to reconsider your position.

RicYashiroLee commented at 5:41 pm on January 28, 2024: none

Why was my last comment to Peter Todd’s comment, DELETED? Where can I find the reasoning for such deletion?

Your comment was deleted because it was off topic, consisted of insults, and contributed nothing to the discussion. Continue to make such comments and you will be blocked from this repo. @achow101 can I ask that my original comment, which originated your moderation, be shown here also in this “pushed aside” section of the PR? Just so anyone understands better your reasoning, and not just myself? I promise I will not comment over it, but I think when you exclude any comment, not just specifically mine, you must leave it available in some “moderated” section like this one, as some people might want to read a different perspective from your ‘moderation’, and in some cases understand what is not allowed by your moderation. Does that make sense to you?

achow101 commented at 6:13 pm on January 28, 2024: member

Why was my last comment to Peter Todd’s comment, DELETED? Where can I find the reasoning for such deletion?

Your comment was deleted because it was off topic, consisted of insults, and contributed nothing to the discussion. Continue to make such comments and you will be blocked from this repo.

@achow101 can I ask that my original comment, which originated your moderation, be shown here also in this “pushed aside” section of the PR? Just so anyone understands better your reasoning, and not just myself? I promise I will not comment over it, but I think when you exclude any comment, not just specifically mine, you must leave it available in some “moderated” section like this one, as some people might want to read a different perspective from your ‘moderation’, and in some cases understand what is not allowed by your moderation. Does that make sense to you?

Edit it into your earlier comment. Note that this is not permission to continue to make off topic and/or abusive posts. Every new comment sends a notification to everyone subscribed to this thread. Do not make further off topic or abusive posts - you will be blocked if you do so.

RicYashiroLee commented at 6:42 pm on January 28, 2024: none

Why was my last comment to Peter Todd’s comment, DELETED? Where can I find the reasoning for such deletion?

Your comment was deleted because it was off topic, consisted of insults, and contributed nothing to the discussion. Continue to make such comments and you will be blocked from this repo.

@achow101 can I ask that my original comment, which originated your moderation, be shown here also in this “pushed aside” section of the PR? Just so anyone understands better your reasoning, and not just myself? I promise I will not comment over it, but I think when you exclude any comment, not just specifically mine, you must leave it available in some “moderated” section like this one, as some people might want to read a different perspective from your ‘moderation’, and in some cases understand what is not allowed by your moderation. Does that make sense to you?

Edit it into your earlier comment. Note that this is not permission to continue to make off topic and/or abusive posts. Every new comment sends a notification to everyone subscribed to this thread. Do not make further off topic or abusive posts - you will be blocked if you do so.

You keep warning me that I can get blocked, you can imagine that creates a situation that is unpleasant and threatening to someone on a first warning immediately, should not sound like a last one, right? So it seems important IMV that you show the original comment I did. I am not wanting to contribute meanwhile, until I understand HOW can I, what was all that deletion and reasoning of yours all about, I would like to understand, and probably others also. What I am suggesting, w/o adding any more comments, is that you move moderated comments in this PR and maybe others also, reasonably to this ’excluded’ section, so anyone can understand your reasoning for excluding. Currently I and anyone can only see your reasoning to delete my unknown comment.

achow101 commented at 7:04 pm on January 28, 2024: member

You keep warning me that I can get blocked, you can imagine that creates a situation that is unpleasant and threatening to someone on a first warning immediately, should not sound like a last one, right?

A warning should include all information about what will happen if the violation occurs again. If you continue to make off topic and abusive posts, you will be temporarily blocked. If you continue to do so once that is up, you will be permanently block. So indeed, this warning is both your first and your last warning.

So it seems important IMV that you show the original comment I did.

Deleted comments cannot be restored, github does not provide a facility to do that. That is why I said you can edit it into your complaint comment.

theDavidCoen commented at 8:42 am on January 29, 2024: none

I keep reading ideological points and no one insists on a very basic thing: consistency. This PR should be merged because:

The code has been tested and it works.
Flags that activate a feature with no widespread consensus or technically overcome by an update to the consensus layer, should be always set to false. The Bitcoin users (node operators) should be in charge and establish their node’s policies actively.

An example: with version 26.0 we now have the ability to activate v2 transport Protocol, which is a great improvement for Bitcoin. In order to do that, the users need to set the flag v2transport to true. So the default setting is false, and this is correct.

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.

vostrnad commented at 9:26 am on January 29, 2024: none

@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 (-networkactive), broadcast wallet transactions (-walletbroadcast), persist the mempool between restarts (-persistmempool) etc. It would also mean you can just rename an option (e.g. -permitbaremultisig to -disablebaremultisig) to force the opposite default.

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 -v2transport will eventually be turned on by default.

theDavidCoen commented at 1:03 pm on January 29, 2024: none

@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 (-networkactive), broadcast wallet transactions (-walletbroadcast), persist the mempool between restarts (-persistmempool) etc. It would also mean you can just rename an option (e.g. -permitbaremultisig to -disablebaremultisig) to force the opposite default.

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 -v2transport will eventually be turned on by default.

I got your point but I didn’t mention “Default off everything”. What I actually mean is we should default to false parameters in which there is no (or no more) consensus in keeping them active by default.

In this specific case, bare multisig were useful before P2SH. Since the introduction of BIP16, bare multisig became a legacy way to have multisig. Now, there is no consensus on the utility of bare multisig, which are on the contrary used to pollute the chain. Defaulting them to off, does NOT censor transactions because pools/miners can have their own nodes’ policies and accept them, as the Peter Todd’s fork does. It simply push the users to do their homework and actively change the policies if they want to use such feature.

I edited the previous comment to make it more clear.

chrisguida commented at 8:54 pm on January 29, 2024: none

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.

@chrisguida Let me expand on my NACK: given how easy it is for miners to adopt profit-maximizing transaction policies, and how easy it is for people to relay profit-maximizing transactions to them, we should not try to filter out profitable transactions. That’ll just make life more difficult for smaller miners and encourage the growth of out-of-band transaction submission mechanisms that only large miners can realistically profit from. @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.

petertodd commented at 7:12 am on February 2, 2024: contributor

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.

BitcoinMechanic commented at 7:19 am on February 2, 2024: none

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.

petertodd commented at 7:40 am on February 2, 2024: contributor

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.

BitcoinMechanic commented at 7:55 am on February 2, 2024: none

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.

in doc/release-notes-28217.md:4 in 8672721deb

0@@ -0,0 +1,4 @@
1+P2P and network changes
2+-----------------------
3+
4+- Changing the default setting of -permitbaremultisig to false. Non-P2SH multisig transactions will no longer be relayed by default. (#28217)

jonatack commented at 3:30 pm on February 2, 2024:

Only if you need to repush, so as not to invalidate the current review ACKs, in commit 8672721deb06e66854a085c9994e99c99160b8a1 perhaps consider the following diff.

0-P2P and network changes
1------------------------
2+Updated settings
3+----------------
4 
5-- Changing the default setting of -permitbaremultisig to false. Non-P2SH multisig transactions will no longer be relayed by default. (#28217)
6\ No newline at end of file
7+- The default value of the `-permitbaremultisig` configuration option is changed
8+  from true to false.  Non-P2SH multisig transactions will be considered
9+  non-standard by the node and no longer relayed by default. (#28217)

Retropex commented at 9:52 pm on February 2, 2024:

It’s noted.

jonatack commented at 3:57 pm on February 2, 2024: contributor

ACK 8672721deb06e66854a085c9994e99c99160b8a1

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#pullrequestreview-1842509290 for examples.

1440000bytes commented at 5:44 pm on February 2, 2024: none

In that case, I think it’s totally fine for you to maintain a separate client in case miners would like to mine your potential future nonstandard transactions, and I wish you the best of luck in this endeavor.

As you correctly point out, if this PR is merged users and miners have other options to coordinate for transactions which the community writ large doesn’t want to have polluting their local mempool. It seems like your objective in the comments section of this PR isn’t really to NACK the PR, but rather to lobby for your personal libre-relay branch to get merged instead (https://github.com/petertodd/bitcoin/tree/libre-relay-v26.0). I would encourage you to create a separate PR for that to be discussed on its own merits, rather than muddying this discussion with a debate over your unrelated branch.

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

chrisguida commented at 10:44 pm on February 2, 2024: none

@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 commented at 11:18 pm on February 2, 2024: none

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?

“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?

chrisguida commented at 0:15 am on February 3, 2024: none

@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.

1440000bytes commented at 1:05 am on February 3, 2024: none

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.

These are the examples for excluding some transactions based on a government blacklist. permitbaremultisig=1 does not exclude but include bare multisig transactions.
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.
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.

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.

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.
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.

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

chrisguida commented at 2:09 am on February 3, 2024: none

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.

petertodd commented at 6:38 am on February 3, 2024: contributor

@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.

1440000bytes commented at 7:24 am on February 3, 2024: none

I don’t see how this is relevant. Default mempool policy can either exclude or include certain classes of transactions.

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.

Altering these defaults is defying the user community’s explicitly stated wishes.

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.

chrisguida commented at 1:20 pm on February 3, 2024: none

@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:

Fees. These are the shortest timescale, and also the least significant factor (~$100/day?)
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.

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.
Regulatory entanglements. Medium-to-long-term. Very significant risk.
Reputation within the bitcoin community. Can vary on short timescales and long timescales. Very significant risk.
Bitcoin’s survival and proper functioning. This is the longest-term concern, without which none of the other things ultimately matter.

1440000bytes commented at 10:45 pm on February 3, 2024: none

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.

1440000bytes commented at 10:46 pm on February 3, 2024: none

ACK https://github.com/bitcoin/bitcoin/pull/28217/commits/8672721deb06e66854a085c9994e99c99160b8a1

1440000bytes commented at 4:38 am on February 4, 2024: none

.

instagibbs commented at 2:48 pm on February 8, 2024: member

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

chrisguida commented at 3:58 pm on February 8, 2024: none

@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.

moonsettler commented at 4:07 pm on February 8, 2024: none

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

1440000bytes commented at 1:01 pm on February 23, 2024: none

Related: https://archive.is/ieLKV

chrisguida commented at 4:32 pm on March 12, 2024: none

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?

set DEFAULT_PERMIT_BAREMULTISIG to false #28217

Code Coverage

Reviews

Conflicts

Alternative

Aside

Primary Response

Some additional corrections to the initial PRs content to avoid a double post.

Technical Reasoning this is not the best means to solve the problem.

set `DEFAULT_PERMIT_BAREMULTISIG` to false #28217