Ok, but seriously how will I pay for my $250 grocery bill with bitcoin?

[AmDD]

What about merchants just accepting the risk? They do that now with cash, check and credit cards. People print and use counterfeit money everyday, people write bad checks and use stolen credit cards. The thing is not everyone does this. The few bad transactions that will happen are just part of the risk of having a business. Granted eliminating that risk would be great but how much effort is it worth?

[piotr_n]

What about merchants just accepting the risk? They do that now with cash, check and credit cards.

How do they accept the risk of double spending with cash? There is no such risk.

The idea is to make bitcoin payments equally reliable/irreversible, for the payees, as the cash payments are.
If they get to "accept the risk", they can just as well put the bill on you tab and let you pay it from your desktop after you get home.

[capsqrl]

I don't think off-blockchain is the answer. This completely undermines and defeats the purpose of the block chain being an open ledger. You might as well be another Paypal. The reasons invoked for off-block chain transactions are that the merchants’ volume is too high for the block chain, that the fees are too high or that confirmation time is too long. For every single of those problems there are known solutions that aren’t detrimental to the block chain ecosystem.

I think the "another Paypal" solution is exactly what you want here.

Yes, for all the reasons you state. But I think there could be a network of interoperable "another PayPals" with legal relationships between eachother, each performing off-chain transactions for users of any operator in this network, and periodically settling between each other on the blockchain. Each user would sign up for service on their operator of choice, and keep a relatively small spending balance. There would be a standard protocol for payments and settlements that anyone could implement, and merchants wouldn't have to support any particular operator such as CoinBase.

This would be for harmless, non-controversial, everyday humdrum use-cases like buying groceries or cups of coffee. People can yell all they want about this violating the sacred intention of the blockchain as a public ledger, but in fact every cup of coffee ever consumed does not need representation on the blockchain. The blockchain is still there for anyone who is unable or unwilling to use the off-chain network (think controversial or illegal transactions, long-term or high-volume storage, privacy).

[murraypaul]

I don't think off-blockchain is the answer. This completely undermines and defeats the purpose of the block chain being an open ledger. You might as well be another Paypal. The reasons invoked for off-block chain transactions are that the merchants’ volume is too high for the block chain, that the fees are too high or that confirmation time is too long. For every single of those problems there are known solutions that aren’t detrimental to the block chain ecosystem.

I think the "another Paypal" solution is exactly what you want here.

Yes, for all the reasons you state. But I think there could be a network of interoperable "another PayPals" with legal relationships between eachother, each performing off-chain transactions for users of any operator in this network, and periodically settling between each other on the blockchain. Each user would sign up for service on their operator of choice, and keep a relatively small spending balance.

We could call them ... banks.

[capsqrl]

We could call them ... banks.

We could call them aeroplanes for all I care; they're useful and don't negate any advantage of Bitcoin for anyone who don't want to use them. In fact they could facilitate more private transactions since they're not expressed on a public ledger, while allowing Bitcoin to scale.

[cypherblock]

On-chain solutions like greenaddress.it's 2-of-2 signing allow 0-conf transactions, provided the merchant trusts ga.it not to double-spend.

I think you are right about this. So if I understand correctly it can work as follows:

First, before I go shopping,  I send some bitcoins to a 2 of 2 multisig address between me and some 3rd party service. TX1

After that transaction is confirmed (standard 6 or more blocks deep in the chain), any merchant that also trusts that 3rd party service not to double spend can receive "instant payments". As follows:

I show up at merchant store (or website), I buy stuff and for payment: I send a message to the 3rd party service with my signature for TX1 and ask them to sign it and send payment to the merchants public address (that they've provided me). This could be done either through my wallet or the merchants wallet/pos but it is done 'offline' in the sense that this message is not sent to the bitcoin network yet since it needs the 3rd party signature.

3rd party service checks their own system to make sure that they've received no previous attempt to spend TX1 and then creates a transaction spending TX1 (TX2) by adding the second signature needed.

Merchant can get sent a copy of TX2 and does not really even have to wait for one block confirmation. They trust 3rd party and know that 3rd party will not double spend.

I think this how greenaddress.it is doing it? Yes.? They also use the nLockTime parameter, so that TX1 will 'expire' after some time so that I can get my coins back if 3rd party goes bankrupt or doesn't release payments when requested, but I haven't got my head around that part yet (as haven't looked into nLockTime yet).

[instagibbs]

I think this how greenaddress.it is doing it? Yes.? They also use the nLockTime parameter, so that TX1 will 'expire' after some time so that I can get my coins back if 3rd party goes bankrupt or doesn't release payments when requested, but I haven't got my head around that part yet (as haven't looked into nLockTime yet).

They send the change to a new multisig address, and send you a new refund txn that you can't spend for "90 days" or something(1440 blocks? It says in the app). So if ga.it disappears tomorrow, you have to wait a bit to get your money back, but they can't run away with it.

The normal workflow is exactly the same as regular wallets that have 2FA. It's just that their servers sign the txn when you respond to the 2FA challenge.

FWIW, it's the only wallet I'm using these days, outside of paper wallets. Great for my spending money. They are rolling out 0-conf stuff as we speak, which uses the payment protocol.

[piotr_n]

Yes, for all the reasons you state. But I think there could be a network of interoperable "another PayPals" with legal relationships between eachother, each performing off-chain transactions for users of any operator in this network, and periodically settling between each other on the blockchain.

Certainly, there should be a competition, but I would not go into banking kind of infrastructure, because then when one of them runs away with money, the entire system collapses. Just like the one we are now seeing collapsing

So I rather see it like some common "bitcoin paypal API", that would allow a merchant to hook to a new instant payment provider with no much effort.

So:
* Being a merchant, to accept payment from a new "bitcoin paypal provider", you just need to create a merchant account there and add it to your billing system (POS).
* While being a payer, you need to create a customer account at a "bitcoin paypal provider" of your choice and deposit some bitcoins there.

Mind that each of these providers would give you a different kind of security/anonymity/fees/etc.
For instance: some of them can even credit your payments, though definitely not those which did not check your ID.
And that is great - because you have a choice.
That is pure market and that is how it should work.

Of course the payment providers/processors/insurers (aka "bitcoin paypals") can come out with a system allowing off-chain transactions between them.
But that would not be a requirement and such systems would rather be transparent for the users, and the merchants.
As long as the balance on our account is correct, we don't really care about how the corporations settle their balances between each other; on- or off-chain.

[capsqrl]

So I rather see it like some common "bitcoin paypal API", that would allow a merchant to hook to a new instant payment provider with no much effort.

You make a good point, and I certainly don't want to see the necessity for bail-out funds etc when one node in the settlement network goes under. I like your alternative, and it's probably more realistic, but I'm afraid it would create a much smaller ecosystem, perhaps tending towards a duopoly or worse, like one "Visa" and one "Mastercard". I want a rich ecosystem of actors competing against each other on fees, security, features etc.

[piotr_n]

So I rather see it like some common "bitcoin paypal API", that would allow a merchant to hook to a new instant payment provider with no much effort.

You make a good point, and I certainly don't want to see the necessity for bail-out funds etc when one node in the settlement network goes under. I like your alternative, and it's probably more realistic, but I'm afraid it would create a much smaller ecosystem, perhaps tending towards a duopoly or worse, like one "Visa" and one "Mastercard". I want a rich ecosystem of actors competing against each other on fees, security, features etc.

That is why you want each of these paypals to provide you with different kind of services - that is going to make the difference.

Not everyone needs a Tor level anonymity and a highly secured con mixers - but some do and they will be willing to pay for it.
Such kind of providers might not be accepted by all kind of merchants, but can still use the same API.

At the other hand, if you provide a bitcoin paypal with your photo ID and a credit history - they may like to build their business model not as much on transaction fees, as maybe on crediting your payments, assuming you'd want to borrow some coins from them at the interest.

BTW, both of the above mentioned business models are evil for some people.
The first one feeds on a money laundering - the second on usury...
But none of them is evil for me, especially when people have the choice between them.
Not to mention that there would always be business models in between.
Still there is no reason why the API could not be common for all of them.

[ajareselde]

Simply, coinbase should be the third parity escrow like service.
You would be confirmed in the same amount it takes you to put in your PIN for CC.
also,did you ever buy something using bitpay ? it is confirmed in no-time

[joshraban76]

I thought about something, maybe printing GC like voucher and stated on it the BTC price along with it's corresponding USD.

Or printing a voucher by $300 for example, and the remaining will be sent to you automatically to your wallet.

[Lethn]

https://coinkite.com/

[cypherblock]

On-chain solutions like greenaddress.it's 2-of-2 signing allow 0-conf transactions, provided the merchant trusts ga.it not to double-spend.

What about the concept of detecting double spends in bitcoin nodes and notifying merchant? This has been proposed before, and was just having discussion with someone from Bitsimple on this (they suggested it). They were saying you as a merchant or more likely a service the merchant is using, can deploy a bunch of nodes across the globe (not a huge number, but maybe 10-50). Merchant get's your transaction and does wait like 10 seconds, but no more. If any of the service's nodes see a second transaction trying to spend the same bitcoins, it notifies the merchant POS/wallet system. If no second transaction is seen in 10 seconds it is considered 'safe'.

This could eliminate the need for the buyer to use a 3rd party like greenaddress.it and only the merchant would have to use a service that offered this protection.

[nwfella]

Well , I see an inputs.io lookalike as the best solution.
It permeated almost all the Bitcoin websites and it had off-chain transactions.

But the problem is , the inputs.io scare has put everyone off the idea for a loooong time.

Your idea is interesting , but on-chain transactions can not happen under 10 minutes.

I cringe everytime I so much as see the name inputs.io or tradefortress or infested_with_bugs or whatever the hell his name is now.  But yes, something that could have that much market penetration but 100% decentralized in it's design.

You put enough power into the hands of any one single individual and unless that person is Ghandi, or Mother Theresa or something they will more than likely eventually succumb to greed.

[coastermonger]

So really, how do brick and mortar merchants accept bitcoin payments in 1 second or less without risking double spending? Do we actually have a solution for that which doesn't require me (and merchant) to use a proprietary bitcoin app but let's me use a generic wallet app?

I wouldn't be surprised, but haven't checked, if Coinbase or somebody has a solution for this, but I'm guessing it requires both merchant and customer to be using Coinbase.

I guess if the larger bitcoin firms like Bitpay, Coinbase, etc provide guarantees to merchants that the transaction will be confirmed and they take the risk of fraud (double spending attacks) then that is certainly one solution.  They can quickly (1 second?) do a check to make sure transactions look ok (based on current blockchain) and hope that double spending attacks will be rare.

Coinbase and eGifter facilitate your ability to purchase groceries quite nicely.  Coinbase is a place that lets people easily acquire BTC, and eGifter is working to let people spend it basically anywhere, even in places where the merchants don't know about BTC.  Let's assume you have the eGifter app and a Coinbase account, and need to buy $200 worth of groceries.

1.) Shop for some food at Walmart.
2.) You can buy a walmart giftcard straight from the eGifter App using bitcoin.
3.) Egifter gives you a whopping 6% discount, which means you paid $188 for your $200 Walmart Giftcard.  (why can they do this? Because BTC doesn't charge back)

[Gianluca95]

Use BitPay to make your transaction with any problem and then pay grocery bill !

[cypherblock]

Coinbase and eGifter facilitate your ability to purchase groceries quite nicely. 

So you didn't really address the questions about 1 second checkouts that are guaranteed or safe. But you did successfully promote those 2 services if that was your intent.

[luckypyrate]

It seems to me that, while your question is valid, it is no different than real world situations now where people are using checks and such for transactions.  I mean really only just now are grocery stores doing realtime verification of funds with checks.  Not to mention if the credit card network or the sites internet goes down, a lot of these retailers have their CC machines set to batch automatically until a connection is restored in order to maintain continuity of business.  A couple of crooks got off well, albeit briefly, with this little secret by putting tin foil on the satellite receivers and then buying up gift cards in the store and then removing the foil once they left.  They made off with upwards of $300 a store and none-the-wiser until several weeks later. 

My point is these fears have existed throughout commerce history, and it really just comes down to a level of expectation of honor and also a little bit of insurance against such attacks.  I think the eBay model of financial ostracism for suspicious or fraudulent buyers/sellers works really well for them and on a larger scale could work really well in a bitcoin aware world. 

Just some thoughts...

[Brangdon]

What about the concept of detecting double spends in bitcoin nodes and notifying merchant? This has been proposed before, and was just having discussion with someone from Bitsimple on this (they suggested it). They were saying you as a merchant or more likely a service the merchant is using, can deploy a bunch of nodes across the globe (not a huge number, but maybe 10-50). Merchant get's your transaction and does wait like 10 seconds, but no more. If any of the service's nodes see a second transaction trying to spend the same bitcoins, it notifies the merchant POS/wallet system. If no second transaction is seen in 10 seconds it is considered 'safe'.

It would help further if nodes that detected double-spends either relayed them, or, better, relayed an alert that a double-spend was being attempted.