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

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.

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.

No, the average time from one block to the next will be ten 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....

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.

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.

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.

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.

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.

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.

Yep -- a bitcoin backbone, one might call it.

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.

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.

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

I don't know if it would be feasible, but here's a proposal for real time confirmation:

https://bitcointalksearch.org/topic/a-block-chain-for-real-time-confirmations-4382

If it won't work, can you explain why?

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

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.

Yeah, that was my first suggestion, but a general purpose debit account would be more useful since it could be used at other places.

I didn't say impermeable, I said good-enough.  The loss in practice would be far lower than with credit cards.

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.

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

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.