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

[jtimon]

Fees should be enough to prevent spam transactions.
For unspent transactions...I'm with killerstorm about the tree-structured chain.

Also about his other proposal which seems less destructive, at least for legitimate use cases like colored coins/smart property.
Instead of expiring an address after a given number of blocks, I would prefer to activate some kind of no proportional demurrage so that we don't expire addresses with lots of funds without putting extra hardcoded validations about "small" amounts.
People just needs to move the coins if they still want them.

[Prattler]

Let's assume bitcoin has scaled up to 2000 tx/s. We all want this, right? https://en.bitcoin.it/wiki/Scalability. Block size is 500 MB. CPU, network and archival blockchain storage seem to solvable.

Let's say SatoshiDice-like systems are doing informational transactions that produce unspendable outputs, because they can and users are paying for it anyway (proved in real life). 400 unspendable outputs per second would be realistic.

This would be bloating UTXO data at a speed of 52 GB/year. That's a very big memory leak. And this is just the unspendable outputs.

Bitcoin cannot scale up until such dust output spamming is discouraged at the protocol level.

[killerstorm]

This would be bloating UTXO data at a speed of 52 GB/year. That's a very big memory leak. And this is just the unspendable outputs.

You can save such "unlikely to be spent" TXOs to disk.

EDIT: Oh, bad idea...

[gyverlb]

Let's assume bitcoin has scaled up to 2000 tx/s. We all want this, right? https://en.bitcoin.it/wiki/Scalability. Block size is 500 MB. CPU, network and archival blockchain storage seem to solvable.

Let's say SatoshiDice-like systems are doing informational transactions that produce unspendable outputs, because they can and users are paying for it anyway (proved in real life). 400 unspendable outputs per second would be realistic.

This would be bloating UTXO data at a speed of 52 GB/year. That's a very big memory leak. And this is just the unspendable outputs.

Bitcoin cannot scale up until such dust output spamming is discouraged at the protocol level.

This is more and more looking like FUD.

52GB is nothing. The mining economy today at current BTC price is above $60M/year. You can have reliable servers handling more than 5 time this amount in RAM for less than $10k today. Add BloomFilter and sugar on top and you can probably do it on a $2k server.

If nothing changes running full nodes will be restricted to tens or hundreds of companies making a living of it. They will simply run the pools of today but charge more.

[gyverlb]

This would be bloating UTXO data at a speed of 52 GB/year. That's a very big memory leak. And this is just the unspendable outputs.

You can save such "unlikely to be spent" TXOs to disk.

Actually you need a fast way to find out if a TX used as input for another one is valid and spendable and don't want to go to disk for that (of course all unspent TXs are stored on disk but you need a structure in RAM to avoid DoS attacks using large numbers of invalid inputs).

[greBit]

Bit late to the party on this one. Has anything been decided? I'm with killerstorm, it would be a huge shame to prevent colored coins/smart property in this way.

If I want to make a 'worthless' transaction of one satoshi, and im willing to pay a fee for the pleasure, where's the harm?

But the expiry idea seems like a less drastic solution than just effectively banning what you decide are worthless transactions.

[allten]

Bit late to the party on this one. Has anything been decided? I'm with killerstorm, it would be a huge shame to prevent colored coins/smart property in this way.

If I want to make a 'worthless' transaction of one satoshi, and im willing to pay a fee for the pleasure, where's the harm?

+1

[jgarzik]

If I want to make a 'worthless' transaction of one satoshi, and im willing to pay a fee for the pleasure, where's the harm?

Well, at present, people are uploading wikileaks data, GPG encrypted data, python scripts, hidden wiki URLs, and other data spam.

[greBit]

If I want to make a 'worthless' transaction of one satoshi, and im willing to pay a fee for the pleasure, where's the harm?

Well, at present, people are uploading wikileaks data, GPG encrypted data, python scripts, hidden wiki URLs, and other data spam.

Are they paying fees?

[Peter Todd]

Well, at present, people are uploading wikileaks data, GPG encrypted data, python scripts, hidden wiki URLs, and other data spam.

Are they paying fees?

Yes - about $500 worth of fees for the 2.5MB wikileaks data for instance. (although if they weren't so impatient, it could have been about $50)

[AsymmetricInformation]

Bit late to the party on this one. Has anything been decided? I'm with killerstorm, it would be a huge shame to prevent colored coins/smart property in this way.

If I want to make a 'worthless' transaction of one satoshi, and im willing to pay a fee for the pleasure, where's the harm?

+1

Both the SatoshiDice transactions and those for timestamping are really about storing a specific piece of information in the chain, forever.

Isn't there a way of doing this without touching the UTXO space? Some kind of flag to let the miner know "Hey, I really just want you to put '9b3fc6a603193ce5ad63a619482bc645035af1e89137ae1c69d7ad35227af511' into the blockchain, I dont actually care about this transaction at all."

The Bitcoin transaction doing this could then just be a direct payment TO the miners. The last piece of the puzzle would be for miners to choose to make this payment lower than the transaction fee, and incentives would align such that everyone could save money with non-UTXO transactions (they are cheaper than just burning a satoshi).

Is this not possible? Sorry, I don't understand UTXO enough to figure this out.

[killerstorm]

Both the SatoshiDice transactions and those for timestamping are really about storing a specific piece of information in the chain, forever.

Isn't there a way of doing this without touching the UTXO space?

 Some kind of flag to let the miner know "Hey, I really just want you to put '9b3fc6a603193ce5ad63a619482bc645035af1e89137ae1c69d7ad35227af511' into the blockchain, I dont actually care about this transaction at all."

Colored coins and smart property actually need to be transferred via transactions, timestamps are not enough.

Is this not possible? Sorry, I don't understand UTXO enough to figure this out.

It is fairly easy to implement timestamping with close to zero overhead.

[Peter Todd]

Isn't there a way of doing this without touching the UTXO space? Some kind of flag to let the miner know "Hey, I really just want you to put '9b3fc6a603193ce5ad63a619482bc645035af1e89137ae1c69d7ad35227af511' into the blockchain, I dont actually care about this transaction at all."

This is what you want Provably Unspendable/Prunable Outputs

It's still a bit controversial, but there is consensus among the devs that at least a 20 byte data payload should be made a standard transaction type. That is a zero-value output of the form:

Code:

scriptPubKey: OP_RETURN <20 bytes>

We may eventually enforce that the 20 bytes be a digest of a SHA256 hash to make sure putting arbitrary data in the blockchain is very difficult - gmaxwell came up with a (very clever) way to do this: To prevent arbitrary data storage in txouts — The Ultimate Solution

[AsymmetricInformation]

Isn't there a way of doing this without touching the UTXO space? Some kind of flag to let the miner know "Hey, I really just want you to put '9b3fc6a603193ce5ad63a619482bc645035af1e89137ae1c69d7ad35227af511' into the blockchain, I dont actually care about this transaction at all."

This is what you want Provably Unspendable/Prunable Outputs

It's still a bit controversial, but there is consensus among the devs that at least a 20 byte data payload should be made a standard transaction type. That is a zero-value output of the form:

Code:

scriptPubKey: OP_RETURN <20 bytes>

We may eventually enforce that the 20 bytes be a digest of a SHA256 hash to make sure putting arbitrary data in the blockchain is very difficult - gmaxwell came up with a (very clever) way to do this: To prevent arbitrary data storage in txouts — The Ultimate Solution

Pretty cool...looks like I have more reading to do.