Brick-and-mortar BTC payments.

[ruski]

So, I was planning to do this all myself and get rich (still might, mind you) but let's have a discussion. What will it take to bring BTC to actual stores?

1. Payment (obviously.)
EFTPOS machines work by reading your card, authenticating to a processor server and transferring the funds. This seems like the fastest and easiest way to do it - use a familiar system, ie. an EFTPOS look-alike, and credit-card size cards. The infrastructure required would be:

• Accounts. Instantly accessible merchant and buyer accounts. Using the blockchain for instant transactions is not feasible. However, codifying every transaction after the fact in the blockchain is quite possible and really quite simple. Have your cake and eat it too - instant and non-reversible transactions.
• Standardized cards and readers. With no "central authority" this is nearly impossible. If Mt Gox decided to expand Yubikey functionality into ordinary cards and sell the card readers, complete with API software so the McDonalds till can tell the reader how much to debit, it's possible. Any third party so inclined could also do it.

2. Acceptance

• Acquiring BTC. It needs to be easier. It's virtually impossible to bring Australian cash to Mt Gox to buy coins, and the eventual fees are massive. Not to mention the fact that you need to first actually buy Bitcoins before you can use them, anywhere. With a trusted direct debit service, uncharged BTC accounts could end up similar to a no-fee no-interest credit card, with the same legal consequences if the money isn't in the bank to buy your BTC in the background. No direct purchase of BTC by you required.
• Fees. There has to be a reason you'd go to the trouble of getting BTC to spend in a shop instead of just using your bank card. There is definitely a reason for businesses from the local pizza shop to the supermarket to adopt it - no chargebacks. But why would you personally use it? Shops pass on a lot of bank fees to their customers. With a good sales pitch for BTC, decent discounts could easily be negotiated for BTC purchases.
• Exclusivity. Some companies no doubt have deals with Visa or Mastercard to accept only those cards, and get discounts on their fees in return. With a system as easy to use as above, the only barrier would be awareness and these shops will be able to drop those deals like hot potatoes, and while they're at it, promote Bitcoin.
  

[1713511637]

1713511637

[1713511637]

1713511637

[1713511637]

1713511637

[joepie91]

So, I was planning to do this all myself and get rich (still might, mind you) but let's have a discussion. What will it take to bring BTC to actual stores?

1. Payment (obviously.)
EFTPOS machines work by reading your card, authenticating to a processor server and transferring the funds. This seems like the fastest and easiest way to do it - use a familiar system, ie. an EFTPOS look-alike, and credit-card size cards. The infrastructure required would be:

• Accounts. Instantly accessible merchant and buyer accounts. Using the blockchain for instant transactions is not feasible. However, codifying every transaction after the fact in the blockchain is quite possible and really quite simple. Have your cake and eat it too - instant and non-reversible transactions.
• Standardized cards and readers. With no "central authority" this is nearly impossible. If Mt Gox decided to expand Yubikey functionality into ordinary cards and sell the card readers, complete with API software so the McDonalds till can tell the reader how much to debit, it's possible. Any third party so inclined could also do it.

2. Acceptance

• Acquiring BTC. It needs to be easier. It's virtually impossible to bring Australian cash to Mt Gox to buy coins, and the eventual fees are massive. Not to mention the fact that you need to first actually buy Bitcoins before you can use them, anywhere. With a trusted direct debit service, uncharged BTC accounts could end up similar to a no-fee no-interest credit card, with the same legal consequences if the money isn't in the bank to buy your BTC in the background. No direct purchase of BTC by you required.
• Fees. There has to be a reason you'd go to the trouble of getting BTC to spend in a shop instead of just using your bank card. There is definitely a reason for businesses from the local pizza shop to the supermarket to adopt it - no chargebacks. But why would you personally use it? Shops pass on a lot of bank fees to their customers. With a good sales pitch for BTC, decent discounts could easily be negotiated for BTC purchases.
• Exclusivity. Some companies no doubt have deals with Visa or Mastercard to accept only those cards, and get discounts on their fees in return. With a system as easy to use as above, the only barrier would be awareness and these shops will be able to drop those deals like hot potatoes, and while they're at it, promote Bitcoin.
  

The main issue with a card would be that either
1. you have to trust a payment processor to handle 'payment requests' which opens up a whole slew of other potential issues
2. you have to allow the payment terminal access to a wallet on your card, thus allowing it access to *all* of your funds on that card.

I think a more feasible method would be some kind of hardware device with a simple LCD screen to display an amount and an 'accept' and 'reject' button. You would 'plug it in' for payment, the terminal sends a payment request to the hardware unit. The hardware unit then shows you the amount, and if you accept the payment, it makes a new address, sends the right amount of BTC to that address (broadcasting it to the blockchain through the payment terminal), and then passes on the public + private key of that new address to the payment terminal. The payment terminal now has a new address (public + private key) with the exact amount of BTC that the customer had to pay - and can either save these keys somewhere, or transfer the funds in that address to their own wallet.

[mc_lovin]

My idea was to use a remote login program and log into your computer at home with the bitcoin software operated remotely using teamviewer.

http://bit-coin-trading.com/forum/index.php?topic=127.0

I mean, it DOES work.  Except you would have an issue typing that crazy long bitcoin address unless you used a bitcoin wallet address shortener.

[ruski]

Sure, those 2 would be issues online. Do you think McDonalds is going to take more than theyre entitled to? Or a licensed FS firm scamming? Also, your way relies on the chain and takes too long for a store. Besides, you get the accept button anyway.

[ruski]

I will be collecting a couple of trial card designs from the printers next week. Lets take another look at interest then 

[joepie91]

Sure, those 2 would be issues online. Do you think McDonalds is going to take more than theyre entitled to? Or a licensed FS firm scamming? Also, your way relies on the chain and takes too long for a store. Besides, you get the accept button anyway.

The entire idea of Bitcoin is, if I recall correctly, that there is no *need* to trust a third party.

As for relying on the chain - any solution that does not involve having to trust a third party (payment processor) will rely on the chain. The time it takes will be the same regardless, unless you find it an acceptable solution to (by default) trust a third party, which would make the entire idea of Bitcoin somewhat pointless. The cost of a double-spending attack for example would be far too high for any small amounts (meaning you can pretty much just assume that a spend is valid), and for large amounts you will always have to deal with this issue, even if you allow 'direct access' to a wallet.dat (because in fact what happened after gaining access to that wallet, would still be the same as with the method I am describing).

[ruski]

The point of the security behind Bitcoin is that you don't need to trust anybody with the security. Not trusting anyone at all with your money would mean there was zero trade, in the end.

I think one of the only fatal problems with Bitcoin, if it's not overcome soon, will be the 10-minute-per-block standard. Without a third party, real-time transactions using the block chain are not possible or feasible for real-world applications.

That said, I am currently coding an entirely original CMS and secure back-end processing system for this. It won't be too efficient, but any hack besides a DDOS will also have to be original and not some tired SQL injection attack or the like, so security should be good. I've also revised the idea a bit. I know it may seem hard to swallow for those of you who treasure anonymity and no trust above all, but read to the end, please. This seems to be the only feasible way to bring Bitcoin into the mainstream.

The service will function like an escrow. A large number of the server's own Bitcoins will be held as a pool - ie. primary investment, having come from nobody but myself. Bob will open an account, and McDonalds will open an account. Bob now wants to buy a cheeseburger.

Bob can now either:

• credit his account with Bitcoins directly,
• or authorise direct debit to the value of the desired Bitcoin balance. (enter the hard-to-swallow part.)

Since DD is instant, in most cases free, and can only come from an account where Bob has authorized those payments, there can be no question of chargebacks against the service, and no delays. Bitcoins to the value Bob wanted are immediately transferred from the service pool to Bob's account, and the service replaces them from the market with Bob's cash. If those Bitcoins are not for immediate spending, that transaction can then be made temporarily inaccessible to Bob while it's transferred to Bob's address via the blockchain, removing the coins from Bob's "paper" account and making them accessible from both within the service, and any client on which he has the server-generated wallet.dat.

(example: Bob's server wallet address is 1abc456. He has 2 BTC in that wallet as confirmed by the blockchain, and 5 BTC that are just being credited to 1abc456, actually belonging to the service. If the service goes down, he will only have those 2 BTC, but once the 5 BTC are sent via the blockchain, he can access them anywhere. Capiche?)

Obviously, the same can then be repeated for the merchant.

But wait - there's more! Since Bitcoin isn't actually currency or a recognized financial instrument, there is no legal obligation to keep meticulous records of BTC transactions. Cash transactions and names must be kept for 7 years, and they will be. However, this makes it possible to have two types of accounts - anonymous BTC only, basically an online wallet, and the cash-chargeable account. With zero BTC recordkeeping and the potential to rout BTC internally instead of via the chain, Bob could charge his account, transfer them directly to an anonymous account and use that as safely as if he was using the client.


Having a third party brings a great deal of convenience, simplicity and overcomes one of Bitcoin's built-in flaws. Neither seller nor buyer have to really understand BTC beyond which buttons to push. They both, however, recognize the savings over current mainstream processors.

More to come. Also, I'll be opening this server for a stress test soon, hack-this-site-esque.

Disclaimer: The record keeping is only my interpretation and may not be as so. I'm still trying to decrypt the Australian AML/CTF Act 2006 which covers "digital currencies."

[ruski]

From the Act:

ANTI-MONEY LAUNDERING AND COUNTER-TERRORISM FINANCING ACT 2006 - SECT 4
A reporting entity must carry out a procedure to verify a customer's identity before providing a designated service to the customer. However, in special cases, the procedure may be carried out after the provision of the designated service.

ANTI-MONEY LAUNDERING AND COUNTER-TERRORISM FINANCING ACT 2006 - SECT 6
(1)  For the purposes of this Act, the following tables define:
  (a)  the provision of a designated service ; and
  (b)  the person (the customer ) to whom the designated service is provided.

(1) in the capacity of account provider, opening an account, where the account provider is:
  (e) a person specified in the AML/CTF Rules

ANTI-MONEY LAUNDERING AND COUNTER-TERRORISM FINANCING ACT 2006 - SECT 5
"account" includes:
(c)  an account of money held in the form of units in:
  (i)  a cash management trust; or
  (ii)  a trust of a kind prescribed by the AML/CTF Rules.

"money" includes:
  (d)  e-currency, however amounts of the e-currency are expressed.

"e-currency" means an internet-based, electronic means of exchange that is:
  (c)  not issued by or under the authority of a government body;

"trust" means a person in the capacity of trustee or, as the case requires, a trust estate.
"trustee" has the same meaning as in the Income Tax Assessment Act 1997 .

from the Income Tax Assessment Act 1997
"trustee" :
(a)  of a * superannuation fund, an * approved deposit fund or a * pooled superannuation trust--means:

"approved deposit fund" has the meaning given by section 10 of the Superannuation Industry (Supervision) Act 1993 .

from the Superannuation Industry (Supervision) Act 1993
"approved deposit fund" means a fund that:
  (a)  is an indefinitely continuing fund; and

"fund" means a regulated superannuation fund or an approved deposit fund.

Dictionary
cash
Noun: Money in coins or notes, as distinct from checks, money orders, or credit.

I do not believe an account held in Bitcoins would qualify as an account under the Act.


Further to that, however:

ANTI-MONEY LAUNDERING AND COUNTER-TERRORISM FINANCING ACT 2006 - SECT 6
(4) accepting money on deposit (otherwise than by way of deposit to an account), where the deposit-taker is:
  (e) a person specified in the AML/CTF Rules

"deposit" is not defined in the Act, nor are any references to other Acts given in relation to its meaning. I'll look into that further.

Dictionary
de·pos·it
verb
Store or entrust with someone for safekeeping

Areas to follow up:
"promissory note" has the same meaning as in paragraph 51(xvi) of the Constitution. as far as "crediting" "accounts." On that note, I'm not sure whether the use of a chain-verified private key would even constitute the provision of an account.

Anti-Money Laundering/Counter-Terrorism Financing Rules, ie. the rules made under section 229 of the ANTI-MONEY LAUNDERING AND COUNTER-TERRORISM FINANCING ACT 2006 could use some spading.

[joepie91]

The point of the security behind Bitcoin is that you don't need to trust anybody with the security. Not trusting anyone at all with your money would mean there was zero trade, in the end.

I think one of the only fatal problems with Bitcoin, if it's not overcome soon, will be the 10-minute-per-block standard. Without a third party, real-time transactions using the block chain are not possible or feasible for real-world applications.

As I said before, it would be perfectly possible to just assume a transaction is not a double spend, in the case of small amounts ('small' being a relative term here).

That said, I am currently coding an entirely original CMS and secure back-end processing system for this. It won't be too efficient, but any hack besides a DDOS will also have to be original and not some tired SQL injection attack or the like, so security should be good. I've also revised the idea a bit. I know it may seem hard to swallow for those of you who treasure anonymity and no trust above all, but read to the end, please. This seems to be the only feasible way to bring Bitcoin into the mainstream.

The service will function like an escrow. A large number of the server's own Bitcoins will be held as a pool - ie. primary investment, having come from nobody but myself. Bob will open an account, and McDonalds will open an account. Bob now wants to buy a cheeseburger.

Bob can now either:

• credit his account with Bitcoins directly,
• or authorise direct debit to the value of the desired Bitcoin balance. (enter the hard-to-swallow part.)

Since DD is instant, in most cases free, and can only come from an account where Bob has authorized those payments, there can be no question of chargebacks against the service, and no delays. Bitcoins to the value Bob wanted are immediately transferred from the service pool to Bob's account, and the service replaces them from the market with Bob's cash. If those Bitcoins are not for immediate spending, that transaction can then be made temporarily inaccessible to Bob while it's transferred to Bob's address via the blockchain, removing the coins from Bob's "paper" account and making them accessible from both within the service, and any client on which he has the server-generated wallet.dat.

(example: Bob's server wallet address is 1abc456. He has 2 BTC in that wallet as confirmed by the blockchain, and 5 BTC that are just being credited to 1abc456, actually belonging to the service. If the service goes down, he will only have those 2 BTC, but once the 5 BTC are sent via the blockchain, he can access them anywhere. Capiche?)

Obviously, the same can then be repeated for the merchant.

But wait - there's more! Since Bitcoin isn't actually currency or a recognized financial instrument, there is no legal obligation to keep meticulous records of BTC transactions. Cash transactions and names must be kept for 7 years, and they will be. However, this makes it possible to have two types of accounts - anonymous BTC only, basically an online wallet, and the cash-chargeable account. With zero BTC recordkeeping and the potential to rout BTC internally instead of via the chain, Bob could charge his account, transfer them directly to an anonymous account and use that as safely as if he was using the client.


Having a third party brings a great deal of convenience, simplicity and overcomes one of Bitcoin's built-in flaws. Neither seller nor buyer have to really understand BTC beyond which buttons to push. They both, however, recognize the savings over current mainstream processors.

More to come. Also, I'll be opening this server for a stress test soon, hack-this-site-esque.

Disclaimer: The record keeping is only my interpretation and may not be as so. I'm still trying to decrypt the Australian AML/CTF Act 2006 which covers "digital currencies."

How can it *possibly* be a good idea to centralize the 'main' usage option for bitcoin IRL, into one single payment processor - and have companies adopt the system of that one payment processor, causing pretty much a vendor lock-in?

[ruski]

As I said before, it would be perfectly possible to just assume a transaction is not a double spend, in the case of small amounts ('small' being a relative term here).

OK then, would you like to be the processor assuming 50,000 $2 transactions a day are all legit spends? Yeah.. didn't think so.

How can it *possibly* be a good idea to centralize the 'main' usage option for bitcoin IRL, into one single payment processor - and have companies adopt the system of that one payment processor, causing pretty much a vendor lock-in?

It doesn't have to be locked in. Once the protocol is established and standardised, other companies could offer an alternate service if they wanted. Better customer service, lower fees (if lower is possible), better interface, whatever - that's what competition is about. We have to start somewhere, and this is as good a place as any. If anti-competitiveness is your only concern, what I'm proposing is really only a system. One or a dozen companies could execute it. I intend to be the first and I've got some neat marketing strategies ready to go too

As you said above - your company could follow the blind faith path, if you wanted. With this protocol it would hardly even matter since the whole thing is geared to work around the block-chain delay, while still solidly incorporating the security it provides, mostly after the fact instead of before.

[zellfaze]

The point of the security behind Bitcoin is that you don't need to trust anybody with the security. Not trusting anyone at all with your money would mean there was zero trade, in the end.

I think one of the only fatal problems with Bitcoin, if it's not overcome soon, will be the 10-minute-per-block standard. Without a third party, real-time transactions using the block chain are not possible or feasible for real-world applications.

As I said before, it would be perfectly possible to just assume a transaction is not a double spend, in the case of small amounts ('small' being a relative term here).

I agree that you could just assume that it isn't a double spend.  If it is a transaction worth less than a few USD, you don't really lose all the much if it is a double spend.  On top of that the resources required to double-spend are outrageously high compared to the free cup of coffee that you could get if you double-spent.  The profit motive doesn't exist to double-spend small transactions.

Now for larger things, it might be better to wait for a few confirmations, but people do that anyhow.  You generally need paper-work and such for large transactions.  If I bought a house or car with BTC, I would be Ok waiting an hour to get it.

[ruski]

You're also assuming the only illegitimate transactions are double spends. If you're "assuming" any submitted payment is legitimate, you're also vulnerable to non-existent coins being spent. This is the reason we're all here, and you're saying it's pointless? With one breath you say we need security, and with the next you say we don't.

I thought that waiting for a transaction to be confirmed a few times was a prudent given and common sense. I can hardly believe we're even arguing about it... getting a bit off topic aren't we?

[zellfaze]

Your client itself can verify the coins exist; this is why we all keep a copy of the entire block chain.  Waiting for confirmations is just so that people don't double spend.

But yes, we are getting off topic.

[ruski]

A rough sample card I whipped up in Photoshop. I'm many things, but a graphic designer isn't one of them. If any of you have designed some BTC cards, now may be a good time to post them. I have a short run of 20 different designs due to the printers by Wednesday.

Server is well on its way to stress testing. Few more days, folks.