P2PTradeX, back from the future

Almost one year ago I described in the Bitcoin technical forums a new P2P virtual coin trading protocol (so called P2PTradeX) I had implemented for an alternate cryptocoin, mostly as a proof of concept. The idea got some attention, but nobody really needed that stuff. It was before it’s time. Yesterday I was at Bitcoin 2013 conference in San Jose, CA, listening to David Swartz explain the Ripple protocol, which is innovative in many ways, and he presented the difficulties of trading Bitcoins against XRPs, and then I remembered P2PTradeX and explained it to him. It immediately caught his attention, and then he rapidly disappeared into a bunch of other people. I thought that was kind of rude. The day after he came to me telling me that I had solved one of the problems his team thought it was impossible to solve. And even if he thought it was and awful idea (!), it was the only possible solution to the problem. Those things make you fell  that ideas and hard work, sometimes not immediately recognized when published, can make a difference. Now I’m reprinting the technical part…

The protocol allows cross-coin p2p trading without a central point. It seems to me that it is the “holly grail” of alternate crypto coins, because it gives them an advantage Bitcoin didn’t have at that time.  And this is an idea that can change the cryptocoin ecosystem for good, where all coins trade against each other. The benefit for alternate chains is enormous: they don´t need to provide an exchange site, nor worry about regulation, they can trade automatically against Bitcoin. Each user is responsible of his own actions. But also it can make regulation quite unenforceable at the user level. It also means that alternate cryptocoins will rely on Bitcoin and will support Bitcoin because they need  it to enter the cryptocurrency game.

This is short explanation:

Suppose that there are two crypto-coins, XC and BTC. Each coin XC and BTC has its own blockchain and client. The user A has some XC and want to buy some BTC in return. User B wants the opposite. First both parties find each other (in a central directory or by a P2P protocol) and fix the trade price (A pays “a” XC and B pays “b” BTC back). There are two payments A->B (in XC) and B->A (in BTC). We well call these payments first and second payment, respectively. Both users have an address in the XC system and an address in the Bitcoin system.

The protocol works as follows:

1. User A commits to the first payment of “a” XC to the address of user B in the system XC. This is a special payment with a “contract” that is automatically allowed if a certain “proof” is published as a special transaction in a limited interval after the publication.

2. User B sends b BTC to A via Bitcoin in a standard way. This is the second payment.

The contract specifies that a piece of the Bitcoin blockchain (a branch) should be copied into a special transaction called “proof” into the XC blockchain to prove the second payment has actually taken place.

The contract also specifies:

• The chain branch size (N). This is how much effort in terms of confirmations (PoW) must be added after the block where the second payment is published.
• The hash of the block where the branch should start (root block). The root block should be chosen to be some blocks in the past to avoid choosing a block that will be discarded by a competing branch in a natural fork. For example, if current block is BLK and the previous block of BLK is Prev(BLK), parties can choose a root in Prev^3(BLK) with a length of at least 9 blocks (6 confirmations after current block)
• The maximum number of blocks after the root block where the second payment can appear. This is to prevent the payment being done just after the XC contract interval has expired, thus making the trade one-way only. You can specify a low number of blocks for trading low values and a high number of blocks for greater values exchanged. In this regard, the protocol scales smoothly with the amounts transacted.

3. When the proof transaction (that matches the contract) is published in an XC block, clients automatically accept the first payment (that specifies the contract), thus paying “a” XC from A to B.

Notes:

1) Not the full Bitcoin blockchain branch needs to be included in the XC blockchain. Only the headers of the N blocks, the Merkel branch that proves the existence of the second payment and the transaction of the second payment. Generally less than 800 bytes are required for the full  “proof”.

2) All this protocol works transparently. The user only setups maximum/minimum trade prices and trade quantities.

3) Generally B is the most interested that the “proof” is published, but if B doesn’t do it  (and the second payment was done) then A itself can publish the proof.

4) The “proof” is included in a block as a normal transaction and can pay a fee to the miner, but the minimum fee is specified in the contract. Both parties should take care of specifying fees that allow the transactions to be selected by the miners to be included in a block. If the fee is not enough, a higher fee can be specified when the proof is sent. It is recommended that the fee for the miner of the “proof” be much higher than normal fees to give a strong incentive to miners to include this transaction in all competing blocks.

5) The security of the system relies on the premise that no party can build a blockchain branch longer and faster than the “global” branch in a limited interval (e.g. 20 blocks). Also the proof cannot be constructed in advance, since the root block (which is almost the current block) is specified in the contract.

6) If the trade fails because the interval has elapsed and the second payment was not done, the first payment is canceled.

7) The coins committed in the first payment cannot be used until the contract is canceled or it is accepted.

I have a proof of concept of this protocol working. Note that the XC coin cannot be Bitcoin, since it requires many additional features too hard to be implemented in Bitcoin right now.  And anyway, it’s only needed on one side of the exchange.
The system is quite malleable, so in a way that the XC coin understands contracts for all other alternate cryptocurrencies and probably some unknown ones. The user specifies a “template”  for the second payment message, with placeholders for the fields that are unknown (the transaction signature) and fixed values for the remaining fields (amount of money, public key of recipient,etc.). And also a template for the block format (field of linkage, hash algorithm, etc.).

It’s a pity that no alternate coin has given the protocol the proper attention, before launching their coins.

Last, I named the protocol P2PTradeX, because there was no result when I goggled that word. Is so hard to came up with a new acronym unused these days.