Bitcoin Forum

Basically, I want to double spend the coins i want to send to you.
I prepare two chains.

a 6 long chain with your TX in the first block
a 7 long chain with your TX doublespent in the first block.

Then I submit the first chain,
you send me the stuff and immediately I release the 7 long chain charging back the money.

When releasing the Pubkey shortly before payment, this is not possible.

You can't prepare any chain ahead of time because you always have to build on the blocks that came before it.  So by the time you solve the next block, someone else will likely also solve it, and the network will use their block if you try to keep yours hidden.

 I don't know what Satoshi was talking about in the quoted section as it doesn't make any sense to me either.  You are right, the attacker doesn't need the victims PubKey in order to build the chain because the "attack chain" will contain the double spend not the spend to the victim.  I can only conclude that Satoshi was either mistaken or he is talking about something else and is unclear in the wording.  The paper was written at a theoretical level about a year before the first version of the client was completed.

maybe originally there was no such thing as blocks and every transaction was simply linked to the next?

11. Calculations
We consider the scenario of an attacker trying to generate an alternate chain faster than the honest
chain. Even if this is accomplished, it does not throw the system open to arbitrary changes, such
as creating value out of thin air or taking money that never belonged to the attacker. Nodes are
not going to accept an invalid transaction as payment, and honest nodes will never accept a block
containing them. An attacker can only try to change one of his own transactions to take back
money he recently spent.
The race between the honest chain and an attacker chain can be characterized as a Binomial
Random Walk. The success event is the honest chain being extended by one block, increasing its
lead by +1, and the failure event is the attacker's chain being extended by one block, reducing the
gap by -1.
The probability of an attacker catching up from a given deficit is analogous to a Gambler's
Ruin problem. Suppose a gambler with unlimited credit starts at a deficit and plays potentially an
infinite number of trials to try to reach breakeven. We can calculate the probability he ever
reaches breakeven, or that an attacker ever catches up with the honest chain, as follows [8]:

p = probability an honest node finds the next block
q = probability the attacker finds the next block
qz = probability the attacker will ever catch up from z blocks behind

qz= 1 if p≤q
qz = (q/ p)^z if p<q

Given our assumption that p > q, the probability drops exponentially as the number of blocks the
attacker has to catch up with increases. With the odds against him, if he doesn't make a lucky
lunge forward early on, his chances become vanishingly small as he falls further behind.
We now consider how long the recipient of a new transaction needs to wait before being
sufficiently certain the sender can't change the transaction. We assume the sender is an attacker
who wants to make the recipient believe he paid him for a while, then switch it to pay back to
himself after some time has passed. The receiver will be alerted when that happens, but the
sender hopes it will be too late.
The receiver generates a new key pair and gives the public key to the sender shortly before
signing. This prevents the sender from preparing a chain of blocks ahead of time by working on
it continuously until he is lucky enough to get far enough ahead, then executing the transaction at
that moment. Once the transaction is sent, the dishonest sender starts working in secret on a
parallel chain containing an alternate version of his transaction.
The recipient waits until the transaction has been added to a block and z blocks have been
linked after it. He doesn't know the exact amount of progress the attacker has made, but
assuming the honest blocks took the average expected time per block, the attacker's potential
progress will be a Poisson distribution with expected value.

<removed calcuations.  Satoshi model and estimate is not as accurate as the ones done in the later paper by Meni Rosenfeld>

What video?

What you described is a double spend.  It becomes progressively more difficulty for Alice to build the longer chain unless she hash a majority of the computing power.  It doesn't matter if Alice starts building the attack chain first or makes the legitimate deposit and then starts building the attack chain the probability she will outrace the network starting from a block behind is unlikely.  The more confirmations the less likely it becomes.


For a deposit of 1,000 BTC the exchange should probably require more than three confirmations.  Meni wrote a very good paper on the economics of double spending.  If Alice has 10% of the network computing power her chance of being successful is 1.712% for 3 confirmations,  0.546% for 4 confirmations, 0.178% for 5 confirmations, and 0.059% for 6 confirmations.  The exchange can also protect itself by validating KYC information for users involved in large transactions.  https://bitcoil.co.il/Doublespend.pdf

As for your quote.  I don't know what Satoshi was talking about in the quoted section as it doesn't make any sense to me either.  You are right, the attacker doesn't need the victims PubKey in order to build the chain because the "attack chain" will contain the double spend not the spend to the victim.  I can only conclude that Satoshi was either mistaken or he is talking about something else and is unclear in the wording.  The paper was written at a theoretical level about a year before the first version of the client was completed.

This video: http://www.youtube.com/watch?v=Lx9zgZCMqXE .  At around 14:00 minutes, it explains why one can't preparing blocks ahead of time. I think what it says is incorrect.

Meni assumes one block was pre-mined by the attacker. All his calculation is base on this assumption.
My case is that the attacker pre-mines all the blocks he needs, Which makes him sure he can double spend the coins. The calculation should be different between my case and Meni's case.
I think if someone really want to double spend coins, he should pre-mine all the blocks he needs.
The reasons are:
1. When he is successfully pre-mine the blocks he needs, he is 100% sure he can double spend the coins.
2. When he pre-mine the blocks, he can abandon his hidden chain when his chain becomes shorter than the honest chain, and works on another hidden chain after the honest chain. This is more efficient. In Meni's case, unless the attacker gives up his attack, after the he spent the coins in the honest chain, he can't abandon his hidden chain even if the honest chain becomes longer than his chain.

The video is not incorrect.

Are you sure you understand the part where they said the previous blocks output is used as input to the next block?

you would need a tremendous amount of hashing power to outmine the network for even a few blocks.

If you want to prevent someone from preparing a chain of blocks ahead of time, it's worthwhile to require each block to contain some kind of observed event that can't easily be known in advance. 

A Bitcoin block ID/Hash would be a pretty good example of that, I'm thinking.

If you require a bitcoin hash from, say, 2 hours ago in each block of your block chain, you're immune to reorgs on the bitcoin blockchain unless they're over 2 hours long, and the time of appearance of each bitcoin block is publicly known.  The result is that nobody can make a block of your altcoin chain more than 2 hours in advance.