Some ideas for native Bitcoin apps
cdixon.org
cdixon.org
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.
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
https://bitcoinj.github.io/working-with-micropayments
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.
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.
The above is subject to malleability-resistant payment channels, which will require a patch like Peter Todd's CHECKLOCKTIMEVERIFY (https://github.com/petertodd/bips/blob/checklocktimeverify/b...)
BTW, this does not require the rapidly adjusted transaction technique.
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.
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.
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.
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.
Micropayments that aren't channels will be possible when fees are lower.
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).
How does that make sense in a peer to peer environment?
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.
The reward will be halved in two years ( http://bitcoinclock.com/ )
> 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.
http://credit-card-processing.findthebest.com/
> 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.
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).
[1] http://bitslog.wordpress.com/2014/02/17/5-sec-block-interval...
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] https://en.bitcoin.it/wiki/Contracts#Example_7:_Rapidly-adju...
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.
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.)
(disclosure, helped create this ^)
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)
Sadly it won't happen, mail is too entrenched.
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.
But it wouldn't need to be seen as a "tax" if the money went to the recipient of the email, and any prices were set by those recipients.
What does that mean?
This is a rapidly developing example of an application that couldn't exist without Bitcoin.
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).
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.
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.
[1] https://www.wepay.com/api/payments-101/payment-regulation-ch...
To the extent people are interested, we'd really appreciate any feedback.
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 -
https://news.ycombinator.com/item?id=8392883
(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.)
My bill was over $600 for 2 weeks :(
Two compelling blog posts by two Bitcoin thought leaders at the same time. Multiple discovery at its best
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.
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.
I do own bitcoin, and I buy lots of stuff with it all the time. I can't recommend it enough.
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.
It may be too simple though, since the amount donated in laughably low compared to the work done by the nodes.
Torcoin and similar solutions may be a better solution due to that issue.
- Open source and Kickstarter like projects funding
- App/Startup Coins
- Virtual Goods
- Silk Roads