Pages:
Author

Topic: Ok, but seriously how will I pay for my $250 grocery bill with bitcoin? (Read 3023 times)

donator
Activity: 668
Merit: 500
When I were a lad, the question was "But seriously, how will I pay for my $25 grocery bill with bitcoin?"
sr. member
Activity: 365
Merit: 251
3 - Per outer quote above, the network should relay, and not drop, double-spends.  This makes #2 above much more effective.  The actual double-spend transaction is the best alert, because it is signed by the person double-spending.  Anything else would require a trusted 3rd party.
As long as the double-spend is relayed in a way that no-one will confuse with a single-spend. They shouldn't be relayed as a normal transaction.

Possibly the alert should embed both transactions. That makes it a neat, clear-cut proof of attempted fraud in a single message. Then again, normally the alert is being sent to the same nodes that the original transaction was relayed to, so perhaps that's not necessary.

no, this is to easy to use for spamming the network with transactions.
Only the first double-spend needs to be relayed; subsequent ones can be dropped because a single double-spend transaction is enough to establish that a double-spend attempt is in progress and alert the merchant. So spamming is limited.

If you want to limit it more, only relay/alert double spends if the amount is, say, at least triple the current dust level. So a spammer can either send a million transactions with 5431 satoshi each, or 333,333 with 16293 satoshi each plus 333,333 "free" double-spends alerts. The cost to the spammer is the same, as is the bandwidth cost to the network. (And the double-spends don't get added to the block-chain so we gain there.) In practice, 16293 satoshi is small enough that thieves aren't going to bother trying to double-spend it, and most merchants can accept the risk that they will.

(We can juggle the numbers depending on the actual cost of the alert, and whatever the dust level is nowadays, but you get the idea.)
sr. member
Activity: 406
Merit: 251
http://altoidnerd.com
What about just prepaying BTC for later use?  I do this all the time on e.g. namecheap.  I'll spend the credit eventually, I don't really mind.  I understand the merchant's needs.
sr. member
Activity: 266
Merit: 250
What about the concept of detecting double spends in bitcoin nodes and notifying merchant? ... 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.

Good questions.  Everyone sees that the decentralized bitcoin system can't have complete, immediate protection from the effects of 0-conf double-spends, but that is totally different from saying that the situation cannot be improved immensely.  Some improvements that can be made are:

1 - Agree that 0-conf double spends should be made more difficult, not easier (there are actually people who disagree).

i disagree...
i dont like false security measures which give people the impression something is safe when it is not.

and i still hope for the feature to resend a tranaction with a higher fee if it gets stuck

2 - Per inner quote above, wallets should immediately and loudly notify their users of double-spends.  Amazingly, I am not aware of a single wallet that does this!  Please post if I am missing one or more.  The reason you notify the user is that they may not yet have handed over the merchandise.
right, i'd love that feature as well
3 - Per outer quote above, the network should relay, and not drop, double-spends.  This makes #2 above much more effective.  The actual double-spend transaction is the best alert, because it is signed by the person double-spending.  Anything else would require a trusted 3rd party.
no, this is to easy to use for spamming the network with transactions.
but maybe we can use an overlay network for that?
5 - Longer-term, before giving up on the bitcoin protocol, we should ask how to incentivize miners NOT to include second-spends in blocks.  For example, I have never seen a reason why this idea from 2011 could not reduce the unsafe period for 0-conf double spends to only seconds, instead of many minutes https://bitcointalksearch.org/topic/m.48484
not sure.... dont think its possible at all to make it safe as the attacker does not have to publish his double spend attempt before the fact - only his miner needs to know it of course

[/quote]
newbie
Activity: 54
Merit: 0
What about the concept of detecting double spends in bitcoin nodes and notifying merchant? ... 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.

Good questions.  Everyone sees that the decentralized bitcoin system can't have complete, immediate protection from the effects of 0-conf double-spends, but that is totally different from saying that the situation cannot be improved immensely.  Some improvements that can be made are:

1 - Agree that 0-conf double spends should be made more difficult, not easier (there are actually people who disagree).
2 - Per inner quote above, wallets should immediately and loudly notify their users of double-spends.  Amazingly, I am not aware of a single wallet that does this!  Please post if I am missing one or more.  The reason you notify the user is that they may not yet have handed over the merchandise.
3 - Per outer quote above, the network should relay, and not drop, double-spends.  This makes #2 above much more effective.  The actual double-spend transaction is the best alert, because it is signed by the person double-spending.  Anything else would require a trusted 3rd party.
5 - Longer-term, before giving up on the bitcoin protocol, we should ask how to incentivize miners NOT to include second-spends in blocks.  For example, I have never seen a reason why this idea from 2011 could not reduce the unsafe period for 0-conf double spends to only seconds, instead of many minutes https://bitcointalksearch.org/topic/m.48484

sr. member
Activity: 365
Merit: 251
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.
full member
Activity: 168
Merit: 100
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...
jr. member
Activity: 43
Merit: 1
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.
legendary
Activity: 1582
Merit: 1196
Reputation first.
Use BitPay to make your transaction with any problem and then pay grocery bill ! Cheesy
sr. member
Activity: 367
Merit: 250
Find me at Bitrated
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)


legendary
Activity: 1610
Merit: 1000
Well hello there!
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.
jr. member
Activity: 43
Merit: 1
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.
sr. member
Activity: 252
Merit: 250
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.
legendary
Activity: 1722
Merit: 1000
Satoshi is rolling in his grave. #bitcoin
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
legendary
Activity: 2053
Merit: 1356
aka tonikt
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.
sr. member
Activity: 444
Merit: 250
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.
legendary
Activity: 2053
Merit: 1356
aka tonikt
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 Smiley

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.
member
Activity: 114
Merit: 12

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.
jr. member
Activity: 43
Merit: 1
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).
Pages:
Jump to: