Blocking the creation of outputs that don't make economic sense to spend

[Peter Todd]

A lot of people have been creating various patches blocking SatoshiDice, or as some of you like to call it, Dead Puppies. However the real long term harm of SatoshiDice is that they create small-valued transaction outputs that cost more to spend than they are worth, thus bloating the un-prunable UTXO set which must be stored in relatively fast memory on every validating node. Personally I don't agree with blocking SatoshiDice, I see block space as a limited resource that should be sold to whomever is willing to pay for it, but UTXO space is not being priced appropriately by the fee system.

To that end I've created a patch that blocks any transaction output whose value is less than the per-KB fees that transaction pays. (with an upper limit to allow for deliberate sacrifices of value to miners, and a lower limit of 0.0005BTC) If SatoshiDice simply makes their "you lost" transactions have a value greater than the fee, they will be unaffected. (I suggest simply taking it out of the bet)

For miners and pool operators: this helps you in the long run because when pruning is implemented you won't have to waste money on expensive computer hardware just to hold a UTXO set full of spam. (right now >50% is "you loss" outputs from satoshidice) At the same time, the patch doesn't block SatoshiDice, so you can still collect the fees from their transactions.

For users: this also helps you in the long run, by ensuring that you can continue to run your Bitcoin client on inexpensive hardware for the long term, and continue to fully audit the entire blockchain and help keep Bitcoin safe.

[1714509151]

1714509151

[1714509151]

1714509151

[1714509151]

1714509151

[johnyj]

I just browsed through some old discussions and found this:

Re: Flood attack 0.00000001 BC
https://bitcointalk.org/index.php?topic=287.msg7524#msg7524

It seems to do more harm than good because it prevents micropayment implementations such as the one bytemaster is suggesting.

Bitcoin isn't currently practical for very small micropayments.  Not for things like pay per search or per page view without an aggregating mechanism, not things needing to pay less than 0.01.  The dust spam limit is a first try at intentionally trying to prevent overly small micropayments like that.

Bitcoin is practical for smaller transactions than are practical with existing payment methods.  Small enough to include what you might call the top of the micropayment range.  But it doesn't claim to be practical for arbitrarily small micropayments.

[d'aniel]

Can't we block the spam without nuking legitimate uses for small valued coins?

[Peter Todd]

Can't we block the spam without nuking legitimate uses for small valued coins?

How can you tell the difference between spam and a legit use for an anonymous transaction?

[d'aniel]

Can't we block the spam without nuking legitimate uses for small valued coins?

How can you tell the difference between spam and a legit use for an anonymous transaction?

By how much they're willing to pay to create the small valued txout.

[Peter Todd]

How can you tell the difference between spam and a legit use for an anonymous transaction?

By how much they're willing to pay to create the small valued txout.

The point is, a transaction that will never be spent costs the network more than one that will be spent because the former requires expensive, high-speed storage (currently RAM, and maybe SSDs in the future) while the latter doesn't even have to be stored at all by the majority of validating nodes with pruning. To charge the same price for both, which is what the current fee system does, is crazy.

[d'aniel]

How can you tell the difference between spam and a legit use for an anonymous transaction?

By how much they're willing to pay to create the small valued txout.

The point is, a transaction that will never be spent costs the network more than one that will be spent because the former requires expensive, high-speed storage (currently RAM, and maybe SSDs in the future) while the latter doesn't even have to be stored at all by the majority of validating nodes with pruning. To charge the same price for both, which is what the current fee system does, is crazy.

Oh, we very much agree on this.

Actually, if all the exotic uses of dust sized coins can be done equally well with non-dust sized ones, then I prefer your solution.

Otherwise I proposed one that still permits small valued coins here: https://bitcointalk.org/index.php?topic=151177.0

[Peter Todd]

Oh, we very much agree on this.

Actually, if all the exotic uses of dust sized coins can be done equally well with non-dust sized ones, then I prefer your solution.

Well all the exotic uses come down to either the transaction output being unspendable, in which case it should be flagged as such specifically, or the output is spendable but represents something other than a Bitcoin. In the latter case you can always have your algorithm use non-special txouts and txin's so that the actual value of the special txout in Bitcoins can float as required.

Also, look at it this way: if your special txout represents something worth less than a transaction fee, moving it incurs a net loss anyway. If it's worth more than that, having to keep a transaction fee worth of coins sitting quickly becomes a minor cost.

[Gavin Andresen]

The point is, a transaction that will never be spent costs the network more than one that will be spent because the former requires expensive, high-speed storage (currently RAM, and maybe SSDs in the future)

How much does it cost, if you assume reasonable trends for storage/electricity cost?

[d'aniel]

Also, look at it this way: if your special txout represents something worth less than a transaction fee, moving it incurs a net loss anyway. If it's worth more than that, having to keep a transaction fee worth of coins sitting quickly becomes a minor cost.

Yep, that's exactly the reason why I said I'd prefer your solution if the exotic uses can be achieved without dust sized txouts

[misterbigg]

I've created a pull-request....

Thank you for not using BOOST_FOR_EACH. One more step towards eliminating a dependency.

[CharlesPonzi]

Forcing SD to pay for such externalities it causes is a great idea.

[behindtext]

I've created a pull-request....

Thank you for not using BOOST_FOR_EACH. One more step towards eliminating a dependency.

are you trying to tell us that boost is a bad dep?

jokes aside, i think there being a floor value to bitcoin tx isn't a bad idea. with national currencies there is always a practical limit on how small a tx can get, e.g. in the US, tx below USD 0.10 are very uncommon. there is a fair deal of variation between various currencies, but a floor that is related to a basket of local currencies would make sense.

lower bound tx size = 0.10 x (episodic basket/average of currencies valued in BTC)

[kerogre256]

I've created a pull-request....

Thank you for not using BOOST_FOR_EACH. One more step towards eliminating a dependency.

are you trying to tell us that boost is a bad dep?

jokes aside, i think there being a floor value to bitcoin tx isn't a bad idea. with national currencies there is always a practical limit on how small a tx can get, e.g. in the US, tx below USD 0.10 are very uncommon. there is a fair deal of variation between various currencies, but a floor that is related to a basket of local currencies would make sense.

lower bound tx size = 0.10 x (episodic basket/average of currencies valued in BTC)

eyh for bitcoin equivalent of 0.10 is 10 satashi I can't believe why people dont see how danger for bitcoin is banig any type of transaction, I have impresion then peopol who push it hard have really really band intention.

[twobitcoins]

Transactions with zero-value outputs are already considered non-standard.  For practical purposes, 0.00000001 BTC is the same as zero (it is less than one ten-thousandth of a US cent).  The fact that bitcoin supports 8 decimal places is somewhat arbitrary -- if it supported 100 decimal places, would we permit outputs of 10^-100 BTC?  Perhaps sufficiently small outputs should be treated the same as zero-value outputs.

Another solution is a fee policy where spending an output is paid for by a fee in the transaction that created it rather than the transaction that redeems it.  See https://bitcointalk.org/index.php?topic=150749.0.

[gyverlb]

Did no one notice that there are corner cases where you have no other way than creating very low volume outputs (dust)?

Suppose you just created your wallet and got a single 1 BTC input.

Then you go shopping and the (automatically computed) price for what you want is 0.99959 BTC.

As the only Bitcoins available to you come from a single input of 1 BTC when you pay for the goods at this price, you create a transaction that pays 0.99959 BTC to the merchant, the usual 0.0005 BTC fee and 0.00001 BTC back to yourself.

Obviously this is an extreme case chosen for illustration. That said there were 70000+ transactions during the last 24h. Unless the bitcoin clients aggressively try to prevent dust from being created I guess tens or hundreds of them created dust (meaning sub 0.0005 BTC outputs). Even clever algorithm can't prevent the occasional freak transaction (and the Bitcoin user won't understand why his/her payment doesn't go through if dust is blocked).

I believe trying to prevent dust is simply not compatible with the protocol: with the standard Satoshi client you can't even be sure if the 0.00001 BTC are paid back to the original buyer (they are paid to a brand new address).

In fact today's dust may be probably tomorrow's gold. I'm not sure exactly when 0.0005 BTC fees were made the default/kB but at the time they were certainly less valuable than today. If the BTC value keeps rising in the following years, fees will have to be reduced if small payment/transfers are to remain cheap.

I've seen developers discussing a way to track the confirmation delays of transactions to compute a recommended fee and it makes sense to me. Users shouldn't have to think twice about fees for every transaction : the recommended one should reflect the true "market value".
This means than dust will not necessarily remain dust: it will depend on the current transaction rate and miner efficiency at putting transactions in blocks.

[ciphermonk]

I think that, above all, we must maintain bitcoins decentralized nature. That means we should let miners price transactions.

At the end of the day, if a miner accepts a transaction in a block, he agrees to basically store it forever on his hardware. A transaction would therefore have a storage cost. It also has a computational cost as validation might be required in the future when spending outputs of this transaction.

Therefore, I strongly believe that, instead of finding static solutions to transaction costs, we must enable miners with tools to price them correctly. This is the only way we will see the light in a bumpy, uncertain and highly dynamic market environment. Good pricing competition should help us find an equilibrium.

If they don't do it already, miners need to start operating more like businesses. They need to crunch the number and understand the relationship between various transaction parameters and their cost. They need to do that for their own sake as they will need to host these transactions pretty much forever. They also need tools to tweak pricing quickly and dynamically as market forces change.

Under such assumptions, the current transaction dust we are experiencing should be reduced. My prediction is that if miners acted more as rational market players, they would require much higher fees for very small and young transactions. If the transaction is so small that it makes no economical sense to spend it, it should be priced accordingly. It will most likely be impossible to prune it and will require storage in UTXO memory. Some miners might also decide to drop them entirely. This is entirely up to them.

So how does the landscape look today? Are miners sufficiently empowered to dynamically change their pricing policies?

[justusranvier]

If they don't do it already, miners need to start operating more like businesses. They need to crunch the number and understand the relationship between various transaction parameters and their cost. They need to do that for their own sake as they will need to host these transactions pretty much forever. They also need tools to tweak pricing quickly and dynamically as market forces change.

Under such assumptions, the current transaction dust we are experiencing should be reduced. My prediction is that if miners acted more as rational market players, they would require much higher fees for very small and young transactions. If the transaction is so small that it makes no economical sense to spend it, it should be priced accordingly. It will most likely be impossible to prune it and will require storage in UTXO memory. Some miners might also decide to drop them entirely. This is entirely up to them.

So how does the landscape look today? Are miners sufficiently empowered to dynamically change their pricing policies?

More of them would do this if it wasn't for the distorting effect of the block subsidy. Miners won't have a large incentive to optimize their transaction fee policies until fees are a significant portion of their revenue, which won't happen until the transaction rate starts to approach PayPal's.

[Gavin Andresen]

Forcing SD to pay for such externalities it causes is a great idea.

I agree.

That is why I ask "what is the external cost, with reasonable assumptions."

So I'll ask again: what is the cost-per-(pick-your-favorite-time-unit) to the network of an extra unspent transaction output?

[justusranvier]

I don't know what the numbers are, but the way I would calculate it would be to ratio the size of an unspent output to the price of RAM, integrated out to a suitable time in the future to get the net present value.