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

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

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

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.

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

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

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.

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

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.

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

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

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

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.

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

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.

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:

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.

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

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.

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

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

This is due to the 40-byte limit?

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.

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

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

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