Bitcoin Forum
November 10, 2024, 08:47:24 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 2 [3] 4 5 6 7 »  All
  Print  
Author Topic: Bitcoin snack machine (fast transaction problem)  (Read 55303 times)
ffe
Sr. Member
****
Offline Offline

Activity: 308
Merit: 250



View Profile
May 25, 2011, 05:50:15 AM
 #41



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
Hero Member
*****
Offline Offline

Activity: 504
Merit: 502



View Profile
May 25, 2011, 12:08:32 PM
 #42

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.

1AAZ4xBHbiCr96nsZJ8jtPkSzsg1CqhwDa
MoonShadow
Legendary
*
Offline Offline

Activity: 1708
Merit: 1010



View Profile
May 25, 2011, 04:45:00 PM
 #43

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.

"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."

- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
ArdaXi
Newbie
*
Offline Offline

Activity: 11
Merit: 0


View Profile
June 10, 2011, 08:16:33 PM
 #44

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
Legendary
*
Offline Offline

Activity: 1708
Merit: 1010



View Profile
June 10, 2011, 08:30:47 PM
 #45

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.

"The powers of financial capitalism had another far-reaching aim, nothing less than to create a world system of financial control in private hands able to dominate the political system of each country and the economy of the world as a whole. This system was to be controlled in a feudalist fashion by the central banks of the world acting in concert, by secret agreements arrived at in frequent meetings and conferences. The apex of the systems was to be the Bank for International Settlements in Basel, Switzerland, a private bank owned and controlled by the world's central banks which were themselves private corporations. Each central bank...sought to dominate its government by its ability to control Treasury loans, to manipulate foreign exchanges, to influence the level of economic activity in the country, and to influence cooperative politicians by subsequent economic rewards in the business world."

- Carroll Quigley, CFR member, mentor to Bill Clinton, from 'Tragedy And Hope'
ArdaXi
Newbie
*
Offline Offline

Activity: 11
Merit: 0


View Profile
June 10, 2011, 08:37:18 PM
 #46

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
Full Member
***
Offline Offline

Activity: 126
Merit: 100


View Profile
June 10, 2011, 08:50:20 PM
 #47

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.

Bitcoin Weekly, bitcoin analysis and commentary

14DD7MhRXuw3KDuyUuXvAsRcK4KXTT36XA
ArdaXi
Newbie
*
Offline Offline

Activity: 11
Merit: 0


View Profile
June 10, 2011, 09:03:53 PM
 #48

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
Legendary
*
Offline Offline

Activity: 1372
Merit: 1002


View Profile WWW
June 17, 2011, 07:25:43 AM
 #49


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.

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
makomk
Hero Member
*****
Offline Offline

Activity: 686
Merit: 564


View Profile
June 17, 2011, 12:20:55 PM
 #50

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.

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
tymothy
Full Member
***
Offline Offline

Activity: 224
Merit: 100


View Profile
June 17, 2011, 01:48:39 PM
 #51


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
Legendary
*
Offline Offline

Activity: 1372
Merit: 1002


View Profile WWW
June 18, 2011, 11:33:41 AM
 #52

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?

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
bcearl
Full Member
***
Offline Offline

Activity: 168
Merit: 103



View Profile
June 18, 2011, 11:44:24 AM
 #53

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.

Misspelling protects against dictionary attacks NOT
skerit
Newbie
*
Offline Offline

Activity: 20
Merit: 0


View Profile WWW
June 18, 2011, 12:03:40 PM
 #54

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
Newbie
*
Offline Offline

Activity: 39
Merit: 0


View Profile
June 18, 2011, 01:43:07 PM
 #55

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
Legendary
*
Offline Offline

Activity: 3010
Merit: 1121



View Profile WWW
August 07, 2011, 09:43:09 AM
 #56

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


Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
nimda
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1000


0xFB0D8D1534241423


View Profile
May 31, 2012, 11:22:20 PM
 #57

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

Activity: 2142
Merit: 1010

Newbie


View Profile
April 30, 2013, 09:28:34 PM
 #58

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

Activity: 1148
Merit: 1008


If you want to walk on water, get out of the boat


View Profile
April 30, 2013, 09:34:56 PM
 #59

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"  Wink

LeTanque
Member
**
Offline Offline

Activity: 85
Merit: 10


Fortune favors the bold and brave


View Profile
April 30, 2013, 09:37:35 PM
 #60

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.

"It is a mistake to suppose that any technological innovation has a one-sided effect. Every technology is both a burden and a blessing; not either-or, but this-and-that." -Neil Postman Technopoly
1FooDLuTYk782GQNrY7zY1obTc4ceUfj5t
Pages: « 1 2 [3] 4 5 6 7 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!