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

How does the protection against double-spending work?

I apologize for the bump, but this has been done
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

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!)

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.

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)

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 didn't think about that but you're right.
What happened with the Account Hub project?

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

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.

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

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.

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.

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.

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?

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.

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.

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.

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.

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!)