Topic: Economically Unspendable Outputs: A Problem On The Radar - page 5. (Read 16508 times)

Would it be better for Bitcoin if SatoshiDice were to switch to LiteCoin instead?

5000 satoshi is below the minimum tx fee for relay of non-aged coins so how could this be resolved? I think SD added this to work around psy's hack.

#2 was seemingly resolved/minimized...
https://bitcointalksearch.org/topic/m.1604045

I know that 5000 satoshi for the 0.01 bet size is marginal, but anything much larger becomes spendable, surely.

Absolutely first-class, A+ rant!  I quite agree and this thread is suspicious in the extreme.

Fees in SD's increased traffic only pays for some of the added costs. Specifically, the SD traffic that produces economically unspendable outputs is not sufficiently compensated by the transaction fee.

As I have said many times there are two components to the SD spam:

1) high transaction volume
2) economically unspendable outputs

While #1 is not particularly desirable since it doesn't come with a corresponding increase in Bitcoin adoption, it is tolerable since eventually we will have to support that volume regardless. What is lamentable is that it drives transaction fees up prematurely but this is only a temporary effect.

#2 is a disaster! This is what could "KILL" Bitcoin, because it disproportionately increases the initial and ongoing costs of mining! And it's not a storage issue. It's a CPU issue, because the bottleneck is in signature verification. Although it certainly increases storage costs (by a small amount).

ECONOMICALLY UNSPENDABLE OUTPUTS are the terminal problem. Not the transaction volume.

To be fair, it is paid for by fees which are bigger than all other sources combined, and will get bigger because of the 0.5% change. Which means it is not spam, but a type of high-volume flow which, arguably, Bitcoin is not ready for.

Some facts. "DP-involved" means any transaction which has a SatoshiDICE address in either the inputs or the outputs.


There is so much SD transaction spam that it is enough to fill blocks of any size. Can anyone honestly say with a straight face that this is healthy, productive growth?

OK, thanks for the further information, it is indeed reassuring! And in fact, it is now clear that SatoshiDice is not an imminent risk to Bitcoin because you are monitoring the situation and it is always under your control. The real risk lies in the sudden emergence of one or more of a special type of high volume application owned by people who will not make themselves known to the forum. We can call them Dead Puppy Apps, if i can borrow gmaxwell's terminology here.

Let's remember that the small txs from SatoshiDice are only about 1/8th of all txs on the Bitcoin network (1/4th of SD-related txs, which are in turn 1/2 of the network, roughly). If SD stopped the loss-bet confirmation txs, you only reduce blockchain usage by 1/8th... and this amount will be re-added to the network within a month or two.

It is a very silly distraction to get in a fuss about the loss-bet txs from SatoshiDice.

Okay, thanks for clarifying. I understand it now. This deserves a good response but not in the general discussion forum where the lunatics mingle with the sane. I'm going to move this to the thread you started in Development and Technical Discussion.


I'm the first to admit that I've projected a certain amount of sensationalism. But only because this is a social issue. Despite Bitcoin's decentralized nature, there is still a community that needs to act together for the common good. For example, what if we need a hard fork some time in the future?


There's a lot more room for debate regarding the block size, and it's not really a pressing issue right now which is why I have not brought it to the same level of attention that I did with this SD spam. I posted this thread because there was a lot of consternation in bitcoin-dev about the deluge of S.DICE loss confirmations.

I do concede that the block size issue is not so clear cut. There are good arguments to be made on both sides. But there are no sound arguments for keeping the SD dust.


That is a concern but if people want to pay the transaction fees to send economically spendable amounts, there's nothing that we can really do about it, since it can't be distinguished from "legitimate use." In the long run the bots will just drive fees up prematurely but that might be something we just have to accept.

DoomDumas, you might not agree with misterbigg's unconventional cage-rattling approach but he does deserve to be heard. I disagree with him in a major way regarding the 1Mb limit, but I do agree with his concerns about Bitcoin being abused as a messaging system and shotgunned with micro-transactions.

You had a good laugh about Mt Gox choking up earlier this week, as you use other exchanges, but what if Bitcoin itself chokes up? Are you going to laugh about that and load up on pre-mined Freicoin instead?

I am still concerned because people are talking about using bots for SatoshiDice. This would seem a green light for high-volume traffic growth and Bitcoin seizures which would make Mt Gox's choke-up a pause for breath in comparison.

The only information that miners absolutely must keep on hand is the set of unspent outputs (UTXO set) because it's possible to allow them to discard all the rest of the historical transaction data using optimizations that have been discussed but not yet implemented. The UTXO set is what some people refer to as unprunable data.

Right now that set is a few hundred megabytes, but if we imagine a billion Bitcoin users all playing Satoshi Dice it would get very large unless there is an incentive for users to limit the number of outputs in their wallet. Especially when the transaction rate is very high miners are probably going to want to keep the UTXO in RAM to speed up verification, which means as the set gets larger their capital equipment costs go up.

So if they effectively subsidize transactions which reduce the UTXO set by requiring a lower fee in the number of outputs is less than the number of inputs they lose a bit in fee revenue but gain in terms of lower hardware requirements.

Once miners start doing this, client developers will have an incentive to include dust collection into their coin selection algorithms and the dust will be cleaned up automatically.

+1

MisterBigg being more and more Ignored.. not surprising

Okay, I have to admit that I do not fully understand the exact mechanics of your proposal. Are you saying that there is a way to financially reward miners to collect the dust? Because that wasn't apparent from your post, and I think it is what gmaxwell was saying. I would love to be proven wrong of course, because this would solve the spam problem in a way that fixes it for anyone who exhibits the bad behavior and not just targeting one company specifically.

And you refrained from quoting the explanation of why they are incentivized.

You didn't read. I quoted gmaxwell's explanation for why miners are not really incentivized to clean up dust (hint: it would cost them money).

We do have to worry about it, because the dust makes transactions cost more than their value. I'm not sure I understand your point, do you not get that unspendable outputs are bad?

Then let's not worry about it!  Great.

Miners have complete control but they also act in their own economic self-interest (just like S.DICE). Cleaning up dust would cost caring miners money:


There is no incentive to clean up dust.

Miners have complete control over which transactions they include in a block. They don't need to use the default rules, nor do they need to change the protocol. A couple lines of code could create the necessary incentive to clean up all of these "unspendable" dust outputs.

https://bitcointalksearch.org/topic/dust-collection-150726

Nobody is arguing against that. The point raised by the OP is that the current structuring of transaction fees only takes into account the current network cost of a transaction and doesn't capture the (indeterminate) future cost of keeping that unspent output available.

If you want to understand it in software terms: intentionally unspendable outputs have the same devastating effect as a memory leak. Thus one has to try to either tame them or define a scheme by which the blockchain can be cleared from them once in a while.