I want to describe a new P2P protocol I´m implementing for an alternate cryptocoin as a proof of concept.
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. 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, they can trade automatically against Bitcoin. 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. 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.
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.
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 is 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. I will release the code when it's ready. The system is implemented in a way to understand contracts for all other alternate currencies and 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.).
PS: I named the protocol P2PTradeX, because there was no result when I googled that word.