The following content was written by Insti on July 17, 2010, 02:33:41 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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?
The following content was written by laszlo on July 17, 2010, 02:58:29 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
The following content was written by knightmb on July 17, 2010, 03:08:25 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
The following content was written by FreeMoney on July 17, 2010, 05:06:29 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
The following content was written by knightmb on July 17, 2010, 05:10:02 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
The following content was written by FreeMoney on July 17, 2010, 06:03:06 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
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 following content was written by d1337r on July 17, 2010, 07:20:59 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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)
The following content was written by Insti on July 17, 2010, 08:15:41 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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 following content was written by NewLibertyStandard on July 17, 2010, 08:20:14 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
The following content was written by knightmb on July 17, 2010, 08:23:59 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
The following content was written by mizerydearia on July 17, 2010, 08:26:46 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
Or if not not the vendor, then perhaps there’s a company called Bitcoin Escrow
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.
The following content was written by Babylon on July 17, 2010, 08:28:22 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
what you folks are calling an escrow sounds a lot like a debit card account.
The following content was written by NewLibertyStandard on July 17, 2010, 08:36:19 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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. 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.
The following content was written by Babylon on July 17, 2010, 08:42:30 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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. 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 following content was written by Insti on July 17, 2010, 09:09:05 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
The following content was written by NewLibertyStandard on July 17, 2010, 06:37:58 PM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
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.
The following content was written by llama on July 17, 2010, 09:20:14 PM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
The following content was written by Babylon on July 17, 2010, 09:27:07 PM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
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.
The following content was written by satoshi on July 17, 2010, 10:29:13 PM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
The following content was written by llama on July 18, 2010, 12:03:29 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
The service provider 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 service provider’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…
The following content was written by satoshi on July 18, 2010, 01:59:15 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
This is a good start, but still not impermeable.
I didn’t say impermeable, I said good-enough. The loss in practice would be far lower than with credit cards.Quote
(for example, by refusing to propogate word of the transaction at the vending machine)
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.
The following content was written by NewLibertyStandard on July 18, 2010, 02:12:18 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
Yeah, that was my first suggestion, but a general purpose debit account would be more useful since it could be used at other places.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.
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.
The following content was written by aceat64 on July 18, 2010, 07:53:45 PM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
The service provider 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 service provider’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…
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.
The following content was written by Bruce Wagner on January 10, 2011, 05:03:06 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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
The following content was written by jtimon on March 14, 2011, 08:03:39 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
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.
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?
The following content was written by Dobry Den on March 16, 2011, 11:26:00 PM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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!).
The following content was written by Jim Hyslop on March 17, 2011, 01:11:10 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
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.
The following content was written by eMansipater on March 17, 2011, 02:11:18 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
The following content was written by jgarzik on March 17, 2011, 02:56:26 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
The following content was written by db on March 17, 2011, 10:24:04 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
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.
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.
The following content was written by jav on March 17, 2011, 10:48:03 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
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.
The following content was written by Pieter Wuille on March 17, 2011, 11:43:41 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
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.
The following content was written by MoonShadow on March 17, 2011, 03:57:36 PM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
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.
The following content was written by eMansipater on March 18, 2011, 07:32:49 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
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.
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.
The following content was written by abstraction on March 18, 2011, 09:37:42 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
So, here is what I think will happen.
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.
The following content was written by Jim Hyslop on March 18, 2011, 10:42:33 PM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
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.
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.
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….
The following content was written by Dobry Den on March 18, 2011, 11:00:14 PM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
I don’t know how the interface would work, but I’m sure someone already figured that out.
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.
The following content was written by ffe on March 19, 2011, 01:43:21 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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 1ter
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.
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 1ter
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.
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.
The following content was written by jerfelix on May 24, 2011, 11:28:51 PM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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!)
The following content was written by BeeCee1 on May 25, 2011, 01:23:50 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
The following content was written by ffe on May 25, 2011, 05:50:15 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
The following content was written by realnowhereman on May 25, 2011, 12:08:32 PM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
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.
The following content was written by MoonShadow on May 25, 2011, 04:45:00 PM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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 following content was written by ArdaXi on June 10, 2011, 08:16:33 PM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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?
The following content was written by MoonShadow on June 10, 2011, 08:30:47 PM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.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?
The following content was written by ArdaXi on June 10, 2011, 08:37:18 PM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.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?
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.
The following content was written by Findeton on June 10, 2011, 08:50:20 PM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
The following content was written by ArdaXi on June 10, 2011, 09:03:53 PM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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?
The following content was written by jtimon on June 17, 2011, 07:25:43 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
The following content was written by makomk on June 17, 2011, 12:20:55 PM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
The following content was written by tymothy on June 17, 2011, 01:48:39 PM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
The following content was written by jtimon on June 18, 2011, 11:33:41 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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?
The following content was written by bcearl on June 18, 2011, 11:44:24 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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.
The following content was written by skerit on June 18, 2011, 12:03:40 PM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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)
The following content was written by WNS on June 18, 2011, 01:43:07 PM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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:
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.
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.
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.
The following content was written by markm on August 07, 2011, 09:43:09 AM in the thread Bitcoin snack machine (fast transaction problem). All content is owned by the author of the bitcointalk.org post. (original)
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!)
