Quote from: dete on July 18, 2010, 06:33:16 AM

Interim steps like you suggest don't really change anything. What matters is the total number of transactions processed between the time Black Bart spends his coin and the point at which you (unrevokably) transfer something to him in return. (Called "confirmations" in the current UI.)

Not quite accurate. It relies on the number of BLOCKS generated, which is a collection of all transactions made in a rough timespan. So, if only one person out of all bitcoin users transfers money in 10 minutes, or every bitcoin user spends bitcoins like mad for 1000000 transactions in 10 minutes, only one block has elapsed in either case. Then, each block is "buried" under the blocks after it, resulting in more and more security for said transaction.

Quote from: ByteCoin on July 19, 2010, 03:40:28 PM

The attacker can buy computer time from a botnet owner which provides access to a large amount of hash generation power or alternatively he has access to many HPC Amazon EC2 instances. The price of the computer processing is the power multiplied by the time.
The attacker also runs modified BitCoin software at a huge number of different IP addresses but because the software just acts like a network node and doesn't do any block generation it doesn't cost much to run.

He perhaps waits until the "difficulty" is lower than average and then generates a transaction which represents a huge transfer of bitcoins from one address to another. The originating address does not have the BitCoins but that doesn't matter. He then fires up his vast computing resources and generates enough sucessive hash blocks by himself to make the transaction go confirmed. He only transmits these hashblocks to merchants running the "Simplified Payment Verification" who only connect to IP addresses that he controls so the rest of the network doesn't even know anything is wrong. He does not forward network traffic which might alert the merchants to the fraud such as contradictory hashblocks. He then buys goods from those merchants using the credit implied by the transfer he's just rendered confirmed. He continues to generate enough hashblocks to render those transactions confirmed. The scammed merchant transfers the goods. The attacker shuts everything down and walks away with the goods.

ByteCoin

The transfer requires the private key of both parties. Thus, it's impossible to "create" faulty transactions. Also, transmitting directly by IP still alerts the rest of the network. You can't initiate ANY transaction without either a) propagating said transaction throughout the entire network of nodes, or b) creating an isolated graph, where you control ALL the nodes, and aren't connected to anyone else. As soon as an outside client connects to your "bad island", he starts downloading your block chain. He can easily verify each step in that block chain, tracing the validity of coin transfers. He can't "transfer" coins out of thin air, nor can he transfer coins away from an unwilling party, as he doesn't have their private key. The merchant in your example, running the "simplified payment verification", would need to download the block chain, and thus would see that it was invalid.