Bitcoin Forum

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?

For low value items like that you would normally accept the transaction without any confirmations.  If the bitcoin node that the vending machine is talking to accepted the transaction then it's probably valid.  I think the only danger in that is if it was somehow double spent in a short time window - then it may never get into any blocks.  I'm not sure if that's really possible, maybe it is, but it seems like it would be hard to pull it off reliably.

I live near the East coast of the US and I've sent Bit Coins to friends on the West Coast, seems to be fairly instant as long as both clients are well connected to the network.

It will go instantly, but I think the issue is confirmations. Even if you accept just 1 confirmation it will take an average of 10 minutes to get it. In this time the cheater could go to another vending machine and then just let the two accounts duke it out for his one payment while he eats two snacks.

The first solution that comes to my mind is a "verified insta-cash: service. You ship them some amount, they verify it within an hour or whatever and give you a card with credits that goes into vending machines and such. Or you could have an account with the vending company. Or you could use some physical currency, we don't necessarily need just one type of money.

That might be a good experiment to try on the test network to see what happens. I think it both machines are going through the same node, then trying to double speed should be stopped at the first node if they both are connected to it first.

Oh, yeah. It doesn't have to be two vending machines though. I could even send the coin to my friend then immediately spend it at the vending machine. I think the way things are you aren't safe to release until the transaction is embedded in a block that the majority finds acceptable.

The problem with slow confirmations is because of a little amount of nodes. When Bitcoin will become somewhat popular, then you could get the confirmations much quicker (especially the ones in the limit of an ISP/city/region[or state]/country)

You can act on a transaction before it is included in a block.

So you can still check for double spending in all the transactions you can see already.

So to buy 2 snacks with the same coin you'd have to spend it at 2 distant nodes simultaneously and get your snack faster than the network propagation time.

So vending machines are easily possible and the scope of the attack is actually quite limited?

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. Or if not not the vendor, then perhaps there's a company called Bitcoin Escrow, which is trusted by both parties and perhaps regulated by the government. They hold bitcoins 100% in reserve and offer instant transfer of balances between customer/merchant/supplier accounts. Withdrawals and deposits take about ten minutes, but purchases are instant.

If the machine is setup to only connect to their node, that could work since it would be kind of a central spending point that would quickly be able to tell if someone was trying to double-spend the coin.

As for different networks and nodes, like Bob's Escrow is different from Jane's Escrow, the added delay would make a theoretical attack possible, but no one is going to get rich ripping off vending machines.

Perhaps there could be a variety of intermediary service providers that offer this type of 3rd party escrow service and the customer can decide which 3rd party they like to use and the vending machine can choose which 3rd party escrow services it is compatible with.  If the customer finds a vending machine that accepts using a particular 3rd party escrow, then the customer can buy from the vending machine.  Of course, it would be useful if the most popular/trusted/established escrow services are used both by vending machine and customer.

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 (http://bitcointalk.org/index.php?topic=376.0). 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.

The beauty of bitcoin is you don't need 3rd parties like banks.

I can see how an escrow could be useful.

Surely it's still possible to do this without one.
Adding an escrow will add cost to the transaction.

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.

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.

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...

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

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.

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

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 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?

There's some talk in this thread that portrays a future system that's any different than what it is today.

It doesn't have to be. And it probably won't be.

Waiting for confirmations to propagate is impractical for the same reason today's vending machines won't accept checks: Confirmation takes too long.

That's the whole reason why we have electronic spending with credit and debit cards. It's what enabled our fractional reserve system in a global economy. Your assets are just a number in a database that only represents Dollars, Bitcoins, and Zloty.

The instant transaction layer on top of Dollars and Bitcoins means that the actual transaction of real currency can take an arbitrary amount of time (if it even happens at all!).

Well, to pick nits here, it will actually take an average of 5 minutes to get a confirmation.

Person A walks up, the transaction is sent 30 seconds after the confirmation block, so person A waits 9:30. Person B's transaction is sent 30 seconds before the confirmation block, so person B waits 30 seconds. Average time: 5 minutes.

People, there's a simple way for transactions to become instant:  as mining becomes large and centralised, a protocol is developed for at least the majority of hashing power to be able to verify that it has received a transaction.  Then, an instant verification can be offered to the vending machine simply by confirming that the purchase has been successfully sent to the bulk of the network muscle--it will outrun any attempts to doublespend except under very rare circumstances.  That rareness allows the verifier to cover their risk with insurance and/or fees that would be very reasonable.

Yep -- a bitcoin backbone, one might call it.

No, blocks are generated at random times, not evenly spaced. From any point in time the average waiting time for the next block is 10 minutes.

Great, yet another centralized solution. With the corresponding drawbacks: If that mining cartel verifies that it has received a transaction, then it must consider it valid and will work on including it in a block. But maybe it only includes transactions with a certain minimum transaction fee. So I guess you have to pay the fee, if you want fast transaction... you want to opt out? too bad, all the merchants now only accept fast-lane-bitcoin-transactions because it's more convenient.

Competition drives down prices, but a verification service of this type requires you or your cartel to control 50% or more of the computing power. So naturally there can't be a competitor with lower prices. I'm not sure I like this outlook.

That's not necessary even - just a network (and many of those can exist) of a sufficiently high number of nodes (tens, hundred maybe now) that are not directly connected to eachother through the bitcoin network, which all verify that they have 1) received the requested transaction and 2) have not seen conflicting ones for a short time (let's say 0.5s)

A company could provide a service for verifying transactions, and for a small cost maybe give insurance against double-sent transactions for the seller.

It doesn't even need to be a separate network.  A major vendor (or a vendor associaction) has a dedicated server for a client without connection limits, and has established persistent connections to as many major generators as is possible, but also has a list of regular clients that are attached to it, or even a list of 'lightweight' clients that are multihomed.  When the vendor receives a transaction from a customer in the store, before approving the sale at the POS station, the vendor's client sends out a copy of the transaction to every major generator first, and then every regular client except for *one* randomly chosen multihomed regular client.  Then the vendor's client waits to see what transaction the randomly chosen client sends him.  If the chosen client sends back his transaction, the sale is golden.  If any other transaction for those coins come across, the sale is denied.  If nothing comes across for, say ten seconds, then you are in limbo; but probably still not at great risk because the client chosen randomly could have lost it's connection, etc.  It is necessary to not send the transaction to one client because clients don't forward transactions that are invalid, and the second transaction seen in a double spend attack is invalid.  If you send that customer's transaction to the generators, those generators will regard that transaction as the valid one anyway, and will not report to you any conflicting ones.  So by keeping one connected client in the dark, you can see if that client sees your transaction from the network at large, or another one.

No need for a parallel network, no need for a generating cartel, no need even for anything special beyond the function of the modified vendor's client.  It is likely that  insurance could be developed to protect against frauds, and this special client would be the insurance company's, but dependence upon a third party wouldn't be a practical requirement.

It seems quite unlikely to me that any one entity will ever control >50% of the network hash power.  But when, say, a hundred entities do, something like this protocol would be advantageous to all of them to develop were there to be sufficient demand.  The likelihood of all hundred groups agreeing to a pricefixing scheme is low, because it's unstable--any entity that decides to accept lower (but nonzero) fees can scoop up the transactions the others are passing over and make cash with which to increase their computing power, provided there is a difference between the average fee and the actual cost of that much computing power.

So, here is what I think will happen.  :-X Somebody will finally get serious and make a better bank than mybitcoin. Then begins the bitcoin bank competition. As a wise manager of money, I use this to my advantage and let them compete for my business. Vending machines will just need need these inputs from the user: the bank used ("MyBitcoin, Visa, MasterCard, etc."), user, pass, confirm. The vending machine will show the rates that they charge for using each bank as a function of how much the vending machine company trusts each bank. Think of bitcoin as gold and the online bitcoin banks as all the currencies in the world. I'm going to hold more of the currency that stays truer to the nature of gold.

I don't know how the interface would work, but I'm sure someone already figured that out.

No, the average time from one block to the next will be ten minutes.

My example was a little too simplified and misleading. Allow me to elaborate.

For any interval I between two blocks, if there are sufficient transactions occurring at random intervals within the block, then the average wait time will be one half of I. As the number of blocks increases, I approaches 10 minutes, therefore the average wait time approaches 5 minutes.

This all assumes we have a sufficient quantity of blocks and transactions that the average is meaningful (or, for the pun-minded, that the mean in meaningful :-) and that transactions are spaced at random intervals, and difficulty is reasonably constant, and probably a dozen other assumptions I can't think of off the top of my head.

Oh, and of course, you can't apply statistics to a single instance, so the average is meaningless. I think I saw one block that had a 50 minute gap before it. Pity the poor person who's been waiting 49 minutes for a confirmation....

This is precisely one of the reasons why advocates of a central monetary authority (like the Federal Reserve) want to keep a unary legal tender.

You can't arbitrarily inflate or manipulate a currency when there is no barrier to using other currencies.

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.

But dropping the transaction penalizes the recipient, not the sender, right?  It's bad enough that the second recipient gets screwed out of the bitcoins.  Why would you want to double the amount of innocent victims, by also penalizing the first recipient?

I think you are trying to hurt the sender by locking up the coins, but I'm not sure your proposal achieves that.

(then again, I'm still a newbie, so pardon my ignorance, if I'm wrong!)

I believe this would be in the context of the snack machine and fast payment processor.  Since there is only a few (~15) second window for double-spend you don't dispense the sugary snack until that amount of time has passed.  If you do detect a double spend you block the coin and don't dispense the healthy/sugary snack, no one but the malicious owner is affected.

I'm sure a payment processor could block the coin within it's own network, but it could still get in someone else's block later.  If everyone blocked it then in the case you're speaking of, outside of the snack machine context, both recipients would get screwed.

Exactly. This all happens in 15 seconds. After the 30 second window the second spend is ignored and the original is not dropped. The idea is you want to make sure most of the network knows the original spend and no one detected a double spend.

After 30 seconds almost all nodes know the original spend and ignore any second attempt to spend. Any second spend would have a very hard time gaining momentum. Eventually, in about ten minutes, the original spend is locked into a chained block, so I don't think a second spend could get in later.

Isn't it the case that a node seeing a second spend attempt will not broadcast that transaction?  In which case a double spend will look like a single spend to most of the network, since they will only see one of the two transactions.

I note that there is an ERROR type for inv messages.  Could this be pressed into service to announce transaction rejections because of double spends?

Then a vending machine, say, would only have to wait for the network propagation time to pass (let's hope it's seconds) and look for an ERROR inv that lists coins they think they've received.

It would go like this:

• Node receives an inv then tx which spends coins that it already has seen a pending tx for
• Node sends back to the sender an inv with ERROR for that tx hash.
• The sender requests the ERROR transaction and sees that it's transaction is therefore in error too, and forwards the ERROR rather than the tx.
  

I'd have to think about which transaction gets announced as an ERROR, but this method would allow a node to announce a double spend, and be sure it would propagate.

Note: it wouldn't be enough to receive an ERROR to trigger the invalidation of a transaction, because that would make it possible to invalidate any arbitrary transaction.  Receipt of an ERROR inv would mean the node had to request that transaction and examine it themselves.

This is correct, a node won't forward a transaction that it considers invalid, and by seeing another transaction that spends those same inputs, the second transaction is invalid.  It probably wouldn't need 15 seconds even if the network were huge.  Transactions propagate very fast.

This doesn't actually require someone to hold your Bitcoins to confirm. Here's my solution to this problem.

1. A trusted third-party is chosen. This third-party does not have to be trusted by the person paying the snack machine, just by the person who owns the snack machine.
2. At least an hour before the tasty snack purchase, the hungry customer-to-be sends a transaction with an input to the value of the maximum he wants to spend on merchants trusted by the third party. The script requires a signature from both you and the third-party before any outputs can be added, and if it isn't claimed after a certain period (like a month) it's refunded to you.
3. You wait for this transaction to get 6 confirmations.
4. You go to the snack machine and your phone prepares a transaction with the price of the snack sent to the merchant, and the rest sent back to you as change. You sign this transaction and send it to the third-party.
5. The third-party signs it, releases it and gives the snack machine the green light to sell you tasty snacks.

If the third-party is unable or unwilling to sign the transaction, the money is eventually refunded to you.

The point of this is that the third-party will only sign one transaction for that input, and therefore it can't be double-spent, so long as the third-party is trustworthy.

Thoughts?

That's basicly escrow, but it doesn't solve the fast transaction problem because if you knew that you were going to want something from a snack machine in an hour, then you don't really need rapid confirmations anyway.

It's not really escrow, because the third-party only checks whether it has signed this transaction already.

Anyway, the idea is that many services will use the same third-party. So you'll just need to know whether you'll want something from anything in an hour. You could do this at the start of the day, for example.

You insert the credit card into the machine, you enter your password and buy whatever you want. The machine contacts your bank with the payment, and the bank provides the machine a wallet.dat with the exact amount to pay (or a number of wallet.dat). The machine has to recognise the bank as a trusted third party, otherwise the bank could have spent some money that has not been confirmed yet.

Why would it provide a wallet.dat? Wouldn't just the transaction suffice?

Well, if the payer wants the third party to give him the change and to refund if necessary, I think the payer needs to trust the third party too.

I'm pretty sure your argument is wrong, by the way. No matter how long it's been since the last block has been generated, the average time until the next block is always ten minutes (plus or minus any change in network hashing power since the difficulty adjustment). This is kinda counter-intuitive, but it has to be the case because the probability of a block being generated in any given second is not in any way affected by when the last one was generated.

The basic flaw here is that the probability of your craving for a sugary snack falling in any one interval of time between consecutive blocks depends on the length of that interval of time. Your purchase is less likely to fall within one of the shorter periods between two consecutive blocks and more likely to end up in one of the longer ones. This would be quite difficult to calculate, but fortunately we don't need to because we know the next block is always 10 minutes away on average.

A third party handles the transaction like a debit card/credit card company and assumes the risk that a person double spends in a ten minute window, just as a credit card company assumes the risk that a person spends up to their credit limit and defaults. The intermediary can verify in seconds that the funds exist in the customer's account and informs the merchant of this.

I didn't think about that but you're right.
What happened with the Account Hub project?

It should be quite easy:

1. Pick an address with enough coins, send all the coins to another address you own.
2. Send the amount to the vending machine also.

I don't really like the intermediary account-idea. It undermines the decentralized nature of bitcoin.

What about some kind of honour system? If it's the tenth time you bought something at this vendor machine with the same address, it might be a good idea to trust the user more.
Or maybe make people register? (That would be bad for the anonymous part of bitcoin, though. Just like an intermediary service)

This.

At the moment, in the interest of spam reduction the network has a policy of not infoming the rest of the network in the event of a double spend, I think this is a bad idea long term, we need a forward on blind request and a double spend warning message that will allow everybody to see bad transactions.

A double spend is not an invalid transaction so much as it is a possibly valid crime-scene forensic evidentiary transaction plus if it is somehow not a crime scene evidence item it is very likely a debugging the network evidence item.

If the first case, deliberate, premeditated conspiracy to suppress such evidence might be a crime in some jurisdictions; if the second case, it might be a crying shame to the debug the network community...

-MarkM-

EDIT: Possibly anonymity versus law problem: if you DO forward it, knowing it might be forensic evidence, laws about chain of custody might apply, making it a crime not to sign reciept of it so forensic teams know you handled it and trace it back to the actual crime-scene.

(P.S. As far as I know I am not licensed by any generally-recognised sovereign nation on this planet to practice law on this planet.)

(P.P.S. Need the police, FAST? Quick, double-spend!)

I apologize for the bump, but this has been done 8)
There's also a good (albeit too detailed for the average consumer) explanation of how it works in the video.
http://www.youtube.com/watch?v=pDOcLros-w0

How does the protection against double-spending work?

Wrong.
The word "confirmation" means "block"  ;)

Why doesn't someone who wants to operate vending machines also operate a mining rig that specifically prioritizes confirms from transactions from it's vending machines?  This way, it could release the goods immediately from receiving the btc and then expedite the confirmations thus minimizing risk of double spends.

Because you don't know how mining works  ::)

why doesnt someone that wants to operate vending machine have a small service where people put in pocket amount of funds in per day while taking a shower in the morning EG 0.1BTC which get pre confirmed into the service. then the funds are ready to use throughout the day

and the balance is deducted when they scan qr codes from the vending machine.

then they can expand this pocket money service to also cater to a payment gateway for starbucks, 7-11 etc..

i wouldnt call it a bank i would call it more like a prepaid service. much like how people use oyster cards in london to pay for train tickets and other things.

5/10 - this prohibits "impulse sales" which are HUGE in snack and beverage industries.

Is not needed. If it's done right, the vending machine itself doesn't run a BTC client, but receives a paid notification from the vending machine company server that runs the node and is located elsewhere, which would be a good protection against a race attack as you can't make sure miners get the double spend transaction first (the vending company node gets the double spend transaction before the "valid" one).

Therefore leafs only the Finney attack which requires a pool or very large miner to participate to even have a slight chance of success. Which is obviously to expansive to get a bag of popcorn for free.

Also, real cool machine. This could be a great advantage for the snack industry as no money has to be stored on this machines if the machine doesn't contain any private keys, which would be unnecessary anyway.

You just described green addresses.

i think it is the solution to those kind of problem.

Otherwise i'll allways be able to give my private adress to 10 friends buy a snack, send a txt to them and they all go to buy a snack with the same private adress. If i send the txt message before buying the snack i can even get poeple using that private adress in china at the very same moment i use it in london so it might be very hard to be instant AND secure without green address.

Unfortunately there is a long distance between a "race attack" and a Finney attack.
1. Long chain of fee less unconfirmed truansactions challenged by one fat fee transaction sent directly to big miners
2. No 1 combined with a tx in midstrean with nlocktime.
3. One tx sent directly to snack server, conflicting tx sent to 1000+ nodes
The list goes on.
Protecting against zero confirmation transactions is a never ending battle, like spam mail. Attackers/defenders improve, you are never 100% certain.

A double spending attack is much harder, even while duping snack machines, than your scenario implies.  There are techniques for detecting a double spend attack while in progress that can be employed, none of which are necessary yet, and thus have not been implimented.  Several of which don't require any outside support for the snack machine, and provide no warning for anyone that does not have a sniffer on the machine's network connection.

A double spend attack is very timing dependent, and for practical reasons requires that all spend attemps hit the bitcoin network within 10 seconds of each other.  Good luck coordinating that in meatspace.

No meatspace POS system shoudl ever accept any transaction that is not immediately lockable.  This should be obvious enough.  Snack machines shouldn't take IOU's.


Maybe, but as far as I am aware, both the race attack and finney attack are theoretical.  Are there any examples of either being employing in the wild, that does not involve a contrived lab-like setup?  Has anyone, ever, posted on the forums with a "I've been double spended against!" with a credible story?  Online websites should only accept 6 confirms for instantly deliverable goods such as online data streaming, etc; (maybe not a movie, since a double spend simply cuts off the feed halfway through the movie) but meatspace transactions below a certain value are pretty safe.  It's technically simplier to fake a coin operated snack machine using slugs than to double-spend attack it for a bag of chips.

I would love to hear the SatoshiDice developer's take on this and pick his brain.
They (if any) have the experience in the field of accepting zero conf transactions.

How about this:
SD winners/loosers are determined by value of the TX hash and some secret (to be revealed the next day).
If I am among the first to relay a SD TX I can actually alter the TX hash without invalidating the TX (by for instance altering the DER encoding and yet not invalidate signatures) before relaying it to 1000+ nodes. This gives me a high probability of getting my altered TX into the block chain.
Which of the TX hashes should get the winnings if they are determining the outcome on zero confirmations? (No, I wouldn't gain anything from this myself other than the thrill as I wouldn't be able to change the inputs/outputs without invalidating the signatures)

A similar approach would probably confuse many services around as the two TXes would not be a double spend, but just a different variety of the same TX with a different hash.   

Haha, nice catch phrase for chronocoin: "The original bitcoin snack machine"

Vending machines get robbed all the time, I don't think that the 4 people in the world who know how double spending is done properly will hurt the owners of the machine.







P.S. I know more than 4 people was being sarcastic.
P.S.S its no different than when you watch a video on youtube that shows a button combination that spits out money, and free drinks.

Merchants will easily accept the double spend risk.

$20 or less - 0 confirms (similar to no signature required on VISA/MC)
$20 - $300 - 1 confirm
$300+ - 6 confirms

How many confirms for 15 purchases $20 each ($300 total)? 0 or 6?

You have a point. After your comment, I realized there are probably a lot of things regarding bitcoin that I only have a cursory knowledge of.  So, I started to do some research to try and catch up.  Any response to help verify or dispute my understanding would be greatly appreciated.

The first thing I started with was the Satoshi original white paper. Something stood out to me, in section 8:


This sounds very similar to what I was describing, except exchange miner with node.

So then, I thought to myself: well, what is the difference between a miner and a node? This is something I always assumed was the same thing.

But, AFAIK, it would seem that a business would be wise to run a node for speed and security. Wouldn't businesses do this in the future and wouldn't that in turn become a lot of the power of the network, even when there are no more block rewards.

To make it more effective, you would verify your own transactions faster than others. I suppose it would be difficult to single out transactions from their business; so like, confirm the vending machine transactions before others.  Would that be possible?  Could the miner single out transactions that are a certain value, technically?

The whole double spending issue from what I can see is that anyone can send out the same allotment of coins multiple times by using different clients with the same private key imported.

The only problem is only one of the recipients will get the confirmed one. so I still would not risk a zero confirm transaction, instead a vendor would work best if they had a micro-bank/escrow/prepayment service. Just for depositing 0.1btc in each day, which gets confirmed by the microbank/escrow/prepayment service and then when the transaction goes through, the vendor collects the fully guaranteed funds instantly.

So this is an opportunity for someone with high trust to create a prepayment service where franky1 suggests

I can see starbucks, vending machines, train stations, etc all taking on the prepayment service as their payment gateway

For small transactions, you actually don't need to wait for confirmations because chances someone will do a double spend for a chocolate bar are pretty small and if they would succeed it isn't a huge loss.

What if someone does it 1000 times in a row? It's digital world, almost anything can be easily replicated, especially algorithms.

Profit margins should be good enough to cover the odd case of fraud.  I would imagine it would be possible to get some sort of insurance to cover a major scam.

Some sensible checks can be put in place for detecting abnormal behaviour.

If there is any serious risk, install CCTV.

Yeah I think the solution of just accepting without any confirmations is fine for such low-value items.

yeah... just wait for a double-spend app in google play..

satoshi solved the double-spend problem in a distributed network and you guys don't think that confirmations are important?  :-\

Imagine this:
- you install easy double-spend in your smartphone
- you send 0.0001btc to a "community wallet" address
- other people around the world using the same app do the same
- when it reach 0.01btc an alert is broadcasted with the private key so everybody spend at the same time the 0.01btc
- everybody gets a chocolate bar for 1 cent, and easy double-spend keeps a commission :)

Yeah pretty easy...all you got to do is get everyone using the app around the world to hit the button on the vending machine faster than the internet between machine...so what's that maybe 300ms...no problem...:D

Plus all the machine would need to do is delay the candy bar falling for a couple of seconds and verify no double spends.

you are wrong: the propagation of a new spending is not 300ms

Plus the vending machine company could just setup a centralized database to record transactions, independent of the blockchain, so in order to even attempt a double spend you'd have to find 2 machines which were not utilizing the same database.  So it's fairly conceivable that all vending machines could utilized the same shared database.

For example you try to buy candy the transaction is not only sent to the bitcoin network, but also stored in the vending central database, if you were to attempt 2 transactions at the same time on different machines, only one could be inserted into the database, so first one into the database wins.

yeah I think that's an acceptable workaround, actually I was going to suggest a centralized service for syncing the mempool... but then everybody should start using this centralized service if they want to accept 0 confirmations, and that's not so cool..
probably in the future bitcoin will be just a backbone for this kind of services

I for one do not know of any vending machines connected to the internet, so that seems like the first problem to solve...

Sure they do. They send messages to say they need restocking, or out of change.
They use GPRS mostly.

We'll just give the midget inside a smartphone and a bitcoin app.

Yes and no.  This is more like the Walmart versus target contract mining issue.  Use the search function against "walmart" and my screenname, and you will find that I have commented along these lines extensively in the past.

Not a centralized service so much as a combined contract mining agency & insurance agency.  You pay a small monthly fee, and it becomes the insurance agency's problem that your vending machines don't get double spent against.  Your machines connect to the agency's servers, which then make every effort to get those transactions out to the largest of the mining pools as fast as possible, in order to limit the risk of being the loser in a double spend.  Agencies also might trade lists of addresses that have been known to attempt a double spend, and therefore flag those addresses should they pop up in their customers' machines.  There are many ways to undermine the likelyhood of success of a double spend attempt.

Wohoo Satoshi come play at our casino!  :D

A node keeps the block chain, and propagates new blocks.

Miners get their work from nodes.

A merchant wants to have a node, so that they can be responsible for making sure that their transactions are broadcast to miners.  But this does not mean that the miners will accept the transaction when it reaches the node they are mining from.  There are several reasons ranging from not enough fees to finding a valid block before re-writing the current work to include your transaction.

A merchant can also be a miner, and attempt to encode either all transactions or even just their own transactions into a block.

But there's no guarantee that they will find the next block, or even one any time soon.

So neither running a node, or mining yourself, becomes a guarantee against a double spend made on someone else's equipment (vending machine, online merchant, whatever).

It's not directly possible to directly affect the "speed of confirmation" for your own transactions except by adding masses of your own hashing power to the overall network (as a miner, not a node). And if you overdo that you'll just push difficulty up and start the cycle over.

You increase the "speed and security" of transaction when you run a node by ensuring that your transaction gets delivered and included in the workload of as many miners as quickly as possible.

As to whether or not a vendor, or third party can selectively decide what to add to a block, they sure can.  But it doesn't mean they can just add that block to the block chain.

hth

^what coinerd says^

maybe an alternative fee service could solve this: the company could pay some amount of money to the main mining pools to include every transaction made to their addresses

Or simply pay an access fee to be a first tier peer to one or many of the largest mining pools.  If you think about it, BTC Guild could crediblely charge a small monthly fee for peers to be added to the top of their peer list, garranteed to have the highest connectivity (wherein free peers might be throttled, or not even able to connect continuously).  Logically, the major mining pools already have direct peer connections to each other, so a direct peer connection to any of the top five would only be a single hop connection to the lot.  Such a direct connection would be of value to any retailers that accepted zero confirm transactions, which would likely be the norm for meatspace retailers like Wal-Mart should they ever start accepting Bitcoin directly.

Put a notice on the machine "any bitcoin coming from an address with unconfirmed transactions will not be accepted and refund may not be processed in real time-you have been warned."

you are all thinking first generation bitcoin transactions based purely on the blockchain. I still think a reputable vending machine will add a loyalty/membership card system where you deposit bitcoins to your membership balance and then the machines deduct the amounts from the membership balance. off the blockchain.

That way coins are preconfirmed when you have deposited your funds into your balance and you are spending the coins much like MTGOX/BTC-e using databases not blockchains for internal transactions.

At my work we are given a Kenco card which has a 2 free coffee's per day and then any other coffee's add to a balance which you pay off on payday.

Who is going to do a double spend attack to buy some skittles....  ???

So I risk the value of a massive amount of hardware i would need to have under my control for a 50 cent bag of candy... lets be rational here.  Just check their public key to ensure they have enough btc, and give them the candy.

I would certainly not use a vending machine where I need a special card. Vending machines are something I use in some cases when I want the snack the fastest and easiest way. Having to add credit to a card negates both qualities.

to do a SUCCESSFUL double spend requires alot of speed and hardware. but to send out 2 transactions to 2 different addresses using 2 clients but only using one private key supply does not require expensive equipment. A successful double spend requires a confirm on both sides. meaning the 10 minute wait. but sending out 2 transactions that don't require waiting the 10 minutes is piss easy.

accepting unconfirmed transactions should only be allowed on products with delayed delivery. such as bitpay which can inform merchants that the payment has failed in 10 minutes and the merchant still has time to email the customer to attempt the payment again before losing their next-day delivery slot.

it is never EVER acceptable for instant access content.

examples.
if i sent
0.1BTC from 1HomeMachineAddress to 1VendMachineAddress
0.1BTC from 1HomeMachineAddress to 1VendMachineAddress

one of those transactions would instantly be ignored as it would appear as just an echo of the other, where many nodes pass around the same transaction (to avoid repeats)

but if i sent
0.1BTC from 1HomeMachineAddress to 1HomeMachineAddress
0.1BTC from 1HomeMachineAddress to 1VendMachineAddress

it would appear as 2 different transactions and would require a confirm to sort out the mess (10 minute wait)

Right but you are assuming that the receiver is not checking the balance on the address and that the user has spent in excess of the balance.  That is not hard to do...


If my address has 1 btc and I have 2 tx for 1 btc each... the receiver can tell me to wait 10 minutes....  honest actors are not going to do double spends...

accept 0 confirm, but have a camera taking buyer face, and having show ID, and have an algor to check if both match

I still think an outright rejection for addresses with unconfirmed transactions is the most pragmatic way to go, buyers should be warned with notice that refund cannot be processed immediately.

At some point there is some level of trust that comes into play... and I know having merchants in my own family that they are not going to care beyond checking that an address has enough to spend with my unconfirmed tx when it comes to small ticket items like a magazine or pack of cigs.  Plus most of their customers are repeat...

Even with physical money the merchant trusts that the money is not counterfeit, and with credit cards that the card was not stolen and unreported.  So the only way to really pull this off is combined with a 51% attack and anyone who owns equipment to do that would be jeopardizing their own investment...

For larger transactions they take so much time that by the time the tx is done the confirms have come in.  Have you ever bought a house or car or really nice jewelry in 5 minutes?  No that stuff all has paperwork and packaging that happens and can take some time.

Yea I agree that way the machine is not in a locked state waiting for the confirms

Not easy.  Let me se you try it.


It's fine for a great many things.  A movie streamed over the Internet, for example, because it can be cut off if a double spend is detected.  Game or digital content licences (on Steam or iTunes for example) can be reversed.  Online services (monthly access, or even daily access) can be reversed.  All of this with a simple transaction, not using blockchain enforcable contracts.

https://en.bitcoin.it/wiki/Contracts

Using contracts, particularly example #7, opens up some rather creative solutions beyond the simple transaction.  The "loyalty card" system can be implimented within an android phone, without a actual card, and the balance revoked at will, so one could use it as a running balance for a vending machine at work as easily as one could use it at av ending machine that they never expect to visit again.  One could use #7 to pay for gasoline at the pump, again without a 10 minute wait.  Even the most basic contract is significantly more difficult to "double spend", and may actually be mathmatically impossible under certain conditions.

Who the Hell submits to being pictured and giving away a photo of their ID for a freakin' candy bar? I don't like people looking at my ID, much less getting a scanned copy. I'm still uneasy about having submitted ID to sites like Gox. Anyway - the cost of adding all that would be pretty ridiculous for a candy vending machine.

Anyway, I compared this to personal checks in a (newer, actually) thread. Many stores accept personal checks (usually up to $xxx), and many also do their own version of KYC (see MoonShadow above). If a customer turns out to be a frequently-thieving assbag, you ban them from your store. In the case of vending machines, I'd guess they'll just have to accept the risk or use ZipConf-like insurance. For workplace vending machines, you can do something like lock out the machine until a tech visits it when a double-spend is detected, so the thief will gain the ire of their coworkers, and pressure to stop doing it. If it continues and company management does nothing, the vendors can simply remove the machines and put them to work somewhere else. I think most physical and low-cost/high-volume companies will find the risk exceptionally low.

Companies don't need to, and frequently do not, operate on the premise that their customers are thieving assholes, with the exception of many IP distributors, and if a company thinks Sony BMG is a good model to emulate, keeping them out with uneasiness over risk of double spends is fine by me.  :)

Two things.  First, I seriously doubt that double spends on a $2 candy bar are going to be common enough that they'll be a problem.  At worst, the seller bumps the price up 10 cents to cover the cost of fraud and nobody really cares.

Second thing is a simply solution is a phone wallet that automatically creates a transaction to split up its funds into addresses each with only a small amount in them, and then what you would do is send the machine a QR of your private key for one of the addresses and a public key for returning change, and it creates the transaction and sends you the change.  This way it knows the transaction is valid, and it can wait 5 or 10 seconds and see if a double spend transaction shows up on the network.  At least this way, it will be somewhat more confident than it would be by you send it the transaction, but obviously, the only true confidence is a couple of confirmations.

Ripple, obviously. It is credit while the underlying currency settles.

Yes, true. Ripple solves this problem.

For the sake of the Bitcoin only argument, though, I think the idea of verifying unconfirmed transactions would be useful.

My company is considering blocksplit insurance. basically allowing everyone to accept 0 confirmations and be insured if a bad actor began double spending or going off on their own chain

just not sure what people would pay for that

In truth, there are several ways to solve this problem.  I expect that most will be tried in some form or another, and the best solutions will come to dominate, and most clients will evolve to be able to use those methods.

I'd say that one half to one full percent of the purchase price would be about right.  That's about what the credit card companies charge to deal with fraud, and I wouldn't expect that zero-conf frauds would amount to greater rates of fraud.  Start at one percent, and see how profitable you are.  If it's profitable enough, some competitor will come along and force you to lower your rates.  If it's not profitable, you'll stop doing it too.

Sorry for bringing up this very old discussion. Just wanted to see if there are any new solutions to this problem. I don't mind buying a can of coke from the vending machine with my mobile wallet.

Yes, there is a solution without 3rd party payment processor. Finally.
http://www.dashndrink.com

This is nice but the machine works whit dash and no whit bitcoin, does InstantX works whit bitcoin? at most we will use to change shapeshift btc in dash before purchase

Well, satoshi said bitcoin technology is an experiment. Dash uses this tech and explore ideas which would work in decentrilised way.

Do not say this is impossible but This could be cool!

There would be this website with its own bitcoin card that you could load with your bitcoins! This card will be loaded once the confirmations were confirmed and then you can spend your bitcoins anywhere without your phone! They wouldn't need confirmations but it could take up to 2 minutes so the machine sees what your balance is and then deducts what you bought (plus the 2 transaction fees (#2 being the card company he's some extra money from that purchase)) from your balance and then you walk away with your item!

Yes more stuff would be needed but it's a great idea!

Yeah exactly. They would probably just put a QR code on it and you scan it and send the Bitcoin.

Just use a off-chain solution like Xapo with instant transaction confirmation. You get people to sign up for a Xapo account and then have them use their Xapo debit card to pay for the stuff they want to purchase from these vending machines.

Once this takes off, Xapo could form a partnership with these vending manufacturers and arrange for discounts on fees for these micro transactions. At this stage all in card spending <off-chain> is free. Correct me if I am wrong.

There's a huge problem with this solution. We're using Bitcoin, not services that uses Bitcoin like a debit card. By giving your coins to Xapo, you are allowing them to monitor your spending habits and even control your coins fully. There are major privacy and security concerns regarding this. Xapo debit cards uses Visa and is thus not fully a Bitcoin solution. Offchain transfers are usually free for everyone. However, a better solution would be to implement counter measures against double spending and still accept 0 conf transactions. The risk is relatively low.

You need to wait 10 minutes. Best create a website where person can order the food in advance and buy it for write a password to the machine.

Bitcoin will never be instant regardless of block size or network configuration. The number of nodes has nothing to do with confirmation times.

We could have 10GB blocks and a Million nodes and we should still have an average wait time of 10 minutes for each confirmation with a recommended minimum of 10 confirmations before you consider your transaction complete and irreversible; for this reason Bitcoin will never be used for payment in a snack machine.

This might be achievable if you're using an offchain Payment processor like BitPay or Coinbase to send the payments to, but you get the product usually after few transactions or zero transactions, Maybe I think it's called off chain transactions. I wonder if that could be implemented to speed up the transaction problem with your vending machine.

I do not agree with solutions like this, because we deviating from the Bitcoin path and introducing 3rd party services to solve problems that could have

been solved by our own developers. These guys are testing sidechains and other solutions for problems like these. We have to chose which role, we

want Bitcoin to fill. Option A - Payment processor for micro payments or Option B - Cheaper Remittance service and investment

commodity. If we want to do both, we would need to make some compromises somewhere else.   :(

Nearly instant, they said... :(

Actually, 6 confirmations is pretty much secure with the only risk being major block re-org and 51% attack, both of which are hard to execute. 51% attacks are nearly impossible to deter unless the TX is included in a block before the last checkpoint. Other than that, transactions proporgate instantly and brick and motar merchants usually release the goods once they verify that there is a high chance that it won't be a double spend.

"Never say Never".. Do you know how many people have eaten their words by so arrogantly blurting out things like that?

Confirmations flood in fairly quickly, and IMO bitcoin isn't ready for "mass-adoption". Obviously the capabilities of the protocol aren't perfected, because this is a work in progress. Bitcoin is being improved every single day, gaining attention, supporters and developers.

Imagine how many people 200-years ago we're talking about the impossibilities of a snack machine AT ALL, because nobody could be trusted to leave the cash, or because "In-The-Air" transactions weren't "possible".

I think this will be good option to give instant service. Bitcoin payment can be good option for online ordering service, you order and get things delivered. Or it can be using multisign address to pay fully after both parties agree to do deal.

Only an hour then. cool beans.


Because payment processors :)
https://www.reddit.com/r/Bitcoin/comments/40ejy8/peter_todd_with_my_doublespendpy_tool_with/cytut1p

I think this is the best solution.

And also I think that creating such Bitcoin snack machine nowadays may be a good start for a business: people would use the opportunity to buy a snack with Bitcoin even if they normally wouldn't the buy snack, just for fun. Someone should try to make it real.

You can wait until the lightning network is working so we can have this type of super fast 0 confirmation while secure payments, until then i would not worry a lot about it, we can't deal with this type of thing using on-chain transactions.

The price of a snack is an acceptable risk to accept payments with 0 confirmations.

Shapeshift deactivated 0conf as users were exploiting miner's differing policy to accepting transactions. It can easily be migrated by requiring a conf for those TXes that miners are unlikely to accept. ATMs are the likely victims and for vending machines, not so much.  The double spend above is more for 0 conf than 1conf+. It is safe to assume that transactions with 1 confirmations are hard to reverse unless there's a fork.

If you did that, no one would want to use the snack machine anymore. That process is way too long.

Double spend and get free snacks all-day. A lot would actually do this which makes the no confirms possibly a bad idea.

And how much for the transaction fee?  I don't know, this is kind of like the idea of the bitcoin arcade that was floated on here recently.  It's just so much easier to use quarters or dimes in a vending machine.  And pocket change is completely anonymous unless the vending machine has a camera on it.  There are some things bitcoin is not practical for, and this is one of them.

You can do it like in Japan with those IC cards you can recharge with FIAT (SUICA, PASMO). Just make it works with Bitcoin, load a card you can use everywhere (vending machine, convenience stores etc.) and it will work well. Of course, that does mean a 3rd party is involved with off-chain transactions.
Or we can just wait until developers figure out how to make fast and secure transactions for everyday expenses.

Aw. I thought you were actually going to post an actual photo of a Bitcoin snack machine. Either way, this discussion is fine without it.


I think it'd work by entering a code, entering your address then taking the funds out to give you a candy bar.