reject all OP_RETURN outputs tx #6407

• reject all OP_RETURN outputs tx
• print reject tx's hash

NACK.

@jonasschnelli Read the diff before NACKing. The description sucks, but the code seems reasonable enough. I'd utACK, but I'm not feeling very confident in my judgement right now.

The code looks like...

     if (nDataOut > 1) {
         reason = "multi-op-return";
         return false;
     }
+    // all OP_RETURN is not permitted
+    if (nDataOut == tx.vout.size()) {
+        reason = "all-op-return";
+        return false;
+    }

Do we have problems with a transaction containing 1vin (maybe [to]large) with 1 OP_RETURN vout?

I don't see the point. NAK without justification.

The improved diagnostic output is nice.

Why would you want to reject transactions that are all OP_RETURN? From the viewpoint of the UTXO set those transactions are great, entirely provably unspendable - so the inputs are removed and nothing new is added.

(remember that the alternative, effectively accomplishing the same, is to send to the coin eater address or another address for which no private key is known - with the difference that that pollutes the UTXO set forever)

NACK

What is the point? You do not like the sender burning the OP_RETURN output value or giving the complete inputs value to miners (in the case OP_RETURN output value is zero)? I do not get it, sorry.

+1 @laanwj

@laanwj UTXO set is not the only relevant resource. It would make more sense to limit this special case to OP_RETURN without data. With data encourages spam unnecessarily.

What is the reason for this PR?

reject tx like this one, https://blockchain.info/tx/9e492bbc6e56f0a7b5369a3d359c82e29e53f25a6d6a9d6d399b772224603b5c

{
    "hex" : "0100000001d258f657290aa721d0187b8c6ab54f603c1e673648d6375ff528b0d16edf26f90b0000008a473044022062dddfafe6ce1641639af00d76cb9164fa0e91c865c341363b3dcccc5a53914202201e2ad564407e5263c619aa6395919aef4999c7ccc8e8a7d31e6752fdf6c538c0014104334ec322ef674d8a91a5467b78cb12fab3de961aa3d6c2d6afd844526e18c8dd12e9b21d5f9411dfa37689c551d2572465f633df73b0d12015aeb72d423e0d30ffffffff010000000000000000016a00000000",
    "txid" : "9e492bbc6e56f0a7b5369a3d359c82e29e53f25a6d6a9d6d399b772224603b5c",
    "version" : 1,
    "locktime" : 0,
    "vin" : [
        {
            "txid" : "f926df6ed1b028f55f37d64836671e3c604fb56a8c7b18d021a70a2957f658d2",
            "vout" : 11,
            "scriptSig" : {
                "asm" : "3044022062dddfafe6ce1641639af00d76cb9164fa0e91c865c341363b3dcccc5a53914202201e2ad564407e5263c619aa6395919aef4999c7ccc8e8a7d31e6752fdf6c538c001 04334ec322ef674d8a91a5467b78cb12fab3de961aa3d6c2d6afd844526e18c8dd12e9b21d5f9411dfa37689c551d2572465f633df73b0d12015aeb72d423e0d30",
                "hex" : "473044022062dddfafe6ce1641639af00d76cb9164fa0e91c865c341363b3dcccc5a53914202201e2ad564407e5263c619aa6395919aef4999c7ccc8e8a7d31e6752fdf6c538c0014104334ec322ef674d8a91a5467b78cb12fab3de961aa3d6c2d6afd844526e18c8dd12e9b21d5f9411dfa37689c551d2572465f633df73b0d12015aeb72d423e0d30"
            },
            "sequence" : 4294967295
        }
    ],
    "vout" : [
        {
            "value" : 0.00000000,
            "n" : 0,
            "scriptPubKey" : {
                "asm" : "OP_RETURN",
                "hex" : "6a",
                "type" : "nulldata"
            }
        }
    ]
}

I don't see a purpose to that one other than cleaning up the UTXO set (inefficiently). Maybe the ideal solution is to provide some easy way to deprioritise these.

https://blockchain.info/address/1C1r1zMnPFfjQYhW2np6h1vynxrfKK2zHm (https://chain.bitmain.com/api/v1/address/1C1r1zMnPFfjQYhW2np6h1vynxrfKK2zHm)

Txs from this address are all dust tx, should reject them.

Dust has nothing to do with OP_RETURN. Any value sent to OP_RETURN outputs is burned, because these outputs are provably unspendable and thus pruned.

@bitkevin So IIUIC you want to reject only empty-data OP_RETURN transactions? By dust you mean they are useless, but their fee is their input value which is 0.00001. As the size is only 199 bytes, this is way above our "dust" limit (as defined in the source code). Can you please highlight in the decoded TX above the line which is the reason for this PR, so it is clearly stated?

In fact these transactions help clear the UTXO set. As Luke says, inefficiently, yes. They can all be cleared at once, because the input address 1C1r1zMnPFfjQYhW2np6h1vynxrfKK2zHm is Brainwallet with the passphrase "cow" so the private key is known (and this is one of the reasons we see so many transactions related to this address). Or they can be grouped in one bigger output in one transaction etc.

    BOOST_FOREACH(const CTxOut& txout, tx.vout) {
        if (!::IsStandard(txout.scriptPubKey, whichType)) {
            reason = "scriptpubkey";
            return false;
        }

        if (whichType == TX_NULL_DATA)
            nDataOut++;
        else if ((whichType == TX_MULTISIG) && (!fIsBareMultisigStd)) {
            reason = "bare-multisig";
            return false;
        } else if (txout.IsDust(::minRelayTxFee)) {
            reason = "dust";
            return false;
        }
    }

If the only ouput is TX_NULL_DATA, It can avoid dust detection.

NACK as this won't actually do anything against storing data in the chain, and all the alternatives to do so are worse.

Dust filtering should be accomplished some other way, because nothing would stop the spammer from using another kind of transaction if these specific ones were filtered.

If the only ouput is TX_NULL_DATA, It can avoid dust detection.

Which is okay - remember, these transactions do not create UTXO entries at all. The reason for dust filtering is to avoid UTXO pollution.