47. On Fast Transaction Problems

47

On Fast Transaction Problems

HERE, Satoshi explains that a payment processing company would monitor the Bitcoin network for the transaction of interest to the merchant, as well as any other conflicting transactions. Since nodes will only accept the first transactions and will reject any other transactions which conflict with those, the merchant’s transaction should be seen first. If any conflicting transactions are seen by the payment processing company, it will inform the merchant that the transaction is bad. Of course, if the correct transaction is officially accepted, the merchant can reimburse the client or process

the sale.

Re: Bitcoin snack machine (fast transaction problems)

Satoshi Nakamoto July 17, 2010, 10:29:13 PM

Quote from: Insti, July 17, 2010, 02:33:41 AM

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?

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:

So if a double-spend has to wait even a second, it has a huge disadvantage.

The payment processor has connections with many nodes. Whenit 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 transactionis 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 paymentprocessor’s broadcast has reached most nodes, or is so far aheadin propagating that the double-spender has no hope of grabbing a significant percentage of the remaining nodes.

Another later thread revisited the scalability and transaction rate. Satoshi points back to the thread above.

Re: Scalability and transaction rate

Satoshi Nakamoto July 29, 2010, 02:00:38 AM

Quote from: Red, July 22, 2010, 05:17:28 AM

I’m curious about the developers feelings on scalability. For example, could the system handle a million users, doing say5 transactions each per day. 5 million transactions per day is roughly 35,000 transactions per 10 minute period?

Is there a bottle neck in propagating 35,000 transactions to a million nodes for block generation? Or has that issue been designed for?

The current system where every user is a network node is not the intended configuration for large scale. That would be like every Usenet user runs their own NNTP server. The design supports letting users just be users. The more burden it is to run a node, the fewer nodes there will be. Those few nodes will be big server farms. The rest will be client nodes that only do transactions and don’t generate.

Quote from: bytemaster on July 28, 2010, 08:59:42 PM

Besides, 10 minutes is too long to verify that payment is good. It needs to be as fast as swiping a credit card is today.

See the snack machine thread, I outline how a payment processor could verify payments well enough, actually really well (muchlower fraud rate than credit cards), in something like 10 seconds or less. If you don’t believe me or don’t get it, I don’t have time to try to convince you, sorry. http://bitcointalk.org/index.php?topic=423.msg3819#msg3819