Make 0-value outputs non-standard #1718

Closes #1711.

Just verified: this does not make spending 0-outputs non-standard, as it should be IMHO.

ACK.

ACK

ACK

ACK

There are contract protocols that use zero value outputs. Of course they can also be of 1 satoshi in value. I don't think the difference of 1 satoshi affects how likely they are to be reclaimed nor the real-world scalability of Bitcoin given the tiny values involved. It's sort of an academic argument, the apps would get implemented even if zero-value outputs are awkward to use.

My problem with the reasoning in issue 1711 is that whilst you start with 1 satoshi being the minimum, you could use the same arguments to justify raising the minimum to 0.01 BTC or some other arbitrary value. It just doesn't seem very elegant to require a minimal sum on the output when that output is used for something other than re-allocating value.

See here for what I'm talking about: https://en.bitcoin.it/wiki/Smart_Property

ACK, though @mikehearn 's point deserves some consideration.

That said, I'm not against this change. I have no opinion one way or the other. Making these outputs non-standard might lead to weird hacks in future applications, but we can always make these outputs standard again once real apps have been implemented and the utility is proven. As Gavin already signed off on it, no problem.

I'm certainly not going to argue for making 0-value amounts illegal, the protocol allows them, and I suspect for a reason.

IsStandard() rules are still relatively simple to change, it's ultimately not more than a proposed/default policy for miners.

@mikehearn Well the reasoning on 1711 doesn't slippery slope like that; or at least I didn't intend it to.

Let me retry: The number of txouts in the txset with 1e-8 minimum txout is 2100000000000000 outputs, or about 51 bits of index. Without a limit the maximum is infinite. Perhaps its a bit academic, but it makes it possible to write design which can be shown to always work (absent a hardfork that changes things around). (Also, arguably, bitcoin nodes don't have an incentive to actually validate against double-spend 0 value transactions because they don't risk inflation)

With a value of zero, redeeming it gains you absolutely nothing (at least in the context of the system) redeeming it if it's 1e-8 gets you something and is always rational to do so when you can do it for free (e.g. when there is space left over before the next increment). E.g. I can reasonably say that a feature that autosweeps 1e-8 dust when making transactions is clearly in the users direct best interest. I can't say that for 0.

Thanks for the smart property example, getting that example was why I prodded you for your input. I don't think it changes my view at least in terms of non-standardness; though perhaps it will ultimately be a reason to not make them invalid.

Alright then, fair enough. ACK.

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/65ce215641a213cd085671a32c62cb35a9d1de62 for binaries and test log.