## Can transaction validation really be free?

3

If you don't validate a transaction, then you are at risk for relying on it, propagating it, or including it in a block you're mining. For this reason, the default behavior is to validate every transaction (I think!). Otherwise there is some reliance on free transaction validation, which turns out not to be free because of the risks. There is currently no simple way to pay for transaction validation in order to mitigate those risks. I think there should be.

Some guys at Microsoft did some research into the idea of incentivizing transaction propagation (which would necessarily require validation for those getting paid).

I am wondering if it is worth it to develop an idea I had and present it to the bitcoin dev list. It's called "bonded proof" and consists of a proof message which is a valid block (except that it's hash isn't low enough) and the TXOut that is the bond. It isn't actual proof, but tentative proof that can be verified and, if found to be wrong, redeemed. The bonded proof is signed by the bitcoin address that holds the bond. I imagine the TxOut would have to hold at least 100X a standard Tx Fee, but since it's not expected to ever be redeemed, it could hold far more just as a show of good faith.

If the proof is wrong, the maker of such a bonded proof can expect the bonded proof to be redeemed in a block. The "transaction" that redeems such a failed bonded proof would need to include the entire proof message, plus an index into the block to identify the invalid transaction, plus a btc ("disproof") address to receive some part of the bond (say 50%). Block validation would then have to verify that the identified transaction was actually invalid, and this would cause (say 50% of) the TxOut holding the bond to be transferred in the coinbase transaction, while the rest would go to the disproof address.

Miners would be free to ignore any such bonded proof, or to use them if and when they appear to be valuable, but I propose the following mechanism as a default: The maker of a bonded proof ("weak") block would request a fee by making it the coinbase transaction in the weak block. Miners would add a transaction sending that fee to the address in the weak coinbase transaction if they want to encourage the block assembler. By default, any time a node has a brand new transaction to broadcast, it would make a weak block with the new transaction in it as long as the operator has specified a TxOut for the bond.

Selfish miners could turn this off if they wish to cheat those who assemble these blocks, just as they are already doing (probably because it's difficult not to) to those who propagate transactions. I suspect behavior would be better than that. Thousands of people have run full nodes without compensation, and this just makes it easier to reward them, and offload to them the time-consuming validation step, which they are doing anyway (by default).

Furthermore, non-mining nodes would have an incentive to validate these weak blocks in order to find an invalid transaction (root out cheaters who don't bother validating) and redeem the proof block.

The idea of bonded proof appeals to me not just in the case of weak block validation, but as a general mechanism. It isn't called that with regards to the Lightning Network, but the idea is very similar: motivate helpful behavior while requiring that the helper stake some bitcoin on the claim that he is helping.

the default behavior is to validate every transaction (I think!): with BitcoinCore, yes, but not "client-only" (SPV) – Wizard Of Ozzie – 2015-09-30T04:51:35.683

1

There is currently no simple way to pay for transaction validation in order to mitigate those risks. I think there should be.

This statement is incorrect. Transactions include a fee which the miner that finds the block will get. Therefore it's in the miner's interest to include transactions and thus validate them.

Once transactions are in blocks, it's in everyone else's interest to validate for themselves and they don't run any risk doing that. (They'd run a risk NOT doing that.)

There is currently no real problem of transactions getting stuck because "it's too risky to validate". There are a few miners that mine empty blocks, possibly for this reason, but more likely because of lazyness and misunderstanding. And that will become even less of a problem every time the block-rewards halve.

You're right, if we're talking about transactions that have been confirmed, or we're talking about miners. But if we restrict the discussion to non-miners and unconfirmed transactions, the statement is true, right? – Dave Scotese – 2015-09-29T16:04:54.267

Those nodes provide a service to the network by spending a little cpu validating and bandwidth propagating transactions. There no risk though: if you find the transaction invalid you simply drop it and ban the user that sent it. If not you propagate. If it turns out that your upstream peer finds it invalid anyway then the worst it will do is disconnect and ban you. Maybe not pleasant but if it really is a problem on your end (outdated version maybe) then it's a good sign that some human intervention is needed. Better have such a warning than not noticing it at all. – Jannes – 2015-09-29T19:10:26.013

Everything for me falls into one of three categories: benefit, cost, or neutral. Unpleasantness is always cost. But it isn't high, which I guess is your point. It just seems like an opportunity for there to be a tragedy of the commons when the transaction rate is higher and people don't like their cpu constantly churning, so they shut down their node. – Dave Scotese – 2015-10-01T04:18:43.577

"upstream" in my previous comment should be "downstream". - You could say that by forwarding transactions, your node is probing for feedback about the health of the network as well as it's own health. If others start refusing those forwarded transactions (banning your node), you know something is wrong (either your own node or the network). Maybe not a convincing incentive to do a lot of work, but since it's so cheap, actually smart to do anyway. – Jannes – 2015-10-01T09:58:01.000