Topic: P2PTradeX: P2P Trading between cryptocurrencies - page 2. (Read 13158 times)

Let's talk about GMAX protocol. The protocol is almost perfect. But as you say, a timeouts would be necessary to prevent the coins getting blocked if one party refuses to reveal the secret.

I see two problems:

1) Suppose the payment A->B is done on cryptocoin X and the B->A payment on cryptocoin Y. If Alice refuses to tell the secret "x" after Bob has told the secret "y", Alice can wait until the last moment when the timeout in Y will elapse and send a transaction that grabs the payment B->A, leaving no time for Bob to send the corresponding transaction in the cryptocoin X. The A->B transaction will timeout, and the money will return to A. Obviously adding a third party would prevent this, but the protocol must be TTF-free.

2) With the scripting system, Alice could encrypt the value x so that it's difficult for Bob to manually find x from the transaction scriptSig. For example the scriptSig reference to x could be "r t + ~" so that x=~(r+t). Then the transaction would need special treatment to extract "x" and "y" in cleartext.

These problem are not present in P2PTradeX. I know it's a bit more complex, but it works and has no drawback.

Best regards,
S.

For the time being, its a great advancement if you can get it to work reliably but after all decentralized BTC/fiat exchange feels like the difference between a nice gimmick and the real deal.

Trading between cryptocurrencies is a nice idea. In the years to come, it's gonna get more and more useful.

Correct. The script sig would push the x and y values and the script pubkey would hash and compare them.

(You can also reduce the extortion risk  by using nlocktime, on specially constructed refund transactions. E.g. "Abob_pub + H()+H()" OR "Abob_pub2&&Aalice_pub" and have bob sign a refund txn with far future nlocktime using abob_pub2)

Could you clarify this:


Is "ABob_pub + H(x)==Ah + H(y)==Bh " the scriptPub ?

Are the values x and y provided by a scriptSig ?

You can do this with far less complexity, and the same extortion risk like this:

Alice and Bob want to trade Acoins and Bcoins. They each pick secrets. Asecret and Bsecret.
They each tell each other H(Asecret)=Ah, and H(Bsecret)=Bh.

After agreeing on the amounts they each form transactions
AAlice 1 Acoin ->  ABob_pub + H(x)==Ah + H(y)==Bh
BBob  1 Bcoin ->  BAlice_pub + H(x)==Ah + H(y)==Bh

once both transactions are in one or the other reveals their secret out of band. The redemption works for all or none.

As mentioned, there is holdup risk here, which could be solved by adding semi-trusted observer keys to optionally release the funds in the case of defection.

But I think the fragment protocol  described here has the same risk.  (and the obvious ways to do avoid it make it possible to rip off one party by delaying the mining of the solution).

It could in theory be done if banks emitted some kind of digitally signed document when they sent money to an account (which they don't)

Take into account that since bitcoins can be traded against USD or any other fiat money relatively easy now, trading against Bitcoin is "almost" like trading against fiat money.

Sergio.

Nice idea! (dont take my word for it, i have no clue on the technical side what so ever )

If I understand correctly, your protocol only works for digital assets, like crypto currencies. Have you considered working on APIs of online banks as well? Since they would be the real "holly grail" because changing BTC for traditional currencies is what always concerns people most and where the largest market would be for your system.

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.

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 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.).

Best regards,
 Sergio.

PS: I named the protocol P2PTradeX, because there was no result when I googled that word.