Bitcoin snack machine (fast transaction problem)

How would a Bitcoin snack machine work?

1. You want to walk up to the machine. Send it a bitcoin.
2. ?
3. Walk away eating your nice sugary snack. (Profit!)

You don’t want to have to wait an hour for you transaction to be confirmed. The vending machine company doesn’t want to give away lots of free candy.

How does step 2 work?

what you folks are calling an escrow sounds a lot like a debit card account.

what you folks are calling an escrow sounds a lot like a debit card account.

Bitcoins are the equivalent to cold hard cash. There’s nothing precluding the creation and adoption of debit, credit, banks, loans and fractional reserve lending using bitcoins. Read the posts by InterArmaEnimSil in this related thread. Just as a word of caution, escrow services are often operate with the purpose of ripping people off, so make sure you trust them and only kick yourself, but not to harshly, if they rip you off.

Quote from: Babylon on July 16, 2010, 11:28:22 PM UTC

what you folks are calling an escrow sounds a lot like a debit card account.

Bitcoins are the equivalent to cold hard cash. There’s nothing precluding the creation and adoption of debit, credit, banks, loans and fractional reserve lending using bitcoins. Read the posts by InterArmaEnimSil in this related thread. Just as a word of caution, escrow services are often operate with the purpose of ripping people off, so make sure you trust them and only kick yourself, but not to harshly, if they rip you off.

Yeah, I understood the fractional reserve thread. I am not sure that I fully understand escrow, I know it is usually used in large transactions to ensure the seller that the cash is indeed on hand, and will stay that way. Part of the purpose, as far as I can tell, is usually to slow down transactions, thus making them more secure. In this case it seems the point is more to speed up transactions without losing security, which looks more like a debit account than an escrow service, but I may be misunderstanding what an escrow service is.

In this case it seems the point is more to speed up transactions without losing security, which looks more like a debit account than an escrow service, but I may be misunderstanding what an escrow service is.

You’re not misunderstanding. Escrow and debit are similar services and their definitions overlap. I was stretching the definition. Debit fits my description just as well if not better than escrow. I was just putting the emphasis on the fact that the company, whatever it’s called, can transfer bitcoin balances on an accounting sheet instantly without having to wait for a real bitcoin transaction, but like is described in the fractional reserve lending thread.

Even better than an escrow, you just fund the beverage machine company itself.

Like this: you go to the company’s website and send them 100 BC. Then, they give you an ID. They have plenty of time to get confirmations to build, and when you need a beverage you just use the ID they issued you and they debit it from your account.

Even better than an escrow, you just fund the beverage machine company itself.

Like this: you go to the company’s website and send them 100 BC. Then, they give you an ID. They have plenty of time to get confirmations to build, and when you need a beverage you just use the ID they issued you and they debit it from your account.

a prepaid account with the snack machine company works great for snack machines in corporate cafeterias (or other places with a fairly static consumer base) not so much for areas with a large transitory consumer base, such as airports, ferry boats, train stations etc.

I believe it’ll be possible for a payment processing company to provide as a service the rapid distribution of transactions with good-enough checking in something like 10 seconds or less.

The network nodes only accept the first version of a transaction they receive to incorporate into the block they’re trying to generate.  When you broadcast a transaction, if someone else broadcasts a double-spend at the same time, it’s a race to propagate to the most nodes first.  If one has a slight head start, it’ll geometrically spread through the network faster and get most of the nodes.

A rough back-of-the-envelope example:
1         0
4         1
16        4
64        16
80%      20%

So if a double-spend has to wait even a second, it has a huge disadvantage.

The payment processor has connections with many nodes.  When it gets a transaction, it blasts it out, and at the same time monitors the network for double-spends.  If it receives a double-spend on any of its many listening nodes, then it alerts that the transaction is bad.  A double-spent transaction wouldn’t get very far without one of the listeners hearing it.  The double-spender would have to wait until the listening phase is over, but by then, the payment processor’s broadcast has reached most nodes, or is so far ahead in propagating that the double-spender has no hope of grabbing a significant percentage of the remaining nodes.

The service provider has connections with many nodes. When it gets a transaction, it blasts it out, and at the same time monitors the network for double-spends. If it receives a double-spend on any of its many listening nodes, then it alerts that the transaction is bad. A double-spent transaction wouldn’t get very far without one of the listeners hearing it. The double-spender would have to wait until the listening phase is over, but by then, the service provider’s broadcast has reached most nodes, or is so far ahead in propagating that the double-spender has no hope of grabbing a significant percentage of the remaining nodes.

This is a good start, but still not impermeable. This kind of security relies on the fact that the majority of nodes (which really just boils down to the majority of IP’s) are honest. However, if the attacker could amass many IP addresses, then he could control the propagation (for example, by refusing to propogate word of the transaction at the vending machine), and still lead a successful double-spending attack. Which sort of brings us back to the main novel idea of bitcoin: truth is voted on by computing power, not IP.

For just a beverage, it may seem like this attack is uneconomical. But imagine if instead the machine dispensed small-denomination giftcards, and the attack was performed thousands of times (maybe even at the same time in a concerted effort). Suddenly, the cost of that IP block might be a bargain for the attacker…

This is a good start, but still not impermeable.

I didn’t say impermeable, I said good-enough.  The loss in practice would be far lower than with credit cards.

(for example, by refusing to propogate word of the transaction at the vending machine)

No, the vending machine talks to a big service provider (aka payment processor) that provides this service to many merchants.  Think something like a credit card processor with a new job.  They would have many well connected network nodes.

Even better than an escrow, you just fund the beverage machine company itself.

Like this: you go to the company’s website and send them 100 BC. Then, they give you an ID. They have plenty of time to get confirmations to build, and when you need a beverage you just use the ID they issued you and they debit it from your account.

Yeah, that was my first suggestion, but a general purpose debit account would be more useful since it could be used at other places.

The solution is for the snack vendor to have debit accounts. You’ve got a fantastic vending machine at work, so you transfer 2000 bitcoins to it which can be withdrawn or spent at any time. Withdrawing the bitcoins takes about ten minutes, but spending them is instantaneous.

Quote from: satoshi on July 17, 2010, 10:29:13 PM UTC

The service provider has connections with many nodes. When it gets a transaction, it blasts it out, and at the same time monitors the network for double-spends. If it receives a double-spend on any of its many listening nodes, then it alerts that the transaction is bad. A double-spent transaction wouldn’t get very far without one of the listeners hearing it. The double-spender would have to wait until the listening phase is over, but by then, the service provider’s broadcast has reached most nodes, or is so far ahead in propagating that the double-spender has no hope of grabbing a significant percentage of the remaining nodes.

This is a good start, but still not impermeable. This kind of security relies on the fact that the majority of nodes (which really just boils down to the majority of IP’s) are honest. However, if the attacker could amass many IP addresses, then he could control the propagation (for example, by refusing to propogate word of the transaction at the vending machine), and still lead a successful double-spending attack. Which sort of brings us back to the main novel idea of bitcoin: truth is voted on by computing power, not IP.

For just a beverage, it may seem like this attack is uneconomical. But imagine if instead the machine dispensed small-denomination giftcards, and the attack was performed thousands of times (maybe even at the same time in a concerted effort). Suddenly, the cost of that IP block might be a bargain for the attacker…

For more expensive items (gift cards in large amounts) the business would have to decide if the risk was acceptable to trust the transactions or wait for confirmations. I imagine most business would take the risk until/unless someone starts ripping them off frequently. The real world analogue to this is checks, many business still accept checks, despite the fact that it can take days to determine if it was legit (ignoring the places that scan the check and run it as a debit). Some businesses have chosen to no longer accept checks due to the risk, others require that you provide additional information (DL#, date of birth, etc) in order to pay with checks.

If I were running a vending machine business I would assume (like I would today) that the vast majority of customers are not going to rip me off, and would accept the transactions without verification. Though I would of course use satoshi’s “good-enough” checking. For more expensive items I might require the customer register or provide some kind of state issued ID if they are unwilling to wait for the transaction to be verified.

Such a service which allows merchants and customers to have an account with the same entity for the purpose of instantaneous transactions, is being developed as a FOSS software system. We’re calling it the Bitcoin AH (Bitcoin Account Hub). See http://bitcointalk.org/index.php?topic=2628.0;all

I believe it’ll be possible for a payment processing company to provide as a service the rapid distribution of transactions with good-enough checking in something like 10 seconds or less.

The network nodes only accept the first version of a transaction they receive to incorporate into the block they’re trying to generate. When you broadcast a transaction, if someone else broadcasts a double-spend at the same time, it’s a race to propagate to the most nodes first. If one has a slight head start, it’ll geometrically spread through the network faster and get most of the nodes.

A rough back-of-the-envelope example: 1 0 4 1 16 4 64 16 80% 20%

So if a double-spend has to wait even a second, it has a huge disadvantage.

The payment processor has connections with many nodes. When it gets a transaction, it blasts it out, and at the same time monitors the network for double-spends. If it receives a double-spend on any of its many listening nodes, then it alerts that the transaction is bad. A double-spent transaction wouldn’t get very far without one of the listeners hearing it. The double-spender would have to wait until the listening phase is over, but by then, the payment processor’s broadcast has reached most nodes, or is so far ahead in propagating that the double-spender has no hope of grabbing a significant percentage of the remaining nodes.

I don’t know if it would be feasible, but here’s a proposal for real time confirmation:

http://bitcointalk.org/index.php?topic=4382.0

If it won’t work, can you explain why?

I believe it’ll be possible for a payment processing company to provide as a service the rapid distribution of transactions with good-enough checking in something like 10 seconds or less.

The network nodes only accept the first version of a transaction they receive to incorporate into the block they’re trying to generate. When you broadcast a transaction, if someone else broadcasts a double-spend at the same time, it’s a race to propagate to the most nodes first. If one has a slight head start, it’ll geometrically spread through the network faster and get most of the nodes.

A rough back-of-the-envelope example: 1 0 4 1ter 16 4 64 16 80% 20%

So if a double-spend has to wait even a second, it has a huge disadvantage.

The payment processor has connections with many nodes. When it gets a transaction, it blasts it out, and at the same time monitors the network for double-spends. If it receives a double-spend on any of its many listening nodes, then it alerts that the transaction is bad. A double-spent transaction wouldn’t get very far without one of the listeners hearing it. The double-spender would have to wait until the listening phase is over, but by then, the payment processor’s broadcast has reached most nodes, or is so far ahead in propagating that the double-spender has no hope of grabbing a significant percentage of the remaining nodes.

One more point I’d like to make is that 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 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.