Topic: Bitcoin snack machine (fast transaction problem) - page 2. (Read 55211 times)

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

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!

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

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

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

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.

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.

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.

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

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.

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

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.

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. 

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.

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

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.

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.

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

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

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)