Bitcoin can't handle micropayments. The block chain is limited to about 7 transactions per second, and every node has a full copy of the block chain, so traffic goes up roughly as the square of usage. There's a minimum fee for each transaction (if you want it confirmed in any reasonable length of time) and it's currently about $0.30. That's more than many merchants pay to process a credit card transaction.
Nor can Bitcoin handle fast payments. It takes about an hour to get solid confirmation of a transaction, by which time the price of Bitcoins may have changed substantially. If you're selling anything that actually costs you money, you have to wait for some confirmations. One gambling site tried accepting unconfirmed transactions. People would bet, then, if they lost, double-spend to kill the payment.
A distributed digital currency without these problems is technically possible. That may be the currency that actually becomes useful for micropayments. Meanwhile, Bitcoin for vending machines, music tracks, and parking meters isn't going to happen.
Your statement that Bitcoin cannot handle micropayments is absolutely incorrect. Are you familiar with payment microchannels? With microchannels, Bitcoin solves the micropayment problem like it solves other, related problems: with simple p2p network tech combined with cryptography.
In short, Mike Hearn and others figured out how to exploit Bitcoin's native scripting capabilities to support microtransactions. They call it microchannels, and there's a very succinct explanation here if you're familiar with Bitcoin scripting: http://www.slideshare.net/JohannBarbie/bitcoin-micropayment-...
There's even a working implementation: part of Mike Hearn's BitcoinJ, the second oldest Bitcoin implementation.
Now, you could argue that there's so far no big demand for Bitcoin microtransactions, and I'd have to agree. But to say bitcoin is not capable of them is simply false.
Edit: Also, your per tx fee is too high by at least 10x. In fact, many transactions can be sent at absolutely no charge.
Micropayment channels don't offer the flexibility of plain micropayments. Sure I can get $0.0001 from you a certain number of times, but I have to wait until I have a certain amount paid for it to worth it for me to make a transaction.
Micropayments that aren't channels will be possible when fees are lower.
This is just one of many competing "techniques" for bitcoin microtransactions.
As it stands now there is no universal standard, which is needed before you can say bitcoin is ready for microtransactions. It's a market issue, not a technical one.
This is getting ridiculous. So much patchwork and overcomplications show how unfit for the real world Bitcoin is. Just drop Bitcoin for Stellar and problem solved. But, wait, all that vested interest and money in Bitcoin keeps people stick to Bitcoin and reject anything else.
Patchwork??! This uses the original scripting implementation that Satoshi built. It's just one of many possible applications of it.
New applications are exactly why a (non-Turing complete) scripting language was included in the protocol -- so people could extend the Bitcoin to new areas.
You may not like Bitcoin, but calling the use of a feature that was built by the original developer to support one of the earliest aspired uses of Bitcoin "patchwork" is pretty unfounded.
And regarding Stellar, I'm a big fan of the Ripple technology, but very cautious about the entities behind both Ripple and Stellar. Just like Stellar, Ripple started out with promises of distributing the vast majority of the coins around the world, and yet 2-3 years out this still hasn't happened. The fact is -- unlike Bitcoin's -- Stellar's and Ripple's distribution model is highly centralized and thus potentially undependable.
It's patchwork as doing all this is not intuitive, it needs to be explained, spec'd out, needs examples and requires a learning curve. I'm fine with the entities behind Stellar and totally not fine with the shady, questionable, and faceless ones behind Bitcoin! The only character I cared about within Ripple is now with Stellar - Jed McCaleb. Last thing - the distribution is not Ripple's fault, it's the uselessness of cryptos for the 99% of the population, which is leading the imminent crash and burn across the board!
Ripple/Stellar is even more of a patchwork than Bitcoin. At least Bitcoin was created by a cohort of folks well-versed in the computer science of consensus and has some rigor behind it, Ripple is just a hacked up scheme with a (flawed) "whitepaper" as marketing. Same with Stealar unless David Mazieres makes some significant changes to it.
Joyce from Stellar here. Prof. David Mazieres is creating a new provably-correct version of the consensus system and will be publishing a white paper that will be in line with his normal, rigorous academic standards.
In addition, Graydon Hoare (creator of Rust) has also joined the Stellar team from Mozilla. Now that Stellar supports over 2.3 million wallets, making it the largest implementation of this system, we have found certain scaling limitations of the core tech. Graydon is one of the developers spearheading efforts to make Stellar capable of scaling well beyond its current limitations.
Once these two efforts are complete in a few months, I think you will feel much more comfortable with the robustness of the Stellar protocol.
In short, the payer sends a signed transaction to the payee every time they want to increment the payment, but the payer does not broadcast the transaction to the network until they want to finalize it. To prevent double-spending, the payer and payee first set up a 2-of-2 multisig, so all transactions must be signed by both parties.
This lets applications send many instant micropayments, and only one transaction fee is paid.
That does not increase the number of independent transactions that can take place. You can't have multiple recipients: "this does not allow you to send micropayments at high speed to different recipients" And you can't have multiple senders. You just get to do incremental transfers.
In the end bitcoin needs to handle around 1,000 independent transactions a second to see widespread adoption and even 100,000 transactions a second is low for some use cases. NYSE for example peaks well above that.
Today. Yes, today that's the limitation. But don't confuse the current stage of development for the future product. When twitter launched it couldn't handle much, today it's got phone-network level stability. Bitcoin will get there too; and faster than you think.
You can chain microtransactions atomically, so with a star graph of payment channels you can route micropayments through a central processor without introducing trust - taking the number of channels from O(N^2) to O(N) in the number of participants. I imagine a dynamic network of payment processing addresses could be chained in the same way, in order to provide a verified path between two participants using different channel operators.
Multiple recipients are already a feature of the blockchain (one input multiple outputs) and you can make each of those payments as small as you like, just so long as the rolled up transaction is over a given amount.
BTW, this does not require the rapidly adjusted transaction technique.
An example of a company working on this issue is monetas.net, which has announced launch for December. Their solution is based on OpenTransactions, which adds a layer on top of Bitcoin (or any other payment system) that allows to perform much smaller and cheaper transactions.
Chaum ecash is one way to solve it. You'd use chaum ecash tokens backed by bitcoin by an issuer. You would then use the tokens, since they are instant, have no transaction cost and can be anonymous. The ecash tokens themselves require a central issuer that is trustable to avoid double spending, which is it's central issue with it. To side step the trust issue, the issuers would be a large multi sig bitcoin pool. The two technologies compliment each other. Bitcoin creates a purely virtual good that has scarcity and solves the trust issue. Chaum ecash solves the cost, speed and anonymity issue for bitcoin.
Bitcoin will become something like the international wire transfer mechanism.
One implementation of chaum ecash is open-transactions, i suggest you check it out: http://opentransactions.org
It's like you went out of your way and collected every incorrect piece of knowledge about bitcoin.
> Bitcoin can't handle micropayments
It already does.
> The block chain is limited to about 7 transactions per second
No, it doesn't. That limitation is completely artificial and can be removed at any time. The core developers are working on scaling the system to 1000+ tps.
> and it's currently about $0.30. That's more than many merchants pay to process a credit card transaction.
No, it isn't more. And it's $0.03, not $0.30. Have you looked at the actual credit card fees? They consist of a percentage + fixed fee per transaction + fixed monthly fee.
> Nor can Bitcoin handle fast payments. It takes about an hour to get solid confirmation of a transaction
The transaction takes a few seconds. One confirmation takes around 8-9 minutes on average (we always mine faster than the 10 minute goal).
Compare it to a bank - transaction takes days, confirmation takes 6+ months.
Compare it to a credit card - transaction takes a few seconds, confirmation takes 180 days.
> * you're selling anything that actually costs you money, you have to wait for some confirmations*
Same with credit cards and bank transfers. Except these kinds of payments can be reversed for 6+ months, and it's a big headache for the merchants and stores.
Bitcoin's blockchain can't handle micropayments, but blockchain is ideal for insurance deposits making micropayments as a separate protocol "economically" secure (no one wants to lose their deposit).
Two use cases:
1. Micropayment channels. When you pay to a single party in frequent small chunks, you can create a transaction that locks up certain amount upfront and than you simply re-sign that transaction moving more coins to the recipient and less back to you ("change"). Recipient does not publish transaction until the session is done. If you disconnect or they decide to stop providing you with a service, they simply release a transaction with the latest balance of payment and change.
2. Micropayment channel is not always relevant. E.g. you want to make a one-time small payment. E.g. buy a drink in a cafe for $2. We can imagine another micropayment protocol similar to Ripple where IOUs are transferred, but unlike Ripple, each IOU is ensured by at least twice the amount of real bitcoins locked up in 2-of-2 multisig transaction by each pair of nodes that exchange IOUs. In other words, it's a Visa-like clearing house, but it's decentralized (mesh-like) and every penny of debt is fully insured by real bitcoins being held hostage in "joint escrow" transaction (2-of-2 multisig).
That is an inaccurate statement. Technically speaking, sending small amounts of Bitcoin from one source address to one or more destination addresses in separate transactions are inefficient, given the default size of the transaction(s) and the cost of processing. Depending on your use cases, there are solutions to this apparent limitation.
To handle one-to-one micropayments, Bitcoin microtransactions can be done in a trustworthy manner by using rapidly adjusted payments between parties[1]. Basically, funds are held in escrow and the amount owed is adjusted in a variable off-chain transaction until either a) the funds are exhausted, b) the parties decide they are done, or c) a timer expires.
Second, Bitcoin allows for making one-to-many payments in a single transaction[2]. You could send sub pennies (US$) amount of value to 1,000s of addresses in a single transaction. The cost of the transaction goes up as the size of the transaction goes up (more addresses == bigger transaction), but it remains a very economical way to send very small amounts to lots of addresses.
I'm using the latter of the two methods to send coin to virtual appliances controlling OpenStack cluster based instances, which would have an analogy of feeding parking meters in the physical world. You need to trust the payment party (entity paying for all the instances/parking spots in a single transaction), so the plan is to make the payment mechanism distributed by deploying multiple payment nodes onto the network. Payment nodes deposit pennies into instances/parking meters periodically from wallets they create and control themselves. If someone hacks a single payment node's guest machine, and steals its private key, they'd only score a few bucks. Not worth the time or effort of hacking the hypervisor, in theory.
An interesting side note here, payment nodes could also be aware of their own Bitcoin instance payment address, effectively allowing them to use a wallet they are carrying to pay for their own existence.
1. Transaction times are long (6 blocks to confirm)
2. Transaction Fees of 0.0001 BTC could likely incur for transactions smaller than 0.01 BTC. This is about a $0.03 USD transaction fee for transactions under $3.30.
My solution to these limitations is to trade BTC on a distributed, low-transaction fee, fast confirming exchange.
That is why today I launched a BTC to Stellar gateway for my p2p microlending startup at https://onecred.com
I expect to see a lot of things people never imagined were possible once bitcoin's store of value combines with a distributed exchange that is good at the things that consumers need (speed, low fees, security, decentralization).
> Bitcoin can't handle micropayments. The block chain is limited to about 7 transactions per second,
Note that this is not a technical limit, it is an arbitrarily set parameter. Gavin argues it could be increased at least 1000-fold with more professional infrastructure over time. Even with a tenfold increase, an average PC with mediocre broadband could still process every transaction ever. I'm confident that as soon as the need arises, this limit will be increased.
> and every node has a full copy of the block chain, so traffic goes up roughly as the square of usage.
That's not true, traffic goes up linearly with the number of transactions. If there are twice as many transactions, twice as much data needs to be sent around in the network. It is also linear in the number of full nodes running - but most users do not run a full node.
> There's a minimum fee for each transaction (if you want it confirmed in any reasonable length of time) and it's currently about $0.30. That's more than many merchants pay to process a credit card transaction.
Wrong again. At the moment, the recommended minimum fee is 0.03 USD, or 0 for high-priority transactions (those who move large amounts or old coins). It used to be 0.001 BTC, but that was reduced to 0.0001 BTC. Also, most merchants have to pay much more than 0.30 USD to process credit card payments.
> Nor can Bitcoin handle fast payments.
Firstly, when looking at throughput (how many times can the same Bitcoin be spent per day), Bitcoin beats all existing payment systems by a wide margin. Even with SEPA, which is praised to be very fast, you can resend the same euro to a new account at most once per business-day or about 20 times per month. A Bitcoin, however, can be moved thousands of times per day (assuming movements between trusted parties) or dozens of times per day between untrusted parties. So regarding throughput, Bitcoin is the clear winner.
Secondly, there is the time it takes until the money arrives with certainty. For credit card transactions, that time is 60 days. For bank transfers, settlement is T+2 days. That means if you send 100 USD from a Lehman brothers account to a BofA account on Monday, and Lehman goes bankrupt on Wednesday, you won't receive anything. With Bitcoin, it takes about an hour to reach that level of certainty.
The problem you are referring to is that by colluding with a miner, someone could issue a competing second transaction that invalidates the first. Fortunately, such attacks require effort and are perfectly detectable. So if not much is at stake, one can accept a transaction as soon as it has spread to the relevant miners. For example, when you order a coffee in a restaurant, it is much easier to simply walk out without paying than to try to launch such an attack.
> Meanwhile, Bitcoin for vending machines, music tracks, and parking meters isn't going to happen.
Exactly for those applications, it is safe enough. None of them is 100% safe anyway: vending machines can be fed with fake coins, music tracks can be pirated, and parking meters can be ignored (betting that the police won't check them). In all those cases the effort to cheat with traditional means is smaller than that of colluding with a majority of miners (and you need a majority for a reasonable rate of success).
> I'm confident that as soon as the need arises, this limit will be increased.
Why hasn't the need arised yet? People have been saying this since the limit was introduced, and it hasn't changed.
> Wrong again. At the moment, the recommended minimum fee is 0.03 USD, or 0 for high-priority transactions (those who move large amounts or old coins).
This is before the next halving. Right now, miners get 25BTC for completing a successful block. Satoshi expected that at the time this became halved, fees to the miners would take over. So sending 0.01BTC wouldn't make sense since they'd need 12.5BTC in fees to make it profitable.
> That's not true, traffic goes up linearly with the number of transactions. If there are twice as many transactions, twice as much data needs to be sent around in the network. It is also linear in the number of full nodes running - but most users do not run a full node.
How does that make sense in a peer to peer environment?
These things are solved in other cryptocurrencies like Ethereum. You can also take a look at "25-second irreversible confirmations for instant payments" [1].
Before Bitcoin was a thing, I was thinking about the Erlang VM's "reduction-counting" processing paradigm, and noticed that it was a lot like having a dom0-scheduler "treasury" with domU-process "citizens", where each citizen gets paid a basic income every scheduling interval, and then can spend it to "purchase" time-spent-aware on a virtual core.
In Erlang's model, processes lose whatever they don't spend in a given interval—this is necessary to prevent a process from "saving up" and then blocking the VM for seconds at a time. However, if rather than putting a cap on wealth, you just cap spending per interval, then processes could do lots of other clever things with their income: trade it, invest it, spawn subagents that consume it, etc. This would be a very interesting platform for running goal-directed AI agents on: somewhere between Core Wars and Heroku.
Now, if the only "ledger" of reductions was in the local dom0, you'd have nothing more than a toy server: a sort of fishtank for agents to interact within. But throw a blockchain at the problem, and now agents could pay to spawn sub-agents (or copy themselves) anywhere that'll take their dom0's currency.
Interestingly, since cryptocoins are all pretty fungible, this would imply that the "intelligence" of an AI—or of a hypothetical Hansonian brain-emulation, for that matter—could be measured in units of dollars-spent-per-second.
Cool idea, the only problem I can see is how you define a reduction. In the Erlang VM a reduction is kind of a magical unit... and not a reductions are created equal.
I think the definition of a reduction (in terms of what it buys) is allowed to be pretty much arbitrary while still having an effective distributed economy emerge on top of it. Think of it as a communist state that both issues currency, and sets arbitrary prices for all state-produced goods in terms of that currency. In one state, a loaf of bread (or a multiplication) might be worth $1, and a hamburger (or a network message send) $5; in another state, the costs might be reversed. This would shake out as
1. exchange rate nash-equilibria between dom0s, determined by their "monetary policies";
and 2. spawning of subagents on dom0s with better cost-structures for the particular tasks they're assigned to accomplish. (If you're doing a lot of network IO, you'd want to delegate that part of your job to a place where network IO—after currency-conversion—is cheap.)
I think this is a great post. I do wish it covered some of the other Bitcoin 2.0 concepts since it can do more then just efficiently moving small amounts of value around. Many think that concepts like smart contracts and fractual ownership (e.g. Reddit's recent announcement) require new altcoins, metacoins, or ethereum but don't realize Bitcoin can natively supports them too. There are already open source colored coin [1] APIs that allow anyone to model ownership of anything on the Bitcoin Blockchain, without any intermediary currency.
The real wonder is why haven't any of the major players in these areas adopted it in any way. Curiously it is the payment provider industry who has paid it some attention, rather than any of these.
Perhaps the traceable nature of bitcoin makes it unappealing for these use cases. In the early days of bitcoin where it was relatively easy to get anonymous bitcoins (by paying cash through unscrupulous dealers not paying attention to KYC rules), these would have made great use cases for bitcoin.
Now however, I feel like bitcoin doesn't provide relative anonymity over more traditional methods of payment.
I think there could still be a case for a new mail-like protocol that combines email and cryptocurrency for an email system which is both encrypted by default but also everyone sets a payment level for mail to reach them.
So I say "My Address is <bitcoin address? mail address?>, pay at least 0.001 bitcoins to get mail through".
This system:
*Puts a direct cost on spam (therefore massively reducing it)
*ensures everyone owns private keys (so mail can be encrypted simply by knowing their address)
I'm always wary of email/spam solutions that require 'payment' of some form. See https://craphound.com/spamsolutions.txt for a lot of reasons (in particular, Unpopularity of weird new taxes, Public reluctance to accept weird new forms of money, Ideas similar to yours are easy to come up with, yet none have ever
been shown practical, Countermeasures must work if phased in gradually, Sending email should be free)
It's convenient sometimes that sending email is free, but remember the fascinating read about the gmail anti-spam measures, and how they require central knowledge?
I'd bet you can satisfy 99.9% of my antispam needs with 2 rules:
1 - if I've ever sent an email to your address and haven't blacklisted you, you get to my inbox
2 - everyone else, pay 2-3 cents
Note that mailing lists, via an email opt-in, would pass under rule 1. As for everyone else, if emailing addresses that have never conversed with you isn't worth a couple pennies, rethink sending the email.
No, the idea is that users would be able to set an incoming fee per email address, including a default fee for unknowns. Users would simply whitelist email subscriptions at 0 fee. In fact, this could likely be done completely automatically beyond the initial setup (and then only if you want to diverse from the defaults).
That seems pretty promising. I'm wondering if this project might try going into currency as the landscape evolves, As i think it would be great to see centralized exchanges made irrelevant and the network more resilient, though i suspect it might be a bit harder to solve than physical goods.
How about a browser plugin that lets you pay a few cents here and there to hide ads? You could whitelist the sites you care about (no need to pay off every random blog), and give them a sort of "budget" (unknown to the site). Then each time you view a page on cnn.com or whatever, your browser could toss a few Satoshis over to them in exchange for receiving a page with ads completely removed.
Sort of like the NY Times paywall we all know and love/hate, but easier to deploy for less gigantic sites with less staff, and more voluntary (users who don't pay would just see ads as they do now).
Out of these 4 categories, marketplaces is the one that I think has the most potential for a breakaway change.
Micro-payments, micro-incentives and any kind of a scaling down of transactions is something I'm not exactly sure about. Maybe there's some cool stuff here, but I would be surprised.
Marketplaces though are a different story. Marketplaces have been developing into giants since the internet began and the financial infrastructure for running them is terrible.
Ecommerce, native or not, will also be impacted. Anti-fraud & payment verification colour the world of ecommerce enough. Solving friendly fraud (mostly chargebacks) could enable a lot of otherwise transactions and serve underserved markets (EG shipping goods to high risk countries like most of Africa).
ATM though BTC is still in a shaky place. Even bitcoin owners don't use it much. Most people don't have bitcoin wallets so unless a service is important enough to make people use it, BTC cannot be the only option.
Marketplaces are the kind of thing where users can be forced to use the payment method available. EG, if Uber paid driver in BTC, drivers would accept BTC.
what you said and decentralized marketplace could emerge with bitcoin, where marketplace works like a blockchain explorer. Craigslist + bitcoin = Alibaba
Item 2, allocating resources for a true mesh network is a cool idea. It's clean, a b2b transaction for a specific standardized service: forwarding or storing data. It does not sound like a legal minefield. Am I too optimistic? Hats off to cdixon.
The other four I don't understand, can someone help me out?
There is no technical reason that existing money transfers get delayed or expensive because of international borders. The issues are regulatory [1]. How does bitcoin solve that? Same with payments and micropayments. There's nothing technically difficult about moving small or large amounts of money between people. Compliance with regulation is where all the trouble comes in [1], and Bitcoin is not miraculously exempt from those regulations either.
Am I missing something? I'm really curious. Like most technology folks, I /want/ to be more excited about bitcoin.
> Incentivized social software. Up until now, social sites have had to rely on non-monetary currencies such as likes, followers, karma, upvotes, etc. With Bitcoin we can add actual monetary incentives to the mix. This is happening organically on Reddit where users are tipping each other using Bitcoin and Dogecoin.
Incidentally, this is a pretty bad idea, because of how the way people think about things changes when money gets involved. Someone said it well in a recent thread, so I'll defer to them -
(AFAIK, most Reddit tips are only for a few cents, so the only real value is the acknowledgement that someone appreciated your post enough to tip you. This sidesteps the issue, but means that it isn't a good reflection of what would happen if you tried to make a real incentivized social network.)
Club Med used to solve the problem with beads. Vacationers would use beads to buy beer or whatever while there. At the end of the stay they add up the beads that you used and give you a bill. It is pretty effective at making you not think it is money.
Bitcoin has lost some value recently, yes, but what it's bought with that loss is increased merchant adoption. Currently merchants instantly sell bitcoin which causes the downwards pressure on the price you've been seeing. However, as the utility continues to grow this trend will very likely reverse.
I think there is huge opportunity in decentralising existing business models that are well suitable for p2p.
Think of Uber / AirBNB / etc with no fees and no government power over them.
Another huge opportunity in distributing revenue of these services to peers running the network. This may cause rapid growth & unparalleled fault tolerance.
Third thing that might be disrupting is ability of such services to issue their own coins/stocks, which price is linked to service's revenue. Revenue is then distributed among stock owners, and service can issue such stocks at will without government's approval.
This list is pretty good but I suspect infrastructure work is far from done. Also Marketplaces aren't quite native by this definition-- cdixon is more so pointing out that their reaches can be expanded to the unbanked. I think the real magic of Bitcoin lies in the Blockchain itself and its application to the real world via smart contracts. The fact that bitcoin is a currency might turn out to have been a big distraction or just a side effect of the real applications. If this is true it further points to the need for ubiquitous infrastructure.
If you're referring to the recent price drop - you should learn about what causes price fluctuation in Bitcoin. It's actually largely due to the fact that Bitcoin is actually rapidly becoming USED rather than HELD which causes downward pressure on it. This causes miners to become un-profitable btw which will eventually cause upward pressure on the price (but that problem is worrying as it's getting really expensive to produce BTC - just a side note).
But while the price dropping is somewhat concerning, it is extraordinarily clear to anyone paying attention that BTC and crypto generally is growing in utility rapidly.
For context: I'm a fairly neutral observer who does not own Bitcoin. I do have USD on the Ripple ledger.
Why would unprofitable mining cause a upward pressure on price? There is a fixed amount of bitcoin distributed per day cumulatively to all miners regardless of their number.
I doubt the recent price drop is due to people buying and selling in bitcoin since it's way too steep a decline.
I'm guessing that most miners themselves also happen to be investors as well. After all, if you believe in bitcoin enough to purchase equipment to mine it, you must also believe that the price will at least stay constant or rise. So it seems natural to keep some of your profits in bitcoin.
So people mining and investing together are heavily dependent on price, more than those doing one or the other. With the constant slow decline, it left a lot of miners languishing, and they not only need to convert all their current profits to their local currency to pay the bills, but their bitcoin investments as well. This creates a feedback loop and an ever increasing rate of price decline until enough miners run out of bitcoin to sell and/or close up shop.
:-) Well said. I read this after I posted elsewhere on this thread about how the price drop is caused by adoption so in fact we are buying _utility_ with the value that we lost. Once we've bought enough utility the price trend will likely reverse.
I do own bitcoin, and I buy lots of stuff with it all the time. I can't recommend it enough.
Nor can Bitcoin handle fast payments. It takes about an hour to get solid confirmation of a transaction, by which time the price of Bitcoins may have changed substantially. If you're selling anything that actually costs you money, you have to wait for some confirmations. One gambling site tried accepting unconfirmed transactions. People would bet, then, if they lost, double-spend to kill the payment.
A distributed digital currency without these problems is technically possible. That may be the currency that actually becomes useful for micropayments. Meanwhile, Bitcoin for vending machines, music tracks, and parking meters isn't going to happen.