Bitcoin Forum

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 (https://github.com/petertodd/bitcoin/tree/block-uneconomic-utxo-creation) 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.

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

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.

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 (https://bitcointalk.org/index.php?topic=151177.0)

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.

How much does it cost, if you assume reasonable trends for storage/electricity 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 :)

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

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

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.

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.

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.

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?

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.

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?

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.

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 (https://bitcointalk.org/index.php?topic=150194) - 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.

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.

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.

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.newegg.com/Product/Product.aspx?Item=N82E16820104302)
http://www.kingston.com/dataSheets/KHX1600C10D3B1K2_16G.pdf (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.

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.

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.

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.

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.

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

I rather liked that.

Have you seen my post (https://bitcointalk.org/index.php?topic=144895.0) 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.

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.


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).


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.


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.

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 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.

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.

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.


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 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).


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?

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.

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.

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.)

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.

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.

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

EDIT: Oh, bad idea...

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.

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).

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.

+1

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)

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.

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


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

This is what you want Provably Unspendable/Prunable Outputs (https://en.bitcoin.it/wiki/Script#Provably_Unspendable.2FPrunable_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:


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 (http://sourceforge.net/mailarchive/message.php?msg_id=30705609)

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