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

[deepceleron]

Bitcoin didn't anticipate that people would pay fees to spam the blockchain - we required a fee for anything below .01, and if you have a profit model you can pay that...

Payments need to be self-funding, that the recipient will have a net gain by receiving the payment after including retransmittal costs.

So then what is the definition of not making "economic sense to spend"?

A single 0.0005 payment meets the most simple definition of this - received alone, it can't be spent.

However, if my wallet had 1000 BTC in it, I can currently send someone or myself 1000.0005 for free immediately. I can also spend lots of dust. This is why free transactions should be removed - if you are wealthy, Bitcoin works differently for you.

Without changing any other Bitcoin rules though, I would say it is a payment that as an input, when evaluated by minimum fee rules in aggregate with like inputs, would cost more to send in fees than the value of the payment. This is a payment likely to become an unspent TXO - for most it is cheaper to discard than to spend. This is the scenario with Satoshi Dice, a gambler will be getting hundreds of like payments of small value.

Grabbing some sample transactions with two outputs (payment + change), and determining the minimum per-input amount that would result in a post-fee value greater than zero:

1 input: 257-259 bytes = minimum payment .00050001
2 inputs: 436-439 bytes = minimum payment .00025001
5 inputs: 976-980 bytes = minimum payment .00010001
6 inputs: 1157-9 bytes = minimum payment .00016668
8 inputs: 1514 bytes = minimum payment 0.00012501
39 inputs: 5848 bytes = minimum payment 0.00008975

So it looks like a good "receiving this payment will cost the recipient" threshold is any output that is less than 1/5 of minimum fee, from the examples, 20%-40% of minimum fee should be required.

[1714943054]

1714943054

[1714943054]

1714943054

[1714943054]

1714943054

[Gavin Andresen]

Why did you pick 0.0005 BTC ?  That is a mostly arbitrary number.

I estimate a current-worst-case "orphan cost" of an average 250-byte transaction is 0.00008 BTC. See https://gist.github.com/gavinandresen/5044482 (more accurate analyses welcome, I don't pretend to have a monopoly on the "right" answer).

That number will drop as CPUs get faster/cheaper, or bitcoin value rises. So you could argue that even though dust is not economical to spend today, in 20 years it will be.

So I guess I'll rephrase my question again:  Rough, back-of-the-envelope: how much does it cost to keep a dust-like transaction output in the unspent outputs set for 20 years?

If it is a lot, then we should set the "expected time when it will be economical to spend" to either "right now" or "very soon."

If it is tiny, then we shouldn't worry so much about optimizing unspent txout size, and concentrate on other things.

I have no idea what the answer is.

[deepceleron]

Without changing any other Bitcoin rules though, I would say it is a payment that as an input, when evaluated by minimum fee rules in aggregate with like inputs, would cost more to send in fees than the value of the payment. This is a payment likely to become an unspent TXO - for most it is cheaper to discard than to spend. This is the scenario with Satoshi Dice, a gambler will be getting hundreds of like payments of small value.

Grabbing some sample transactions with two outputs (payment + change), and determining the minimum per-input amount that would result in a post-fee value greater than zero:

1 input: 257-259 bytes = minimum payment .00050001
2 inputs: 436-439 bytes = minimum payment .00025001
5 inputs: 976-980 bytes = minimum payment .00010001
6 inputs: 1157-9 bytes = minimum payment .00016668
8 inputs: 1514 bytes = minimum payment 0.00012501
39 inputs: 5848 bytes = minimum payment 0.00008975

So it looks like a good "receiving this payment will cost the recipient" threshold is any output that is less than 1/5 of minimum fee, from the examples, 20%-40% of minimum fee should be required.

I forgot to be recursive - if these miner rules are enforced, clearing the spams also must follow rules; the examples I gave above to spend dust can't be used:

5 inputs: 976-980 bytes = minimum input .00010001 -> sends .00000005
5 inputs: 976-980 bytes = minimum input .00012000 -> sends .00020000

6 inputs: 1157-9 bytes = minimum input .00016668 -> sends .00000008
6 inputs: 1157-9 bytes = minimum input .00020000 -> sends .00020000

I would say the minimum output should be 0.0002 BTC (40% of min per-kb fee). That only costs SD 40% more to spam the blockchain with spendable outputs.

[d'aniel]

I'll assume RAM is replaced every 5 years, and that Moore's law for it holds for at least 5 more years.

16GB costs $115 today and consumes about 5W of power. *  Take $0.10/kWh for electricity, and it costs

(5/1000 kW)*(5*365*24 hours)*$0.10/kWh + $115 = $137

to buy and run 16GB of RAM for 5 years.  Assuming a factor of 1/4 reduction in this price after 5 years (doubling size/unit cost every 2.5 years), we have $171 for 16GB for 10 years.

Assuming 125 bytes per utxo on average, this is 128M utxos per 16GB of RAM, giving

$0.0000013 to store a utxo for 10 years.

But we have to scale this by the number of full nodes, say 100K: $0.13 for the whole network to store a utxo for 10 years.

I only went to 10 years cause I don't know if Moore's law holds for longer.  But we can safely say it's roughly $0.13 for a network of 100,000 nodes to hold a utxo for as long as Moore's law for memory holds.

*
http://www.newegg.com/Product/Product.aspx?Item=N82E16820104302
http://www.kingston.com/dataSheets/KHX1600C10D3B1K2_16G.pdf

I did this quickly so please correct me if I did something stupid...

Edit: I overheard sipa say that the average utxo size is a bit more than 100 bytes, so I changed the number from 50 to 125 bytes.

[deepceleron]

I'll assume RAM is replaced every 5 years, and that Moore's law for it holds for at least 5 more years.

16GB costs $115 today and consumes about 5W of power. *  Take $0.10/kWh for electricity, and it costs

(5/1000 kW)*(4*365*24 hours)*$0.10 + $115 = $133

to buy and run 16GB of RAM for 5 years.  Assuming a factor of 1/4 reduction in this price after 5 years (roughly doubling size/unit cost ever 2.5 years), we have $166 for 16GB for 10 years.

Assuming 50 bytes per utxo on average, this is 320M utxos per 16GB of RAM, giving

$0.0000005 to store a utxo for 10 years.

But we have to scale this by the number of full nodes, say 100K: $0.05 for the whole network to store a utxo for 10 years.

I only went to 10 years cause I don't know if Moore's law holds for longer.  But we can safely say it's roughly $0.05 for a network of 100,000 nodes to hold a utxo for as long as Moore's law for memory holds.

*
http://www.newegg.com/Product/Product.aspx?Item=N82E16820104302
http://www.kingston.com/dataSheets/KHX1600C10D3B1K2_16G.pdf

I did this quickly so please correct me if I did something stupid...

Yes, the thing you didn't consider is that if I am a new user and fire up my brand new install of Bitcoin in five years, I'm being paid nothing for having to download 10GB of blockchain even with pruned transactions, and might just give up. Blockchain bloat has a higher price.

[Gavin Andresen]

Yes, the thing you didn't consider is that if I am a new user and fire up my brand new install of Bitcoin in five years, I'm being paid nothing for having to download 10GB of blockchain even with pruned transactions, and might just give up. Blockchain bloat has a higher price.

Sigh.

Ok, fine, so do a back-of-the-envelope for what THAT cost is.

Big +1 to d'aniel for doing the work of actually calculating a number, that is very helpful.

[gyverlb]

Yes, the thing you didn't consider is that if I am a new user and fire up my brand new install of Bitcoin in five years, I'm being paid nothing for having to download 10GB of blockchain even with pruned transactions, and might just give up. Blockchain bloat has a higher price.

In five years will you really install the Satoshi client if you are a simple Bitcoin user? Even today, lightweight clients like Electrum may be better suited to users (and it was expected IIRC).

If you install a full-fledge Bitcoin node, it should be because you want to have a say in which transactions are given priority (ie: you are propagating them or mining without delegating the choice of transactions included in a block to a pool).

If I'm not mistaken Bitcoin users don't have to pay for the blockchain size, only miners and servers used by lightweight clients. The cost of the blockchain maintenance may hit users in the end (servers for lightweight clients selling their services for example) but would probably be far less than what it would be if they all ran a full node.

[Prattler]

Assumptions:
1. Bitcoin is fully adopted tomorrow, the network is 100,000 full nodes. The network is also crunching 1000+ transactions/second, requiring UTXO (unspent tx outputs) lookup to be fast.
2. UTXO need to be stored in fast access storage. https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures#CVE-2013-2293 . You could maybe make a system setup of multiple HDD systems, but that wouldn't be cheap, at least not as cheap as "HDD space is cheap". Not if you're using 100 disks to do fast seeks.
3. 1 unspent dust output takes 100 bytes of memory.
   <sipa> Prattler: should be 41.5 bytes for each transactions which is not entirely spent (excluding any of its outputs)
   <sipa> plus 23 bytes for each unspent output
   <sipa> in-memory it's a lot more, but that's just the lowest-level cache
4. RAM costs $0.008/MB, SSD costs $0.001/MB.

For example http://blockchain.info/tx/0fda0a78210e2913ba269b3a5ff9385d29a004873333f44e56eb9efb1a488f72
Assuming the dust output is never spent and the network has to store it on:
1) RAM – the network UTXO storage hardware cost is $0.08.
2) SSD – the network UTXO storage hardware cost is $0.01. However, if SSD speed is not enough, costs will go up, as more complex systems will be required.

Ok. $0.08 might not sound like much, but remember the fees go to the miner, the network full nodes get nothing! A miner would probably be content with 0.00008 BTC (See https://gist.github.com/gavinandresen/5044482) fee to include it in a block. A malicious party could pay 0.00008 BTC to put $0.08 cost on the network. This is UTXO storage alone! In the case of SD, the miners are paid directly by the users, costing SD nothing. The only factor limiting the network costs is the block size limit.

Will correct the post if someone points out any errors in the calculations.

[Peter Todd]

Yes, the thing you didn't consider is that if I am a new user and fire up my brand new install of Bitcoin in five years, I'm being paid nothing for having to download 10GB of blockchain even with pruned transactions, and might just give up. Blockchain bloat has a higher price.

Yup. It's easy to forget the meta risk that we'll get our predictions wrong, either because technology doesn't advance the way we thought it would (where's my flying car?) or because it turns out the usage pattern didn't happen the way we though it would. (Satoshi completely missed mining pools for instance) UTXO set bloat is something that has real security risks in that it can make running a validating node prohibitively expensive, and thus breaking the security assumption underlying Bitcoin that information is easy to spread, and tough to stifle.

Anyway, all this focus lately on trying to come up with hard cost figures kinda makes me laugh, because essentially it's a whole bunch of software guys taking an opportunity to muck about as hardware designers/futurists, and then base the whole security of Bitcoin on their estimates. It doesn't really inspire confidence to me.

I mean, heck, hardware people are bad enough at making forward looking predictions: I've been working at the same cutting edge hardware startup for nearly 5 years now, and on the day of my interview they had a big schedule up on a wall... which said we were supposed to be finished the year before that interview. Whoops.


In any case d'aniel's analysis looks reasonable to me, but the big thing that stands out is he came up with the number $0.13 which frankly is relatively expensive, and for just 10 years of storage. With current 0.0005BTC/KB fees, that means my marginal cost to create a UTXO is just the data required to represent it in the transaction, 34 bytes for a standard tx. So 5mBTC/KB * 34 bytes=17uBTC or about $0.000765

So that wild guess has us undercharging for UTXO space by a factor of 170. It also shows how the cost to the creator of that UTXO is wildly dependent on the current market for blockchain space and the current exchange rate. Finally d'aniel's analysis shows how the cost of that UTXO space is wildly dependent on how many validating nodes there are, by orders of magnitude.

[mintymark]

What about Meni's  Output upkeep costs https://bitcointalk.org/index.php?topic=80435.0 proposal ?

I rather liked that.

[Peter Todd]

Ok. $0.08 might not sound like much, but remember the fees go to the miner, the network full nodes get nothing! A miner would probably be content with 0.00008 BTC (See https://gist.github.com/gavinandresen/5044482) fee to include it in a block. A malicious party could pay very little to put $0.08 cost on the network. This is UTXO storage alone! In the case of SD, the miners are paid directly by the users, costing SD nothing. The only factor limiting the network costs is the block size limit.

Have you seen my post on how miners have perverse incentives to create blocks large enough that not all the hashing power on the network can validate them?

So, what you can do as an evil miner, is pad the blocks you produce with transactions that use up UTXO space. You can create them deterministicly, so you don't have to waste your own resources storing them. As you say, the only cost to the miner is decreased propagation of your blocks, which as I pointed out is actually a good thing is small quantities, and in any case the overall orphan rate and bandwidth costs to you is strongly dependent on how much infrastructure you have.

For instance Google would be able to easily run a very successful and extremely large mining pool/validation node network for very little money because they can re-use their existing infrastructure to broadcast data around the world. Smaller players have costs hundreds or thousands of times what Google does to send a marginal byte out over the network - it pays to own your own fiber.

As you fill up your competitors UTXO space they'll be able to afford less and less IO bandwidth. The problem is as they fall behind on IO bandwidth, it takes them longer to validate blocks, and thus their orphan rate increases. Eventually they'll be forced out of business.

What's really nasty, is you don't even have to do this in an obvious way. Remember that a miner can pay fees to themselves only limited by the risk that another miner will take the fee. However, if you are the biggest miner selling blockspace any "false-fee" that you make that's less than the fees other miners would accept has no chance at all of getting picked up by them; they can't afford to. So the fee has cost you absolutely nothing. You can then get a large quantity of BTC from someone else, maybe you know someone operating a hedge fund investing in BTC, and spread that large quantity into a pile of phony transaction outputs. (tell your hedge fund clients this is to ensure the privacy of their funds) You gain because Bitcoin looks more popular, you gain because you push your competitors orphan rates up, and you gain because they're forced out of business in the long run.

[gyverlb]

Assumptions:
1. Bitcoin is fully adopted tomorrow, the network is 100,000 full nodes.

Why so many? I'm not sure why the Bitcoin P2P network would need so many nodes to be secure. A good geographical distribution may be desirable to avoid latency and government censorship but can be achieved with far less nodes.

The network is also crunching 1000+ transactions/second, requiring UTXO (unspent tx outputs) lookup to be fast.
2. UTXO need to be stored in fast access storage. https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures#CVE-2013-2293 . You could maybe make a system setup of multiple HDD systems, but that wouldn't be cheap, at least not as cheap as "HDD space is cheap". Not if you're using 100 disks to do fast seeks.

Agreed but you can use several tricks to avoid looking up the storage to protect against this kind of attack. For example Bloom Filters or preferably counting Bloom Filters (to make them more resilient as UXTOs can be volatile) can be used to avoid hitting the disk by detecting invalid outputs early. This is a bit costly to setup (generating the filters is I/O intensive and they must be regenerated when they aren't big enough to handle the growth of the UTXO database and their efficiency plumets).
Developers are smart and know about them (see BIP 0037).

3. 1 unspent dust output takes 100 bytes of memory.
   <sipa> Prattler: should be 41.5 bytes for each transactions which is not entirely spent (excluding any of its outputs)
   <sipa> plus 23 bytes for each unspent output
   <sipa> in-memory it's a lot more, but that's just the lowest-level cache
4. RAM costs $0.008/MB, SSD costs $0.001/MB.

A bloomfilter is quite efficient and can use a few bits per entries (unspent TX) it needs to filter (10 bits give you a ~99.9% efficient filter). The RAM cost in this case is negligible vs the SSD cost. You can store a billion unspent TX on a system with a couple of GB today and have to hit the disk during an attack one time out of one thousand transactions.

For example http://blockchain.info/tx/0fda0a78210e2913ba269b3a5ff9385d29a004873333f44e56eb9efb1a488f72
Assuming the dust output is never spent and the network has to store it on:
1) RAM – the network UTXO storage hardware cost is $0.08.
2) SSD – the network UTXO storage hardware cost is $0.01.

Ok. $0.08 might not sound like much, but remember the fees go to the miner, the network full nodes get nothing!

I believe you can ignore the RAM cost with a software update.
But why would you run a full node if you aren't a miner? The only reason I can see is because a SPV client security wouldn't be enough for you. Why would it be and why would it be for hundred of thousands of people?

We may see the situation from the opposite angle: if the costs of storing UTXO rise and there's only a market for one thousand full node instead of 100 000 (being paid by miners using them), then some people will run at a loss and/or full nodes will shut down until there is only 1000 of them.

And it boils down to: what is the minimum size of the Bitcoin P2P network considered healthy/secure when it's mainly composed of nodes being paid by miners.

[Prattler]

And it boils down to: what is the minimum size of the Bitcoin P2P network considered healthy/secure when it's mainly composed of nodes being paid by miners.

In my opinion, if full nodes are too expensive to run for enthusiasts and require funding by the miners, bitcoin will die.

Hence the 100,000 nodes, which would be government agencies, universities, big companies, big non profit organizations and enthusiasts (wealthy individuals).

There's no way bitcoin can survive with 1000 full nodes.

[gyverlb]

And it boils down to: what is the minimum size of the Bitcoin P2P network considered healthy/secure when it's mainly composed of nodes being paid by miners.

In my opinion, if full nodes are too expensive to run for enthusiasts and require funding by the miners, bitcoin will die.

I hope you are wrong. If we suppose that Bitcoin is successful enough for UXTO volume to become a problem it may very well be when/if Bitcoin reaches Paypal-like levels : the 1000 tx/s you mentioned earlier.

There's no way all enthusiasts will be able to host a node relaying that much. I'm not sure about the bandwidth people have but with ADSL the upload capacity isn't nearly enough. Block transfers already stress my connection (which can reliably move <100 kB/s). Assuming a mean tx size of 500 bytes including network overhead (probably very generous), I can't put more than 200 out each second.
The P2P network is based on broadcasts: each TX can be transfered multiple times. Assuming there's no optimization on average a node sends a transaction to at least half of the nodes it is connected to (the other half of them send first). My node is using a standard configuration and has ~20 connections. This means it would use all my ADSL upload BW when there's more than 20 tx/s on the network. 

For 1000 tx/s with the current broadcast system you'd need 5MB/s upload bandwidth: ~ 50Mbps upload link. This is the very best a consumer can get today in my country and for that you need to switch from landlines to fiber... I'm not against a switch to fiber myself, but I wouldn't do it just to run a full Bitcoin node.

Unfortunately consumer-grade connections capacity doesn't evolve at the same rate than RAM/CPU/disk. It jumps when infrastructure is updated, eventually we will all benefit from a 10x BW increase in the future, but we don't know when.

What can be done today and the foreseeable future is renting a VPS with a 2GB of RAM and a 100Mbps BW link. I don't expect all enthusiast to do so.

[Prattler]

For 1000 tx/s with the current broadcast system you'd need 5MB/s upload bandwidth: ~ 50Mbps upload link.

I have a 100 Mbps connection (upload and download) for $20/month, but we're going off topic here.

How much more expensive is an unspendable output compared to a spendable output to the global network?
~$0.10.

It is obviously a flaw in the bitcoin protocol that miners can include a $0.10 network cost transaction with a cost of 0.00008 BTC for themselves. And that 0.00008 BTC cost decreases with better connectivity and infrastructure, to a point it even becomes profitable for well connected miners to spam the network (See retep's post). The problem doesn't even fix itself when BTC is worth $1000, because miners are getting the tx fees, not the network full nodes.

[gyverlb]

For 1000 tx/s with the current broadcast system you'd need 5MB/s upload bandwidth: ~ 50Mbps upload link.

I have a 100 Mbps internet connection (upload and download) for $20/month, but we're going off topic here.

We aren't really off topic when discussing how many full nodes will be affordable in the future: your computations rely on the network having 100 000 full nodes. My opinion is that the number of full nodes will adapt to the cost/benefit ratio of running one.

How much more expensive is an unspendable output compared to a spendable output to the global network?
~$0.10.

If I'm correct with only 1000 full nodes this drops to $0.001. This is why I think the previous discussion about the number of full nodes is important.

It is obviously a flaw in the bitcoin protocol that miners can include a $0.10 network cost transaction with a cost of 0.00008 BTC for themselves.

It isn't if you consider that running a full node will have to be linked to mining in the future. Such a transaction doesn't cost them 0.00008 BTC, it pays them whatever they want to include it in the block. Fees will simply have to adapt to whatever rule the miners put in place, the full nodes without miners behind them don't count at all as they don't bring any valuable service (copying data around isn't much of a service).

And that 0.00008 BTC cost decreases with better connectivity and infrastructure, to a point it even becomes profitable for well connected miners to spam the network (See retep's post). The problem doesn't even fix itself when BTC is worth $1000, because miners are getting the tx fees, not the network full nodes.

This is why I disagree: if running a full node doesn't bring any income to its owner and doesn't bring any security benefit by mining what exactly is it good for?

[Jeweller]

In my opinion, if full nodes are too expensive to run for enthusiasts and require funding by the miners, bitcoin will die.

Hence the 100,000 nodes, which would be government agencies, universities, big companies, big non profit organizations and enthusiasts (wealthy individuals).

There's no way bitcoin can survive with 1000 full nodes.

I disagree with this.  In fact, I think this type of scenario (full, non-mining nodes being too expensive) is almost inevitable.  I also don't see why 1,000 or under = death, but I have a feeling there will be more nodes than that.

Basically, why run a full node if you're not mining?  Seriously.  Right now I run a full node, because, hey why not.  I already have a computer, internet, all that stuff, it's no big deal for me.  It basically doesn't cost me anything.  I just fire it up in the background when I run my computer and it goes and catches up with the blockchain.

But I get no direct benefit from running the software really.  I know the general argument is this: I gain by not having to trust the miners.  I can verify ever transaction in a published block and see if it's kosher.

To me, this is not really relevant.  If I'm on my computer, and I get block A that is pushed to me, but my full-node sees as invalid, OK, I can drop it.
But what if the next block, block B, is built on block A?  And then after that C?  What am I supposed to do, throw up my hands and say, no, you guys are all wrong!!!

Basically, if you mistrust ALL the miners, being able to look at blocks and reject them as invalid is pretty much useless.  If the mining network has actually been completely compromised, well that's pretty much game over anyway.

Another argument would be, well maybe someone's got control of my internet connection, and is feeding me made-up blocks.  But in that case you should see the block production rate collapse, because an attacker doing so would have vastly less hashing power than the total network.  So maybe he can do that with one block, but the 2nd or 3rd in that false-chain will take hours.

Basically, why not let only miners run the full nodes?  Maybe you can worry about "centralization", true, but recall that initially, every full node was a mining node, or could be.  Mining has now become more centralized because of hardware requirements.  I expect that full-nodes will do the same, and substantially all full nodes will be engaged in mining in the future, because the costs of running a full node will continue to increase, with no concurrent increase in benefit.  Once holding on to the whole blockchain becomes economically significant, you'll think, hey, I'm spending all this money to run a full node, I might as well mine while I'm at it, since mining has all of the same requirements.

Are there plausible scenarios where the _average_ home user runs full nodes years from now?
Also... why is this a problem?  Thousands of miners running the bitcoin network, and being compensated to do so.  Normal users connect to those miners and bid for transaction space.  Sounds OK.

[killerstorm]

If I'm reading this correctly, smart property and colored coins are not welcome on Bitcoin chain, right?

Well, for smart property like a car one can just use a bigger output, but low-value smart property like game items will be effectively banned.

Still, you know, it doesn't feel right when you can change rules like that. Previously the rule was that you can put anything into blockchain as long as you're willing to pay for it, but now we care about UTXO set.

I believe that the right solution is to make Bitcoin scalable in the sense that one node won't need to maintain whole UTXO set. Apparently it is possible if UTXO set is encoded using a tree-like datastructure which is maintained by miners.

But of course it is just easier to ban microtransactions than to implement the right thing.

(Well, I understand that it is not a hard ban, but if it takes a lot of time to get even 1 confirmation, it effectively makes Bitcoin inconvenient for such uses.)

[CharlesPonzi]

If I'm reading this correctly, smart property and colored coins are not welcome on Bitcoin chain, right?

Well, for smart property like a car one can just use a bigger output, but low-value smart property like game items will be effectively banned.

Still, you know, it doesn't feel right when you can change rules like that. Previously the rule was that you can put anything into blockchain as long as you're willing to pay for it, but now we care about UTXO set.

I believe that the right solution is to make Bitcoin scalable in the sense that one node won't need to maintain whole UTXO set. Apparently it is possible if UTXO set is encoded using a tree-like datastructure which is maintained by miners.

But of course it is just easier to ban microtransactions than to implement the right thing.

(Well, I understand that it is not a hard ban, but if it takes a lot of time to get even 1 confirmation, it effectively makes Bitcoin inconvenient for such uses.)

Im guessing you would have to enforce minimum fees on all transactions but make those fees really low. Costing someone else .10 when you only pay a .005 fee is unfair. It causes a form of negative externality where the true cost is pushed to someone else.

[killerstorm]

Im guessing you would have to enforce minimum fees on all transactions but make those fees really low. Costing someone else .10 when you only pay a .005 fee is unfair. It causes a form of negative externality where the true cost is pushed to someone else.

Well, in typical case externalities caused by colored coins and smart property are not different from externalities of normal Bitcoin transactions.

There is just a somewhat higher chance that such coins will be abandoned, e.g. coins representing shares of defunct company or ownership of a totaled car.

But, of course, normally users do not expect that their property will get worthless.

If abandoned outputs are really a problem, it would make more sense to 'expire' small-value outputs after some time. E.g. they are pruned out of UTXO set 1 year after last transaction.

Such rule will work fine with smart property and colored coins: if property is still in use, owner's wallet will periodically refresh it, sending coin to himself and paying a fee.

(In fact I'd say expiration would make sense for all outputs since users effectively pay maintenance fee for all outputs they own. But libertarian crows screams bloody murder when expiration is mentioned, somehow they think that storing their coins in a paper wallet for 1000 years is a sacred right.)