Add an option to allow users to disable relaying/mining data carrier transactions

luke-jr commented at 4:06 am on February 21, 2014: member

jgarzik commented at 4:14 am on February 21, 2014: contributor

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

petertodd commented at 5:53 am on February 21, 2014: contributor

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.

luke-jr commented at 5:57 am on February 21, 2014: member

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

petertodd commented at 6:00 am on February 21, 2014: contributor

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.

jgarzik commented at 6:19 am on February 21, 2014: contributor

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

laanwj commented at 7:09 am on February 21, 2014: member

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?

petertodd commented at 7:10 am on February 21, 2014: contributor

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

petertodd commented at 7:12 am on February 21, 2014: contributor

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.

rebroad commented at 11:17 pm on February 22, 2014: contributor

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

luke-jr commented at 0:40 am on February 23, 2014: member

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

gmaxwell commented at 0:45 am on February 23, 2014: contributor

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.

jgarzik commented at 0:48 am on February 23, 2014: contributor

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

rebroad commented at 11:34 pm on February 26, 2014: contributor

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

gmaxwell commented at 11:57 pm on February 26, 2014: contributor

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

in src/init.cpp: in 39e085a616 outdated

276@@ -277,6 +277,8 @@ std::string HelpMessage(HelpMessageMode hmm)
277     strUsage += "  -walletnotify=<cmd>    " + _("Execute command when a wallet transaction changes (%s in cmd is replaced by TxID)") + "\n";
278     strUsage += "  -spendzeroconfchange   " + _("Spend unconfirmed change when sending transactions (default: 1)") + "\n";
279 #endif
280+    strUsage += "\n" + _("Node relay options:") + "\n";
281+    strUsage += "  -datacarrier           " + _("Relay and mine data carrier transactions (default: 1)") + "\n";

laanwj commented at 12:39 pm on May 28, 2014:

If you want to create a new category here, wouldn’t some other options also be Node relay options? Like -limitfreerelay=, -minrelaytxfee=?

mikehearn commented at 1:03 pm on May 28, 2014: contributor

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.

Diapolo commented at 2:20 pm on May 28, 2014: none

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

leofidus commented at 3:38 pm on May 28, 2014: none

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.

leofidus commented at 3:43 pm on May 28, 2014: none

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

BitcoinPullTester commented at 3:57 pm on June 23, 2014: none

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.

laanwj commented at 5:51 pm on June 24, 2014: member

Needs rebase

jgarzik commented at 6:23 pm on June 24, 2014: contributor

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

Add an option to allow users to disable relaying/mining data carrier transactions e44fea55ea

luke-jr commented at 2:31 pm on June 26, 2014: member

Rebased.

laanwj merged this on Jun 26, 2014

laanwj closed this on Jun 26, 2014

laanwj referenced this in commit 236ae8665e on Jun 26, 2014

rebroad commented at 11:53 am on January 5, 2016: contributor

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

DrahtBot locked this on Sep 8, 2021

Add an option to allow users to disable relaying/mining data carrier transactions #3715