The tl;dr: Represent a piece of property, say a stock certificate, as a small value of bitcoin. By transferring the bitcoin to another user, you are transferring the ownership of the property. This can be useful for creating distributed markets where property can be traded for bitcoins without requiring a trusted intermediary.
I don't understand why this is such a big deal for the developers. You see a lot of panic about UTXO bloat. It seems to me this can be solved by making the UTXO cache a bit smarter. If you have a very small value output that has not been used in a while, store it on the harddrive, not in RAM. If the output shows up in a new transaction, you will have a cache miss, but that doesn't seem like a serious issue. If the client is smart property aware, store those dusty-looking outputs in a seperate cache.
This might be an attack vector for DDOS attacks, but that should be solvable by throttling the processing of transactions that miss the cache.
The propogation of transactions that are not in the RAM cache might be a bit longer, but that is the price you pay for making a transaction with dust.
The problem is that Bitcoin is a distributed network, and therefore the whole blockchain needs to be replicated across all the computers across all the network.
Right now, the blockchain is around 9GB, most of it because of "dust" - that is, if you want to set up your own Bitcoin node, you need to download 9GB of data. And this is growing quite fast.
The practice of microtransactions was abused a lot - for example, SatoshiDice uses 1 satoshi (the minimum amount) transactions to confirm that a player lost. Or some other guys used the blockchain to embed WikiLeaks documents using the same hacks - right now everyone needs to download all this data.
tl;dr; it's not about caching and speed, it's about the amount of storage required to keep all the dust forever and ever.
Also, from what I gather from the commit - this is supposed to be just a temporary solution, and there is something better in order.
How can Bitcoin network maintain integrity in a imaginary future where it has gained significant traction and there are millions or even more transactions happening every single second?
Actually, it was recently stated by a developer on #bitcoin-dev that it is an issue of the total set of unspent transaction outputs (i.e., what all nodes must maintain in memory), not total blockchain size (which only nodes that need to do complete validation actually need).
Of course, it may be that all the developers are not of one mind on this.
Bitcoin may be finite in number, but it's ultimately infinitely divisible, so it does not matter how many bitcoins are "wasted". Regardless, any property worth tracking in such a scheme is likely worth enough to justify a $0.01 investment in bitcoin.
> Bitcoin may be finite in number, but it's ultimately infinitely divisible, so it does not matter how many bitcoins are "wasted".
Correct.
> Regardless, any property worth tracking in such a scheme is likely worth enough to justify a $0.01 investment in bitcoin.
A doubling of the current price would make transactions of less than 1 US penny impossible. So, if the price goes up 10x, it would be 5 pennies. 100x, 50 cents. 1000x, 5 dollars. So, yeah, it does seem like a non-issue.
However, this policy clearly rules out microtransactions.
The problem is that this minimum transaction size may change in the future. So, lets say you set 10 X MIN_VALUE to equal one stock certificate. If the MIN_VALUE adds a couple zeroes in the future, anyone with less than 10 certificates just lost their property.
Also, maybe you want to allow the user to transfer fractions of your property issue. Stocks can go up 10000x in value and you don't want the issuer to have to perform stock splits. If there is no minimum transaction value, this is easy. With minimum transaction values, the value of a single certificate in bitcoin becomes much more important.
The point is, there are valid reasons to transact small amounts of bitcoin that do not involve micro-transactions. If the user is willing to pay the transaction fee, these should be allowed. The developers are limiting the useful (and profitable) application of the network to fix an issue that can be solved by other means.
It doesn't need to be. But it helps. Imagine if you wanted to create a bunch of smart properties which had very little intrinsic dollar values(lets say, collectible sports cards) - you would be forced to spend a bunch of money to do so.
They are aware of the issue. There is a long discussion of it in the linked pull request comments.
My interpretation is that they do not see this application as important enough to take into account in their updates. This is a perfectly valid stance, and they are the developers doing the work; I just don't agree with it.
The tl;dr: Represent a piece of property, say a stock certificate, as a small value of bitcoin. By transferring the bitcoin to another user, you are transferring the ownership of the property. This can be useful for creating distributed markets where property can be traded for bitcoins without requiring a trusted intermediary.
I don't understand why this is such a big deal for the developers. You see a lot of panic about UTXO bloat. It seems to me this can be solved by making the UTXO cache a bit smarter. If you have a very small value output that has not been used in a while, store it on the harddrive, not in RAM. If the output shows up in a new transaction, you will have a cache miss, but that doesn't seem like a serious issue. If the client is smart property aware, store those dusty-looking outputs in a seperate cache.
This might be an attack vector for DDOS attacks, but that should be solvable by throttling the processing of transactions that miss the cache.
The propogation of transactions that are not in the RAM cache might be a bit longer, but that is the price you pay for making a transaction with dust.