Bitcoin Forum
December 06, 2016, 02:07:09 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Making it easy for merchants to accept Bitcoin as payment  (Read 2968 times)
Bleak Morn
Newbie
*
Offline Offline

Activity: 26



View Profile
April 08, 2011, 05:11:19 PM
 #1

Heard an interview about Bitcoin on EconTalk.org and a desire was expressed to make some progress on making it easy for online merchants to get set-up to accept Bitcoin for online payments.

I'd like to help with that.  How do I find the folks who are working on that aspect of things?

Tips: 1H2ptN69vDhbSVzJ7s2k51tzCD4Hjit7Ff
1481033229
Hero Member
*
Offline Offline

Posts: 1481033229

View Profile Personal Message (Offline)

Ignore
1481033229
Reply with quote  #2

1481033229
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481033229
Hero Member
*
Offline Offline

Posts: 1481033229

View Profile Personal Message (Offline)

Ignore
1481033229
Reply with quote  #2

1481033229
Report to moderator
1481033229
Hero Member
*
Offline Offline

Posts: 1481033229

View Profile Personal Message (Offline)

Ignore
1481033229
Reply with quote  #2

1481033229
Report to moderator
Jaime Frontero
Full Member
***
Offline Offline

Activity: 126


View Profile
April 09, 2011, 01:46:43 AM
 #2

you could try contacting "mike" at Google.

http://code.google.com/p/bitcoinj/

i dunno if "pay-by-wave" will ever work with BitCoin, due to the need for verification by downloading recent blockchains - but when Google puts (to *any* degree) its imprimateur on something like BitCoin, its time for merchants to sit up and take notice.

now me; when i'm not actively engaged in being a geek, i earn my living as an antiquarian bookman - and i'm going to start taking BitCoin very soon now.  for any book i sell (and we're talking up into the 5-figure range: i've been at it for awhile...  Wink ).

to answer your question...  i think there's a need to figure out how to *safely* conduct transactions at the speed of the current, bank-driven internet marketplace.  i'd like to trust a non-fee'd payment within... say... a second or two.  i don't even know if that's possible - but it'd sure be a good thing.
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
April 09, 2011, 03:24:18 AM
 #3

A merchant gateway better that MyBitcoin's or MtGox's would be useful.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
ffe
Sr. Member
****
Offline Offline

Activity: 297



View Profile
April 09, 2011, 03:49:38 AM
 #4

Clients publish transactions to each other within seconds. If a new transaction is not a copy of the short term list of new transactions and is not a copy of something in the block chain it is probably ok to believe it will be accepted and you can proceed with the transactions.

The risk is that your client hasn’t seen the duplicate and the other transaction gets incorporated in the chain. I believe the chances of that happening for a normal transaction are low. The double spender would have to actively attack your client network connection to accomplish a double spend and for normal transactions a wait of a few seconds is perfectly fine. We would need the window to be large enough that we are very confident most clients have seen the transaction yet short enough that the selling merchant can wait without burdening normal customers. 15 seconds for example.

For high value transactions (like paying for a car) waiting for a few confirmations seems acceptable.

I think the merchant's client could be modified to let the merchant know there are no conflicting transactions in the active list after 15-30 seconds.
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
April 09, 2011, 04:33:45 AM
 #5

A merchant gateway better that MyBitcoin's or MtGox's would be useful.

Can you define "better"?

Definitely interested in hearing ideas...


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Nefario
Hero Member
*****
Offline Offline

Activity: 602


GLBSE Support support@glbse.com


View Profile WWW
April 09, 2011, 04:57:22 AM
 #6

A merchant gateway better that MyBitcoin's or MtGox's would be useful.

Can you define "better"?

Definitely interested in hearing ideas...



Easier to use/integrate into a website , possibly without the need for more than a line or two of html

Say someone sets up an account on such a system, to sell a new product they enter the product id an price, the site then gives them a line of html to put on the products page.
When the products page is viewed through a browser it shows a "Buy with bitcoin" button.

I'm out of time, so could someone else finish this narration?

PGP key id at pgp.mit.edu 0xA68F4B7C

To get help and support for GLBSE please email support@glbse.com
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
April 09, 2011, 05:29:07 AM
 #7

Can you define "better"?

Definitely interested in hearing ideas...

The existing solutions have very poor documentation. This is the main issue.

Merchant gateways should be using separate wallets so attacks against the EWallet service don't affect merchants. I consider MyBitcoin to be particularly insecure, since it accepts deposits after just 1 confirmation.

Gateways should offer all the features of PayPal, such as gathering shipping info.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
markm
Legendary
*
Offline Offline

Activity: 1778



View Profile WWW
April 09, 2011, 10:22:05 AM
 #8

Maybe even more useful than gathering shipping info would be to allow the merchant to specify the price in some currency other than Bitcoin.

In other words the customer pays the payment processing service in Bitcoin and the service gives the merchant the currency the merchant specified.

Paypal does that, doesn't it? I can tell it my price in CAD for example and I don't care what currency the customer chooses to use? Paypal tells them how much it will cost in their own currency to buy the thing I have priced in my currency?

That frees merchants from the entire headache of trying to play forex on the side as well as operate their business. Set your price, let your payment processing service take care of how to accept different currencies different credit cards etc etc, all you need from the processing service is the price you specified in the currency you specified. The more different currencies and cards and mobile/phone payment tokens and so on and so on the payment processor accepts the better but all that complication should be the payment processor's headache not the merchant's.

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
PLATO
Sr. Member
****
Offline Offline

Activity: 277


Subversive


View Profile WWW
April 12, 2011, 01:30:39 AM
 #9

Bleak Mom:

One way to help would be to consolidate these two wiki pages into one page, redirect the old one to the new one, and publicize the new page.
bitcoinex
Sr. Member
****
Offline Offline

Activity: 350


probiwon.com


View Profile WWW
April 19, 2011, 09:35:52 PM
 #10

A merchant gateway better that MyBitcoin's or MtGox's would be useful.

+1

just clone paypal.com API as Gavin said

New bitcoin lottery: probiwon.com
- Может, ты ещё и в Невидимую Руку Рынка веруешь? - Зачем же веровать в то, что можно наблюдать непосредственно?
tomcollins
Full Member
***
Offline Offline

Activity: 182


View Profile
April 19, 2011, 09:55:21 PM
 #11

Maybe even more useful than gathering shipping info would be to allow the merchant to specify the price in some currency other than Bitcoin.

In other words the customer pays the payment processing service in Bitcoin and the service gives the merchant the currency the merchant specified.

Paypal does that, doesn't it? I can tell it my price in CAD for example and I don't care what currency the customer chooses to use? Paypal tells them how much it will cost in their own currency to buy the thing I have priced in my currency?

That frees merchants from the entire headache of trying to play forex on the side as well as operate their business. Set your price, let your payment processing service take care of how to accept different currencies different credit cards etc etc, all you need from the processing service is the price you specified in the currency you specified. The more different currencies and cards and mobile/phone payment tokens and so on and so on the payment processor accepts the better but all that complication should be the payment processor's headache not the merchant's.

-MarkM-

This is something I had been working on before I noticed this thread.  It's trivially easy to do if you go with mtgox.

Set up a payment processing service that takes bitcoins and squares up with the merchants at some later date, similar to how PayPal or credit cards work.  The customer sets the dollar amount.  The payment service has a balance of coins on mtgox.  When the order comes in, you figure out how much you could sell the coins for on mtgox.  Add in a small transaction fee for your trouble (still probably cheaper than a credit card).  They transfer the coins to you,  you wait for however confirmations you need.  You instantly sell on mtgox (and transfer the ones you got to your mtgox account to replace them).  The merchant can periodically check on orders to see when you "accepted" the customers transaction, and then begins shipping the order.
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
April 20, 2011, 05:40:14 PM
 #12

BitCoinJ isn't really relevant to helping merchants today. It's mostly useful for end users and constrained devices. Most merchants today are online because the community is spread very thin geographically.

I agree with theymos that some easy integration with online stores is the way to go. For instance a website that lets you upload your product list and prices (in your local currency) and which handles all the currency conversions, creation of addresses etc for you. Merchants could sell things for BTC by just using a friendly web site to set up their store and then adding links or redirects to their existing solutions.
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
April 21, 2011, 10:12:18 AM
 #13

Clients publish transactions to each other within seconds. If a new transaction is not a copy of the short term list of new transactions and is not a copy of something in the block chain it is probably ok to believe it will be accepted and you can proceed with the transactions.

The risk is that your client hasn’t seen the duplicate and the other transaction gets incorporated in the chain. I believe the chances of that happening for a normal transaction are low. The double spender would have to actively attack your client network connection to accomplish a double spend and for normal transactions a wait of a few seconds is perfectly fine. We would need the window to be large enough that we are very confident most clients have seen the transaction yet short enough that the selling merchant can wait without burdening normal customers. 15 seconds for example.

For high value transactions (like paying for a car) waiting for a few confirmations seems acceptable.

I think the merchant's client could be modified to let the merchant know there are no conflicting transactions in the active list after 15-30 seconds.
NO, unconfirmed transactions with no special attempts to ensure finding double-spend transactions are not acceptable for any automated system.  In the standard client, even if your client does hear about a double spend, it doesn't mark the double-spent transaction of notify you in any way.  If an attacker created to transactions, sending one to the largest miners (not hard to figure out their IPs) and one to you (depending on the way you structure it, also probably not hard to find your IP) and you would be none the wiser.  Even if you purposefully modify your client to mark double-spent transactions, you have to make sure you have a direct connection between you and the miners attacked to ensure the nodes in between don't drop the double-spend you want to know about.

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
ffe
Sr. Member
****
Offline Offline

Activity: 297



View Profile
April 21, 2011, 03:03:42 PM
 #14

Clients publish transactions to each other within seconds. If a new transaction is not a copy of the short term list of new transactions and is not a copy of something in the block chain it is probably ok to believe it will be accepted and you can proceed with the transactions.

The risk is that your client hasn’t seen the duplicate and the other transaction gets incorporated in the chain. I believe the chances of that happening for a normal transaction are low. The double spender would have to actively attack your client network connection to accomplish a double spend and for normal transactions a wait of a few seconds is perfectly fine. We would need the window to be large enough that we are very confident most clients have seen the transaction yet short enough that the selling merchant can wait without burdening normal customers. 15 seconds for example.

For high value transactions (like paying for a car) waiting for a few confirmations seems acceptable.

I think the merchant's client could be modified to let the merchant know there are no conflicting transactions in the active list after 15-30 seconds.
NO, unconfirmed transactions with no special attempts to ensure finding double-spend transactions are not acceptable for any automated system.  In the standard client, even if your client does hear about a double spend, it doesn't mark the double-spent transaction of notify you in any way.  If an attacker created to transactions, sending one to the largest miners (not hard to figure out their IPs) and one to you (depending on the way you structure it, also probably not hard to find your IP) and you would be none the wiser.  Even if you purposefully modify your client to mark double-spent transactions, you have to make sure you have a direct connection between you and the miners attacked to ensure the nodes in between don't drop the double-spend you want to know about.

Within 15 seconds you would hear from the miner he targeted and know he double spent. The client could be changed to notify you of the double spend. To stop that he would have to keep you from hearing from most other clients for many seconds. That's hard.

Anyway, I'm talking about adjusting the wait to the amount spent. A vending machine that charges 30 cents for a stick of gum could wait 15 seconds and would just eat the loss if an attack like that were being mounted. They do that today when someone uses a slug in a vending machine.
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
April 21, 2011, 03:10:21 PM
 #15

Within 15 seconds you would hear from the miner he targeted and know he double spent. The client could be changed to notify you of the double spend. To stop that he would have to keep you from hearing from most other clients for many seconds. That's hard.

Anyway, I'm talking about adjusting the wait to the amount spent. A vending machine that charges 30 cents for a stick of gum could wait 15 seconds and would just eat the loss if an attack like that were being mounted. They do that today when someone uses a slug in a vending machine.
Keep in mind that a node will not forward a transaction if it has already seen one that conflicts.  This means that unless you have a direct connection to a miner, chances are you won't ever hear about a double spending transaction (because you will forward the first transaction to the nodes around you before they hear about the double-spending one from the rest of the network).  Yes, you can modify your node to connect to deepbit+slush's pool+ArtForz, but those servers cant handle 1000 vending machines connecting to them or even a ton of users who want a bit more security. 

Yes, you could eat the losses for small things, however, people would write clients that actively try to double spend on every transaction meaning they pay for their things only maybe 25% of the time, and if such clients gain market share you are looking at eating a lot of losses.

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
MoonShadow
Legendary
*
Offline Offline

Activity: 1666



View Profile
April 21, 2011, 03:42:02 PM
 #16

Clients publish transactions to each other within seconds. If a new transaction is not a copy of the short term list of new transactions and is not a copy of something in the block chain it is probably ok to believe it will be accepted and you can proceed with the transactions.

The risk is that your client hasn’t seen the duplicate and the other transaction gets incorporated in the chain. I believe the chances of that happening for a normal transaction are low. The double spender would have to actively attack your client network connection to accomplish a double spend and for normal transactions a wait of a few seconds is perfectly fine. We would need the window to be large enough that we are very confident most clients have seen the transaction yet short enough that the selling merchant can wait without burdening normal customers. 15 seconds for example.

For high value transactions (like paying for a car) waiting for a few confirmations seems acceptable.

I think the merchant's client could be modified to let the merchant know there are no conflicting transactions in the active list after 15-30 seconds.
NO, unconfirmed transactions with no special attempts to ensure finding double-spend transactions are not acceptable for any automated system.  In the standard client, even if your client does hear about a double spend, it doesn't mark the double-spent transaction of notify you in any way.  If an attacker created to transactions, sending one to the largest miners (not hard to figure out their IPs) and one to you (depending on the way you structure it, also probably not hard to find your IP) and you would be none the wiser.  Even if you purposefully modify your client to mark double-spent transactions, you have to make sure you have a direct connection between you and the miners attacked to ensure the nodes in between don't drop the double-spend you want to know about.

The regular client doesn't perform a check of the live transaction queue, but it could be done.  I'd be willing to bet that it will be a standard check on POS systems long before Wal-Mart starts accepting Bitcoin at their registers.  And a slick POS client could also send the transaction to all of it's peers except one, and if that peer offers back that same transaction then it's safe to assume that the transaction is good.  Even if there is a double spend attempt underway, if your own POS system has a decent spread of peers and your last peer then sends you the correct transaction, odds are high enough that your transaction was first (and therefore most likely to come away with the actual bitcoins) and therefore acceptable.  This would be acceptable risks for sales values under $50, and is similar to how credit card companies handle charges under $50.

Such a check wouldn't take nearly 15 seconds under normal network loading conditions, but a 15 second timeout would be reasonable.

"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."

- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
MoonShadow
Legendary
*
Offline Offline

Activity: 1666



View Profile
April 21, 2011, 03:45:43 PM
 #17


Yes, you could eat the losses for small things, however, people would write clients that actively try to double spend on every transaction meaning they pay for their things only maybe 25% of the time, and if such clients gain market share you are looking at eating a lot of losses.

If such things start happening, the methods of double spend checks would become more complicated, and fewer vendors will be willing to accept unconfirmed bitcoin transactions without ID and/or insurance.  The fraudulent user is then in a digital arms race that he cannot win, and repeatedly doing these kinds of things is still going to get you caught eventually.

"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."

- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
ffe
Sr. Member
****
Offline Offline

Activity: 297



View Profile
April 21, 2011, 04:12:12 PM
 #18

Keep in mind that a node will not forward a transaction if it has already seen one that conflicts.  

This is why in a previous post I'd recommended we do pass an indication of a double spend.

... the _only_ person who can double spend is the owner of the coin (since only he knows the private key). The only time clients see a double spend is if the owner is purposely being malicious. It is therefore reasonable to drop _both_ the original and the second transactions if a double spend is seen within a window of time. Further, the double spend "event" could be bundled (both original transactions included in the bundle as proof of the double spend) into a transaction that locks that coin out for a long time (remember, we have proof of malicious intent so we would be justified in locking out the coin for say 10,000 blocks or more).

After the [15 second] window of time expires the second transaction is simply ignored. At this point we don't want to lock out the coin because we don't want to leave an opening for the original owner to cancel the original transaction. We would need the window to be large enough that we are very confident most clients have seen it yet short enough that the selling merchant can wait without burdening normal customers. 15 seconds for example. So, waiting 30 seconds without seeing the coin lockout transaction would assure the merchant no double spending happened.
Matt Corallo
Hero Member
*****
expert
Offline Offline

Activity: 751


View Profile
April 21, 2011, 04:41:33 PM
 #19

Keep in mind that a node will not forward a transaction if it has already seen one that conflicts.  

This is why in a previous post I'd recommended we do pass an indication of a double spend.
And so opens the door for massive DDoS potential.  Better to just not.

... the _only_ person who can double spend is the owner of the coin (since only he knows the private key). The only time clients see a double spend is if the owner is purposely being malicious. It is therefore reasonable to drop _both_ the original and the second transactions if a double spend is seen within a window of time. Further, the double spend "event" could be bundled (both original transactions included in the bundle as proof of the double spend) into a transaction that locks that coin out for a long time (remember, we have proof of malicious intent so we would be justified in locking out the coin for say 10,000 blocks or more).

After the [15 second] window of time expires the second transaction is simply ignored. At this point we don't want to lock out the coin because we don't want to leave an opening for the original owner to cancel the original transaction. We would need the window to be large enough that we are very confident most clients have seen it yet short enough that the selling merchant can wait without burdening normal customers. 15 seconds for example. So, waiting 30 seconds without seeing the coin lockout transaction would assure the merchant no double spending happened.
Interesting idea, but I disagree.  It is possible that it could happen reasonably if a user copied their wallet.dat (fist rule of software: your users are out to break your program). 

If such things start happening, the methods of double spend checks would become more complicated, and fewer vendors will be willing to accept unconfirmed bitcoin transactions without ID and/or insurance.  The fraudulent user is then in a digital arms race that he cannot win, and repeatedly doing these kinds of things is still going to get you caught eventually.
Without ID/insurance and at that point you might as well just wait the 10 minutes.  Also, it becomes hard online and if you want to actually be sure you have to have a person check.  Again, at that point, just wait the 10 minutes. 

The regular client doesn't perform a check of the live transaction queue, but it could be done.  I'd be willing to bet that it will be a standard check on POS systems long before Wal-Mart starts accepting Bitcoin at their registers.  And a slick POS client could also send the transaction to all of it's peers except one, and if that peer offers back that same transaction then it's safe to assume that the transaction is good.  Even if there is a double spend attempt underway, if your own POS system has a decent spread of peers and your last peer then sends you the correct transaction, odds are high enough that your transaction was first (and therefore most likely to come away with the actual bitcoins) and therefore acceptable.  This would be acceptable risks for sales values under $50, and is similar to how credit card companies handle charges under $50.

Such a check wouldn't take nearly 15 seconds under normal network loading conditions, but a 15 second timeout would be reasonable.
That is an interesting idea.  I'm not so sure that gives you that good of certainty.  If there was a malicious user, it would be their goal to send out the tx they dont want to see accepted as much as possible through the network.  Although it would provide protection, some users would still exploit the system.  Whether that is enough for places to take the losses, I don't know. 

In any case I don't see a future where every normal user is using standard bitcoin nodes.  The network probably won't handle that and I doubt merchants will want to run their own bitcoin instances all over the place.  Much more likely is a set of payment processors using bitcoin as the currency of exchange. 

Bitcoin Ubuntu PPA maintainer - donate to me personally: 1JBMattRztKDF2KRS3vhjJXA7h47NEsn2c
http://bitcoinrelaynetwork.org maintainer
PGP ID: 07DF 3E57 A548 CCFB 7530  7091 89BB B866 3E2E65CE
MoonShadow
Legendary
*
Offline Offline

Activity: 1666



View Profile
April 21, 2011, 08:16:21 PM
 #20


The regular client doesn't perform a check of the live transaction queue, but it could be done.  I'd be willing to bet that it will be a standard check on POS systems long before Wal-Mart starts accepting Bitcoin at their registers.  And a slick POS client could also send the transaction to all of it's peers except one, and if that peer offers back that same transaction then it's safe to assume that the transaction is good.  Even if there is a double spend attempt underway, if your own POS system has a decent spread of peers and your last peer then sends you the correct transaction, odds are high enough that your transaction was first (and therefore most likely to come away with the actual bitcoins) and therefore acceptable.  This would be acceptable risks for sales values under $50, and is similar to how credit card companies handle charges under $50.

Such a check wouldn't take nearly 15 seconds under normal network loading conditions, but a 15 second timeout would be reasonable.
That is an interesting idea.  I'm not so sure that gives you that good of certainty.  If there was a malicious user, it would be their goal to send out the tx they dont want to see accepted as much as possible through the network.  Although it would provide protection, some users would still exploit the system.  Whether that is enough for places to take the losses, I don't know. 

No, not certainty, but high probability.  If the POS owner chose his peers well, it would be a quantifiable probability; but it would be pretty certain under random peer selection as well.  High enough that I'd be willing to offer vendors insurance against a double spend fraud, and I'd be running the POS super-node.  I can forsee an niche industry of Bitcoin processing companies offering such insurance to small vendors, but chains such as Walmart or Sears are going to do such thinkgs for themselves.
Quote

In any case I don't see a future where every normal user is using standard bitcoin nodes.  The network probably won't handle that and I doubt merchants will want to run their own bitcoin instances all over the place.  Much more likely is a set of payment processors using bitcoin as the currency of exchange. 

That's it exactly.  In the short term, Bitcoin vendors are likely to have normal clients running in the store, but ultimately such functions are likely to be consolidated into datacenters with special POS light clients in the store.  This is pretty much how credit card transactions are handled these days.  The important part is that an independent vendor always has the realistic option of setting up a local full client if his service company ever gets uppity, and the customer also always has the option of setting up his own full node if he ever has reason to distrust his online wallet bank.  Keeps these groups honest.

"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."

- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!