Topic: P2PTradeX: P2P Trading between cryptocurrencies (Read 13118 times)

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.

I'm working on Marketcoin. 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

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

Any progress on this?

I had some difficulty Googling for a clear explanation of atomic cross-chain trading, so I gathered my findings into this wiki page.

I must admit I do not fully understand Mike Hearns' explanation as presented, I suggest we use the wiki page to develop and clarify the solution as needed.

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)

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.

any updates? I am very interested.

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.

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.

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.

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

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 agree with Sergio here. The system sounds like it will work, but it cannot be implemented in bitcoin.

This discussion is related:

https://bitcointalksearch.org/topic/mutltisig-for-txns-that-are-not-currently-valid-but-may-become-valid-120175
(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://bitcointalksearch.org/topic/options-in-the-blockchain-121406
(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.

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.

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?

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.

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.

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

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.