ACK -- happy to give miners easier policy controls

Aside: A couple pool ops were interested in a prioritize-transaction ability, which seems reasonable too. @luke-jr even had an old pull request for such functionality (#1583).

Downright counterproductive to do so without getting rid of bare CHECKSIG and CHECKMULTISIG - enforcing only P2SH and pay-to-pubkey-hash - as data-in-chain users will just use them instead at a cost to the UTXO set. (Mastercoin even has code to make the data indistinguishable from valid compressed pubkeys) Of course @mikehearn has raised objections to forcing P2SH-only for multisig in the past.

@petertodd Just because someone intends to rape you does not mean you should lose your freedom to decide you want to resist them, even if resistance is arguably futile.

You're free to either think about this emotionally, or logically. I get the impression many people around here have decided to do the former rather than latter.

OK, Gentlemen, let's focus on technology.

My rationale: some miners are interested in this. In general, We seem to prefer that core devs dabble less in policy, and try to encourage miners to take the policy reins in hand more often.

Giving miners a policy tool and letting them exercise freedom of choice seems like a good, neutral meta-policy that could be applied to this pull request.

As a general rule, too: as controversy on $topic increases, the less I want to be The Decider, however accidentally or intentionally. Saw it several times on the Linux kernel. Person Foo would pressure Linus Torvalds to make a this-direction-or-that-direction decision. The best route, and one certainly preferred by Linus, is to refuse to make a deicions, forcing the parties to figure out the damn problem on their own :)

ACK on the idea

Code-wise I don't like a command line affecting the Solver in script. In my eyes the solver is a tool to recognize scripts and doesn't make policy decisions. Can this be moved to the caller site?

@jgarzik Like it or not, we've made deliberate choices to promote policy guidelines through Bitcoin Core in the past, e.g. with the anti-dust rules; not implementing OP_RETURN will encourage practices that are more harmful to Bitcoin than the alternative.

Like I said, if you want to be logical about it make that flag ban OP_RETURN, CHECKSIG, and bare CHECKMULTISIG, so the counter-response by people who want to embed data in the blockchain is to change their code to embed it in CHECKMULTISIG-using P2SH scriptSigs - something we can't block but does keep it out of the UTXO set.

I mean, hell, Mastercoin makes use of bare CHECKMULTISIG and OP_RETURN, and I'm telling you to block both even though the bulk of my income now comes from them...

Oh, and tighten up the definition of OP_PUBKEY(s) in Solver() while you're at it to only 33 bytes or 65 bytes - current allows up to 120 bytes for no good reason.

@jgarzik by the same logic of choice, why don't we implement my "antisocial" patch, which stops bitcoin-qt from relaying anything?

(for reference: https://github.com/rebroad/bitcoin/compare/Antisocial)

@rebroad There's a difference between an option to do something that miners have an explicit right to do, and violating a protocol spec for no real reason. Anyhow, off-topic in this PR...

ACK. Seems prudent, this is policy that I know some (many? most?) large miners will deploy, and it might be a nice fast hotfix should these transactions start being used in a particularly abusive way. It's also a reasonable compromise over removing the data transactions completely,— something some of that recent discussion has had me wondering if we should do.

@gmaxwell Completely independent of this patch or recent discussions, I think the OP_RETURN change warrants a release note, linking to a longer piece on data storage in the blockchain (and why that should be discouraged).

@luke-jr There's a protocol spec? Since when? Who says the miners have this right? And who says that any node owner should have any restrictions on how they change their node behaviour? Bitcoin is not centralised, there are no laws, or at least, there shouldn't be.

@rebroad I don't think you're contributing productively now.

If you insist on a patch like this (which just puts off the inevitable for a few minutes - hardly useful), please at least just make it block inclusion rather than relay policy. Otherwise it turns miners that use it into double spending tools for no benefit or reason, forcing everyone else to use an ever more convoluted risk analysis to decide whether an unconfirmed transaction might get double spent by a -datacarrier=0 user. This doesn't help anyone, not even the node running the flag, who must process and store the transaction when another miner confirms it anyway.

Data carrrier TX means in that context, that this are TXes, which contain data unrelated to the Bitcoin system e.g. virus signatures ;)!?

I agree with @petertodd that this option should at least also ban bare CHECKMULTISIG. To be really consequent, CHECKSIG would need to be banned too, but that doesn't seem realistic at this point.

@Diapolo data carrier tx means a tx with an op_return output. op_return is a standard output type carrying up to 40 bytes of data, while making the output unspendable. It was introduced (as being allowed in isStandard transactions) because CHECKSIG and CHECKMULTISIG are already being used for storing arbitrary data in the blockchain and those two could in theory be spent (which means they have to be kept in the UTXO set forever).

Automatic sanity-testing: FAILED MERGE, see http://jenkins.bluematt.me/pull-tester/p3715_39e085a616dc8f3b177770269807393f84d7ee73/ for test log.

This pull does not merge cleanly onto current master
This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/
Contact BlueMatt on freenode if something looks broken.

Needs rebase

As multiple persons on this thread have referenced the concept, PR #3939 adds the option of considering bare multisig non-standard.

Rebased.

@gmaxwell I think my questions were completely relevant, and I don't know of a more appropriate place to ask them than in this pull request.