Bitcoin Forum

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.

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.

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.

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

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 ?

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)

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

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.

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.

BTW, this idea is already discussed on the Contracts wiki page for some time already. I'd suggest starting new proposals that are variants of those ideas by referencing them, and then explaining how to do better:

  https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains

To me the interesting thing is not a P2P cryptocurrency exchange (there's only one that matters), but P2P exchange for fiat. It can work by implementing a form of broadcast Ripple whereby people set up trust relationships between each other and settle up fiat asynchronously. Buying or selling BTC would commit the cryptocoins instantly, and adjust the debts between people in the exchange graph. You would then get the money owed to you by friends/colleagues whenever and however is most convenient.

By connecting yourself to this social graph of trust relationships, you can aggregate multiple paths through the network to reach as much value as you need. Of course, it doesn't help you if you aren't introduced to Bitcoin by somebody you know, but it's the next step in the evolution of sites like localbitcoin/bitcoinary/etc.

Dear Mike,
As I posted before, that kind of P2P trading (GMAX/luxgladius) does not work well because of the need for timeouts.

My proposal is not based on Example 5. Please read carefully. The only thing in common is that both use the word "Contract".

P2P exchange for fiat is another interesting problem, but it has already been discussed in some other threads. This thread is about P2P cryptocoin exchange.

I think Bitcoin would benefit from any new possible P2P exchange (for example SecondLife linden dollars).

You can't create timeouts in Bitcoin, locktime sets the earliest valid time. So you pre-create the refunds... but yes because the timeout wouldn't be identical in both chains there is some exposure.

I don't see how you avoid extortion in your scheme that wouldn't just apply here.  E.g. you could do the pre-created refund tx only on one side in what I described... and have the other side be the send-hash-first side.  If they don't you perform the refund after the timeout, thus no race.

(Not that in general I think that using chain fragments is bad— but I think it's interesting in external oracles, and less in chains themselves)


Both users would txouts before releasing a secret, so any funny business would have to be in the scriptsig.  If your scriptpubkey looks like if  H(stack) == 123456...  Then I could always copy from your scriptsig anything the satisfied that, even if it computed the value. Though yes, a program for this would have to have a pretty general solver to figure out how to extract the data.  So long as the abort transactions are sufficiently far out that shouldn't be a problem, and you'd have proof of your counterparty being evil.

No extortion is possible.

First let's assume a system where transactions/contracts have a timeout field if the proof is not published in a block.
(I'm using here my P2PTradeX terminology of what a contract and a proof is)

Since the contract specifies the length of the branch, it should specify a length whose time is much shorter than the timeout for the contract.

For example, a Alice publishes the following contract:

This contract will pay 100 XC from the prevout X to Bob's address if and only if a "proof" is published before 20 blocks from the publication of this contract.
The contract is this:
- The proof consist of a Bitcoin block branch containing a special tx.
- The block branch must be of length 6 after the block where tx is found,.
- Tx must be a Bitcoin transaction sending 100 BTX to address 37muSN5ZrukVTvyVh3mT5Zc5ew9L9CBare (Alice's address)
- The Root of the branch must be 00000000000000ca853e8e3faa30451909ec22db537717653b8bb6949fbe175c (this is the hash of a block 30 minutes in the past)
- The maximum length of the branch should be 10 blocks


Because there is NO SYMMETRY between Alice and Bob, the timeout on XC is setup to be 20 blocks, and the timeout in Bitcoin is setup to be only 10 blocks. If Bob manages to create the tx in Bitcoin in the time specified by the contract, then there is plenty of time (10 blocks) to publish the corresponding proof in the XC system.

As far as I can see, there is no way of extortion.

Best regards, Sergio.

Ah, I hadn't seen how you handled the non-completion case.  So in Bitcoin-style hashchains when that contract was mined it would consume the inputs forever unconditionally. If it did not, you could not have pruning.

Do you plan on breaking pruning or having the satisfaction rules change as a function of height or?

Honestly I haven't thought how to implement it on Bitcoin as the system to support these contracts (the first payment). I'm testing it on an alternate cryptocoin which does not use "prevouts" but "account numbers" and allows contracts to become effective conditionally. Then I can trade against Bitcoin in the way described. To implement this kind of contracts in Bitcoin some rules would have to change...

That's why I said this could be an advantage for ALTERNATE cryptocurrencies, and only indirectly, for Bitcoin.

I agree with Sergio here. The system sounds like it will work, but it cannot be implemented in bitcoin.

This discussion is related:

https://bitcointalk.org/index.php?topic=120175.0 (https://bitcointalk.org/index.php?topic=120175.0)
(tl;dr  : I am asking why nLockTime can't be modified to allow txns to expire. Due to hold up risk, this is necessary for pure P2P option contracts to work.  As I see it Sergio is making an altcoin where txns can expire. This should make P2P option contracts possible without any intermediary.)

and

https://bitcointalk.org/index.php?topic=121406.0 (https://bitcointalk.org/index.php?topic=121406.0)
(tl;dr : discussion of zero-trust option contracts which rely on an intermediary to serve as "broker" or "notary".)


BTW. Sergio, what system are you using to secure your new cryptocurrency? If you ask me about the 'holy grail' of cryptocurrency, it is a secure cryptocurrency with zero inflation AND simultaneously zero fees. Bitcoin cannot offer this. Ever.

Finding a way to do away with fees seems much, much, more important than cross-blockchain trading.

Without fees, how can you possibly solve spam? This is an ongoing and unanswered problem with email. Though the problem has been reduced by centralized filtering software. ;)

I don't really mean zero fees. I mean fees like bitcoin has today (which are very very low, but sufficient to deal with spam).

If bitcoin ran just on current txn fees the aggregate hash rate would be around 30 Gigahash; about 1/4 that of the mighty PPCoin. Not secure.

The question is: How can you securely run a decentralized currency worth 100 million US on 30 Gigahash worth of external work input? If you can answer this, then fees can stay this low forever.
Of course if you figure out how to have no implicit or explicit fees at all that is even better (though it seems impossible).

How about if The secret release has a time limit on it? Like for example the transaction for returning the deposit in the future to the rightful owner is in 10 mins and the transaction for releasing the first secret is in 5 mins. So Alice can wait but it doesn't matter she can only squeeze bob time to 5 mins time frame.

This should be probably discussed in another thread... it is another under-analyzed important subject...

My estimation is that fee price can be modeled by an equation like this:

Average fee per transaction =
  a0*Mining_Electricity_Cost  + a1*Mining_Hardware_Cost + a2*Avg_Transaction_Size + a3*Avg_Verification_Time
  - a4*Mining_Block_reward

What I've done to reduce fees in my alternate cryptocoin is to reduce average transaction size (80 bytes average), reduce Verification time (0.1 msec average).

I don't know how to reduce electricity cost of mining, except for Proof-Of-Stake proposals.
Wasn't there a paper that analyzed Bitcoin future fee price? What does it says?

Best regards, Sergio.

My views on this topic are controversial and widely-ignored. If you want to discuss this, it would be best for you to open the new topic. If I open it, no one will respond.

My short answer is
1) You should rearrange your equation so that block reward is on the left hand side. Block reward is just another form of tax (inflation tax instead of txn tax).
2) Mining Electricity Cost and Mining Hardware Cost dominate the right hand side, thus you can ignore Txn_Size and Txn_Verification_Time for the time being.

any updates? I am very interested.

Sorry to bump this old topic, but I propose making a change to the wikipedia article here.
https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains


This statement is false. As Sergio has described, the GMAX/luxgladius scheme is inherently insecure because it either a) has no timeout, in which case funds could be locked up forever, or else it b) relies on timeouts in the two chains which leads to a race condition where one guy could run away with the funds.

The P2PTradeX solution he describes would require substantial hard-fork changes to Bitcoin - essentially, you would have to be able to encode the validation rules for the altchain in a transaction script.

So, my suggestion is to remove the GMAX/luxgladius example from the wiki and explain that it currently thought to be impossible to trade between altchains and bitcoin without trust, and include a link to this thread.

You can do it yourself! To become a contributor to the wiki you just have to send a contribution (which can be tiny of you want) to a Bitcoin address (as an Spam protection measure)

I had some difficulty Googling for a clear explanation of atomic cross-chain trading, so I gathered my findings into this wiki page (https://en.bitcoin.it/wiki/Atomic_cross-chain_trading).

I must admit I do not fully understand Mike Hearns' explanation (https://en.bitcoin.it/wiki/Contracts#Example_5:_Trading_across_chains) as presented, I suggest we use the wiki page to develop and clarify the solution as needed.

Any progress on this?

I think the wiki page now clearly explains how to implement it.
We just need someone to pick up the glove...

I'm working on Marketcoin (https://github.com/XertroV/MarketcoinWhitepaper). It's rather similar, but more encompassing.


The chain-trade alg works in theory, but has two many practical 'misapplications', such as the race condition or mutually assured destruction.

As an addendum, Marketcoin requires no change to any current altchain (Bitcoin included) in order to trade with it.

As an addendum to the addendum, I started implementing the chaintrade script before Marketcoin fell into place. See https://github.com/XertroV/bitcoin/tree/chaintrade

No, that's why it's called "atomic", either both parties live up to their end of the bargain, or nothing happens.


No, if one party aborts in the middle then both parties retain the coins that they originally had. Therefore extortion isn't possible.