Bitcoin snack machine (fast transaction problem)

[ffe]

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.

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.

[realnowhereman]

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.

[MoonShadow]

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.

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.

[ArdaXi]

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?

[MoonShadow]

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.

[ArdaXi]

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.

[Findeton]

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.

[ArdaXi]

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?

[jtimon]

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.

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.

[makomk]

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

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.

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.

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.

[tymothy]

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.

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.

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.

[jtimon]

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.

Yes. And the big mining pools are in a perfect position to provide this service, because they can immediately confirm that they haven't seen a double-spend, and that they will reject any double-spend that they do see.

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

[bcearl]

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.

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.

[skerit]

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)

[WNS]

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.

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.

[markm]

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

[nimda]

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

[Come-from-Beyond]

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

How does the protection against double-spending work?

[Gabi]

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)

Wrong.
The word "confirmation" means "block" 

[LeTanque]

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.