I came up with an attack on my P2PTradeX protocol, which, in most cases, would thwart severely its utility. Let’s first review the protocol. A first party issues a conditional transaction in a block chain X, which contains a contract. The contract requests the the other party to provide a proof that a payment has been issued on the Bitcoin block chain. The proof consist of a Merkle branch from the Merkle root to the paying transaction, the block header plus the block headers of several confirmation blocks. The attack works as follows: if the attacker can perform simultaneous trades, then he can create a single counterfeit block branch containing many fake transactions. Almost 2200 standard looking fake transactions can be stored in a block. This block branch can be presented simultaneously to all the traders, sharing the cost of orphan mining over all the executed trades. The attack can be “pipelined” so the counterfeit branch is partially reused for each new batch of attacks performed in each new block, at most an average of 6 times.
Suppose that the proof length is k=6 and that each block can carry n transactions, and the block can be rooted at most t=6 blocks in the past. If the block reward is 25 BTC, then the attacker may try to attack n*t victims by mining (t+k) blocks, and filling the first t blocks with n*t fake transactions. This will cost the attacker 25*(t+k) BTC. This limits the amount of money that can be safely traded in each transaction to 25*(t+k)/(n*t). Currently n is approximately 2200, and assuming t=k=6 we have that the maximum would be 22 mBTC per transaction, or 22 USD at 1K USD/BTC exchange rate, for a 6 block length contract. If the contract specifies values of k much higher than t, then the t value in the upper term can be ignored. The approximate formula for the upper limit when t=6 becomes 1.8*k mBTC. A trade of 1 BTC will therefore require almost 3 days to be executed.
These numbers get worse once the block reward is reduced to 12.5 BTC.
Mitigations
If you want to trade higher amounts (say n BTC) you should either trade them by dividing n in many transactions or increase the proof length (k value). Also you can create a transaction whose size greater the standard transaction size, adding more inputs. Outputs could also be added, but some other standard condition must be specified on transactions to avoid reusing the outputs for different trades.
Since traders request block chain branches that are recent (e.g. rooted not more than 6 blocks ago), the attacker may not be able to reuse the fake block chain branch for many block intervals. To achieve the maximum revenue from the attack, the attacker may need to perform thousands of simultaneous trades. This may be impractical due to the lack of market for trades. If the trading market executes 1 order per second (1/7 of the maximum Bitcoin transaction rate) then the maximum secure trade per transaction rises to 40 mBTC, for a 6 block length trade (1 hour).
Last, if the Bitcoin chain has periodic checkpoints (e.g. 1 per day) signed by a trusted authority, then the contracts may specify that the last block header should be check-pointed. This eliminates the problem completely but slows downs trade rate considerably and requires a TTP.
Conclusion
It’s has to be evaluated if the P2PTradeX is worth it’s complexity now that it has been found that it limits the amounts traded more than previously thought. Recently some other protocols have been designed that achieve the same result but do not require changing the core protocol, such as the one described by Socrates1024 here. In comparison Socreates1024 protocol requires that some non-standard transaction templates are re-enabled in both block-chains but does not limit the amounts traded, while P2PTradeX does not impose any restriction on the Bitcoin side, while requires much computing effort on the alternate coin side, and restricts traded amounts.
Bitslog 