Change -permitbaremultisig default to off

luke-jr commented at 8:38 pm on November 6, 2014: member

(no known legitimate use, and commonly abused)

Change -permitbaremultisig default to off (no known legitimate use, and commonly abused) 978819d33d

jgarzik commented at 9:37 pm on November 6, 2014: contributor

While I do support your position, I think “no known legitimate use” is overstated. ISTR @mikehearn saying that bitcoinj defaults to bare multisig.

TheBlueMatt commented at 9:59 pm on November 6, 2014: member

ACK 100%, if someone is still using bare multisig at this point, they really need to switch to P2SH.

jgarzik commented at 10:01 pm on November 6, 2014: contributor

We need more than “should” IMO. This basically hatchets any existing user.

TheBlueMatt commented at 10:09 pm on November 6, 2014: member

Does anyone have a statistic for the number of outputs currently in bare-multisig? Note that bitcoinj is just a library, and you can go make a P2SH multisig output in it no problem. If there are many bare-multisig outputs left sitting around, we should (have, like a year ago) non-standardized creation of new ones, even if spending is still standard.

luke-jr commented at 10:22 pm on November 6, 2014: member

@jgarzik BitcoinJ uses multisig for what? O.o and nothing is “hatcheted” here, it’s just a policy default.

jgarzik commented at 10:25 pm on November 6, 2014: contributor

@luke-jr Don’t play meaningless games with semantics. The real world consequence, once this rule is deployed to the majority of the network, is to cut off use of bare multisig.

I support that, as stated, but please do not insult our collective intelligence by hand-waving away consequences as a policy default, easily changed. What matters is collective behavior, which very likely follows the default.

mikehearn commented at 11:21 pm on November 6, 2014: contributor

Please justify this change with a reasonable cost benefit analysis. If you can’t, default answer should be “no”. Backwards compatibility matters a lot - I’ve seen too many systems screw over real users and their own success by prioritising some notion of theoretical purity over real usage, to be enthusiastic about such changes.

sipa commented at 11:42 pm on November 6, 2014: member

I’m not opposed to this, but it completely depends on how much real world usage there is, or there is expected to be.

ryanxcharles commented at 1:30 am on November 7, 2014: contributor

There is a use case for bare multisig outputs. If colored coins are sent to bare 2-of-2 multisig output, then it is possible to send stealth transactions (e.g. dividends) to the owner of the asset. The first pubkey is used as the “receive” pubkey, and the second pubkey is used as the “scan” pubkey. Both privkeys are necessary to retrieve the payment, but only the scan privkey needs to be online to detect the payment. By putting these pubkeys in a multisig output attached the ownership of the colored coin, effectively an anonymous stealth address has been shared.

This idea is due to @justusranvier.

luke-jr commented at 1:42 am on November 7, 2014: member

@sipa One can reasonably expect there to be zero, since it was only passing IsStandard at all as a side-effect of P2SH using the same code. I don’t know of any real-world usage. @ryanxcharles That sounds like asking to be scammed - what happens when someone sends to a 2-of-2 that they control the other key for?

jgarzik commented at 5:53 am on November 7, 2014: contributor

@luke-jr What in the world are you talking about? Bare multisig has existed, and been relayed, since the birth of bitcoin. Nothing at all to do with P2SH.

To get precise numbers on usage, build picocoin and run https://github.com/jgarzik/picocoin/blob/master/src/blkstats.c

I’m on a crappy hotel connection without a local blockchain, and so cannot do it myself for several days.

luke-jr commented at 10:32 am on November 7, 2014: member

@jgarzik I don’t see code to relay bare multisig from until 0.6.0 (yes, this is before P2SH, so apparently I was wrong).

laanwj commented at 11:18 am on November 7, 2014: member

I don’t see the point of changing this default policy. How does it hurt anyone to allow it? In general, I’d like to avoid that we make decisions like this here.

luke-jr commented at 11:25 am on November 7, 2014: member

@laanwj Ideally, end users should be making decisions on policy - but my last PR to require it of miners didn’t get merged… As far as how it hurts: spammers are abusing bare multisig as a way to shove >40 bytes of data into relayed-by-default transactions.

laanwj commented at 11:36 am on November 7, 2014: member

Spammers are also using send-to-many transactions with invalid addresses to shove >40 bytes of data into relayed-by-default transactions. Forbidding bare multisig just closes one of the may holes through which this is possible at the moment, and sounds kind of ineffective in that regard.

dexX7 commented at 0:56 am on November 11, 2014: contributor

If there are many bare-multisig outputs left sitting around, we should (have, like a year ago) non-standardized creation of new ones, even if spending is still standard.

There should be about in total 170-195k by now, less than 20 % spent.

I believe rather sooner than later this issue resolves naturally, because other mediums of transport are indeed more appealing, but appearingly it takes time, and in particular in the context of OP_RETURN, it was not only once signaled that transaction confirmation delays play a significant role why there was no transition yet, even though everything is set for quite a while now.

You may force a move here, but I also believe the “enemy” isn’t necessarily the one who tries to find a way around barriers by it’s nature, but a potential blowback of “fighting against it and losing focus of the broader scale”. An example that serves in this context: cryptograffiti.info - a “real time message embedding service” that uses P2PKH encoding, basically because that’s what is supported by most clients.

Anyway, since almost all Couterparty and Mastercoin transactions imply the use of bare multisig, this chart might provide some insight:

xcp

ABISprotocol commented at 2:10 am on November 11, 2014: none

Wow, well that was a nice chart. Visuals help. I’ve read carefully through this thread. I think there is an argument for keeping bare multisig and not changing default to off, not forbidding it. So re. the mentions of P2SH, “why not both?” Overly simplistic I’m sure, but those are my two zerosatoshis.

luke-jr commented at 3:15 am on November 11, 2014: member

@dexX7 I think people were asking for statistics on real bare-multisig use, not abuse-for-spam.

laanwj commented at 7:37 am on November 11, 2014: member

An example that serves in this context: cryptograffiti.info - a “real time message embedding service” that uses P2PKH encoding, basically because that’s what is supported by most clients.

That was exactly what I was hinting at in my post above.

At least with bare multisig it’s possible to create an output that has arbitrary information but is still spendable (by using 1-of-N), so it is not the worst of evils.

For the sake of keeping data out of the UTXO set, the move should certainly be towards everyone using OP_RETURN, but we may first have to address the reasons why it’s not as widely used yet.

petertodd commented at 8:02 am on November 11, 2014: contributor

@luke-jr If you’re going to be consistent, make this pull-req also disable bare OP_CHECKSIG too. @laanwj Publishing information with OP_RETURN is significantly more expensive and inconvenient than publishing it with CHECKMULTISIG, so of course people use the latter. And yes, ease-of-implementation often triumphs both, as shown by cryptograffiti.info

In any case, getting rid of bare CHECKMULTISIG will certainly result in more unspendable P2PKH outputs. Heck, I’m writing a colored coin standard right now that’ll be able to take advantage of it, with P2PKH/P2SH being a fallback. (CHECKMULTISIG can publish data signed by SIGHASH_SINGLE in ways OP_RETURN can’t and never will be able to) We’re also looking into using it for stealth payments, again in a generic way so as to be able to flexibly avoid censorship with P2PKH/P2SH available as a fallback. (if the history of OP_RETURN has taught us anything, it’s that you should make every effort to make your transactions (optionally) indistinguishable from all others to avoid censorship)

That said, miners have good reasons to disable CHECKMULTISIG due to the sigops limit; I personally proposed we just get rid of bare CHECKMULTISIG not that long ago for that reason. However slightly smarter transaction selection is a good solution there as well; Eligius already implements this. @ryanxcharles Actually using CHECKMULTISIG for stealth payments was suggested in my original paper: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03613.html “Bare CHECK(MULTI)SIG output alternative” although @justusranvier is certainly capable of having reinvented the idea himself.

laanwj commented at 8:15 am on November 11, 2014: member

Publishing information with OP_RETURN is significantly more expensive and inconvenient than publishing it with CHECKMULTISIG

This is due to the 40-byte limit?

petertodd commented at 8:19 am on November 11, 2014: contributor

This is due to the 40-byte limit?

Yup. The exact numbers depend on what you’re trying to do, but there’s lots of cases where CHECKMULTISIG is cheaper; heck, P2SH/P2PKH is often cheaper.

For my colored coin protocol with SIGHASH_SINGLE you only get to sign the output at the same index as the input, so in certain cirumstances that come up in atomic trades CHECKMULTISIG is your only secure option.

laanwj commented at 10:11 am on November 17, 2014: member

No consensus exists on changing this default, so I’m closing this

laanwj closed this on Nov 17, 2014

luke-jr commented at 2:13 am on November 25, 2014: member

@laanwj There seems to be pretty obvious consensus in favour, even if people disagree over the relevance of it…

ABISprotocol commented at 7:39 am on November 25, 2014: none

—–BEGIN PGP SIGNED MESSAGE—– Hash: SHA512

Er, no, Luke. It’s closed, and I agree it should be closed, and I think there is no consensus in favor at all. What was done made sense, even if you would have rather it gone in a different direction.

Luke-Jr:

@laanwj There seems to be pretty obvious consensus in favour, even if people disagree over the relevance of it…

— Reply to this email directly or view it on GitHub: #5231 (comment)

http://abis.io ~ “a protocol concept to enable decentralization and expansion of a giving economy, and a new social good” https://keybase.io/odinn —–BEGIN PGP SIGNATURE—–

iQEcBAEBCgAGBQJUdDIPAAoJEGxwq/inSG8CLg4H/RUfW8Z9w9+aSje/m2gsPmGg dBBfVWEmOWoCCBPP2xqafzTujCnlYFRYvIV2PVseTbyNBmDRFINTra2SRnzrhdYV 1Ql01rjWDcux8cGnFZ5nDvJD6hv/QDw2uAeallNb/x66sNRwKt0RV+DWhhewtZpF h3Vgu/eoaQythW+xM+vmRjuJfabG2WICOWrIHXgUuz/od79iamrqiUuUJSv3ZxUZ IfCikqonKDxeW0ULR93E0nNdOL9VrVeHFnKElbvqr6KYgqNkFS6QkqPgG15YtfpX HbY73J/A0cMGWpwuCYgNbslfQ12KF1YQRk5oIOTvrvQfcq1ueeROu6FihmpiNUw= =fOdt —–END PGP SIGNATURE—–

MarcoFalke locked this on Sep 8, 2021

Change -permitbaremultisig default to off #5231