Mercury - Fully trustless cryptocurrency exchange - Looking for testers!

[slothbag]

Hi mappum, do you plan to add support for interacting with coin daemons instead of relying on inbuilt SPV clients?  This way people could host their own nubits daemon and mecury could just call its APIs? This seems to me a much more scalable solution.

[1715036169]

1715036169

[1715036169]

1715036169

[1715036169]

1715036169

[mappum]

Hi mappum, do you plan to add support for interacting with coin daemons instead of relying on inbuilt SPV clients?  This way people could host their own nubits daemon and mecury could just call its APIs? This seems to me a much more scalable solution.

The currently implemented coin clients will already do this (they check for a node running on localhost, and if there is one they use it as a trusted peer). You're right, it might be a good idea to get Nubits to work like that, so that a SPV client doesn't have to get developed first.

[slothbag]

The currently implemented coin clients will already do this (they check for a node running on localhost, and if there is one they use it as a trusted peer). You're right, it might be a good idea to get Nubits to work like that, so that a SPV client doesn't have to get developed first.

Great

So if we had a non Bitcoin based coin like Nxt, Ripple or BitShares, and they implemented some sort of PayOnSecretReveal & SecretReveal API would that be pretty straight forward to implement into Mecury?

[mappum]

Great

So if we had a non Bitcoin based coin like Nxt, Ripple or BitShares, and they implemented some sort of PayOnSecretReveal & SecretReveal API would that be pretty straight forward to implement into Mecury?

It's slightly more complicated than that in order to allow the deposits to be redeemed by the refund transactions, but that sort of API would be most of what is required. I don't know a lot about how these currencies differ from Bitcoin, do they still have the same input/output system, with scripting?

[Uptrenda]

Disclaimer: I am currently working on my own decentralized exchange although I've tried my best to make this feedback balanced and accurate.

First, let me say this is a great project. I like your user interface, your centralized order book is a nice simple idea, and you seem like a competent developer. However I can't help but think you're glossing over the security concerns by making too many assumptions. Keep in mind, I do understand this is a prototype but as it stands this design won't work for real money (at least not very well) and here is why:

1. Transaction malleability. If the transaction that the refunds depend on is mutated the refund will be invalidated, potentially locking any funds up within the contract and leaving the contract vulnerable to extortion attacks. You suggest this problem is too costly to perform but let me say: that might not be the case. A particular paper comes to mind (0) in which researchers were able to double-spend zero confirmation transactions on the Bitcoin network by having vastly more connectivity than the victim and using that connectivity to propagate the double spend TX before the legitimate TX arrives. The attack works by exploiting the properties of the mempool, as nodes will only accept the first version of a transaction for any group of inputs. Now in the context of your exchange, an attacker could simply mutate (3) the "bond" TX and propagate it to the rest of the network / the majority of miners before your original transaction arrives (1) ( 8 ). This attack would not be expensive to perform and could be done with a few hundred $5 a month VPS'. Additionally, the attacker could vastly optimise his chance of success by monitoring multiple points on the network, thereby ensuring the attacker sees transactions at the earliest possible time.

Even if the attacker only succeeds in mutating less than 5% of transactions and your exchange's transactions constitute less than 0.00001% of that TX volume - that could still translate to quite a large number of users effected (4) and OP_CHECKLOCKTIMEVERIFY won't save you here. You seem to be assuming that once Bitcoin Core merges the patch that all your problems will go away, but this relies on the assumption that alt-coins will actually merge Bitcoin Core's patches and stay up to date when generally they don't. There are still patches that were made to Bitcoin core in 2012 that have yet to be merged with Litecoin and I'm guessing it's the same story with other alt-coins too. Thus, alt-coins that aren't forked after the patches are likely to remain vulnerable to TX malleability for years - possibly indefinitely.

Of course, you could fix this whole nasty problem in a day by adding fail-safe keys to your scheme, that way if the money is locked you can still mediate ... but if you decide to do that, you then have to worry about the security of the keys and you couldn't claim that your scheme was entirely trustless if  full mediation was required.

2. Partial matching. From my understanding of your code there doesn't seem to be a mechanism for partial matching. In practice, this would mean that your users would have to wait for 8~  confirmations * confirm_time minutes (80 minutes for Bitcoin!) between every match (and large orders may require hundreds of them.) The problem comes from the fact that Bitcoin transactions are like hierarchical trees, that outputs must be spent in full, and that the distribution of amounts amongst outputs isn't guaranteed to be optimal for matching trades. Consequently, any given match - even for a small amount - could make 100% of the coins in your wallet unavailable until the contract was confirmed (which would make it incredibly painful to match trades.)

A proper exchange needs to support partial matching (5) to be able to efficiently match orders and I'd argue its even more important for "decentralized" exchanges as trades are already thousands of times slower than centralised exchanges because of the block chain.

3. Non-standard transactions. Since this is getting too long I'll just summarise this point: cross-chain contracts rely on non-standard transactions whose propagation is outright rejected on most alt-coins. The result is your contracts likely won't work on the main network and if  it does: confirmation time will take hours rather than minutes. This is a huge issue because you can't fix the lack of transaction support with any coding patch. It's an immovable object built directly into the parameters of the network and the only way around is to be able to influence the miners directly into accepting your non-standard transactions. You probably won't have this problem on the Bitcoin side because the IsStandard() rules were recently relaxed (2), but on alt-coin I can see you pulling your hair out (6) (7)
 
tl; dr, your design has major problems that you need to fix. These are all problems I've had to address in my design so if this criticism comes off as too vague I'm happy to elaborate.

(0) https://eprint.iacr.org/2012/248.pdf
(1) There have been reports of widespread transaction mutation on the main network. An attacker might already have the capabilities I've discussed.
(2) https://github.com/bitcoin/bitcoin/pull/4365/files
(3) I have a five line function in my repo - literally five lines, and it will mutate transactions on most alt-coins:
   

def mutate_tx(tx_hex):
    """
    Mutates a raw transaction using TX malleability in the scriptSig (specifically, the OP codes.) This function shouldn't be used beyond testing as it uses an ugly eval() hack.

    https://en.bitcoin.it/wiki/Transaction_Malleability
    """
    tx = CTransaction.deserialize(binascii.unhexlify(tx_hex))
    script_sig = repr(tx.vin[0].scriptSig)[9:]
    script_sig = eval("CScript([OP_1, OP_DROP, " + script_sig)
    tx.vin[0].scriptSig = script_sig
    return b2x(tx.serialize())
   

(4) I'd argue even 1 user effected would be bad since there's potentially no way to retrieve the money if  the other side discards the key.
(5) A simple solution is to sort the order book in descending order but that still doesn't guarantee optimal matching.
(6) Tier-Nolan came up with a solution to this that only requires non-standard transactions on one side of the trade. The details are available here: https://github.com/TierNolan/bips/blob/bip4x/bip-atom.mediawiki
(7) I really like cats.
( 8 ) The window of time for such attacks would be possible depending on how close the attacker was on the network to the broadcasting node. If we assume around 50 - 400ms latency between hops, then the arrival time for the initial transaction would still make a double-spend possible given the current network propagation delays: http://bitcoinstats.com/network/propagation/

And now I'm done editing.

[mappum]

Disclaimer: I am currently working on my own decentralized exchange although I've tried my best to make this feedback balanced and accurate.

First, let me say this is a great project. I like your user interface, your centralized order book is a nice simple idea, and you seem like a competent developer. However I can't help but think you're glossing over the security concerns by making too many assumptions. Keep in mind, I do understand this is a prototype but as it stands this design won't work for real money (at least not very well) and here is why:

1. Transaction malleability. If the transaction that the refunds depend on is mutated the refund will be invalidated, potentially locking any funds up within the contract and leaving the contract vulnerable to extortion attacks. You suggest this problem is too costly to perform but let me say: that might not be the case. A particular paper comes to mind (0) in which researchers were able to double-spend zero confirmation transactions on the Bitcoin network by having vastly more connectivity than the victim and using that connectivity to propagate the double spend TX before the legitimate TX arrives. The attack works by exploiting the properties of the mempool, as nodes will only accept the first version of a transaction for any group of inputs. Now in the context of your exchange, an attacker could simply mutate (3) the "bond" TX and propagate it to the rest of the network / the majority of miners before your original transaction arrives (1) ( 8 ). This attack would not be expensive to perform and could be done with a few hundred $5 a month VPS'. Additionally, the attacker could vastly optimise his chance of success by monitoring multiple points on the network, thereby ensuring the attacker sees transactions at the earliest possible time.

Even if the attacker only succeeds in mutating less than 5% of transactions and your exchange's transactions constitute less than 0.00001% of that TX volume - that could still translate to quite a large number of users effected (4) and OP_CHECKLOCKTIMEVERIFY won't save you here. You seem to be assuming that once Bitcoin Core merges the patch that all your problems will go away, but this relies on the assumption that alt-coins will actually merge Bitcoin Core's patches and stay up to date when generally they don't. There are still patches that were made to Bitcoin core in 2012 that have yet to be merged with Litecoin and I'm guessing it's the same story with other alt-coins too. Thus, alt-coins that aren't forked after the patches are likely to remain vulnerable to TX malleability for years - possibly indefinitely.

Of course, you could fix this whole nasty problem in a day by adding fail-safe keys to your scheme, that way if the money is locked you can still mediate ... but if you decide to do that, you then have to worry about the security of the keys and you couldn't claim that your scheme was entirely trustless if  full mediation was required.

2. Partial matching. From my understanding of your code there doesn't seem to be a mechanism for partial matching. In practice, this would mean that your users would have to wait for 8~  confirmations * confirm_time minutes (80 minutes for Bitcoin!) between every match (and large orders may require hundreds of them.) The problem comes from the fact that Bitcoin transactions are like hierarchical trees, that outputs must be spent in full, and that the distribution of amounts amongst outputs isn't guaranteed to be optimal for matching trades. Consequently, any given match - even for a small amount - could make 100% of the coins in your wallet unavailable until the contract was confirmed (which would make it incredibly painful to match trades.)

A proper exchange needs to support partial matching (5) to be able to efficiently match orders and I'd argue its even more important for "decentralized" exchanges as trades are already thousands of times slower than centralised exchanges because of the block chain.

3. Non-standard transactions. Since this is getting too long I'll just summarise this point: cross-chain contracts rely on non-standard transactions whose propagation is outright rejected on most alt-coins. The result is your contracts likely won't work on the main network and if  it does: confirmation time will take hours rather than minutes. This is a huge issue because you can't fix the lack of transaction support with any coding patch. It's an immovable object built directly into the parameters of the network and the only way around is to be able to influence the miners directly into accepting your non-standard transactions. You probably won't have this problem on the Bitcoin side because the IsStandard() rules were recently relaxed (2), but on alt-coin I can see you pulling your hair out (6) (7)
 
tl; dr, your design has major problems that you need to fix. These are all problems I've had to address in my design so if this criticism comes off as too vague I'm happy to elaborate.

(0) https://eprint.iacr.org/2012/248.pdf
(1) There have been reports of widespread transaction mutation on the main network. An attacker might already have the capabilities I've discussed.
(2) https://github.com/bitcoin/bitcoin/pull/4365/files
(3) I have a five line function in my repo - literally five lines, and it will mutate transactions on most alt-coins:
   

def mutate_tx(tx_hex):
    """
    Mutates a raw transaction using TX malleability in the scriptSig (specifically, the OP codes.) This function shouldn't be used beyond testing as it uses an ugly eval() hack.

    https://en.bitcoin.it/wiki/Transaction_Malleability
    """
    tx = CTransaction.deserialize(binascii.unhexlify(tx_hex))
    script_sig = repr(tx.vin[0].scriptSig)[9:]
    script_sig = eval("CScript([OP_1, OP_DROP, " + script_sig)
    tx.vin[0].scriptSig = script_sig
    return b2x(tx.serialize())
   

(4) I'd argue even 1 user effected would be bad since there's potentially no way to retrieve the money if  the other side discards the key.
(5) A simple solution is to sort the order book in descending order but that still doesn't guarantee optimal matching.
(6) Tier-Nolan came up with a solution to this that only requires non-standard transactions on one side of the trade. The details are available here: https://github.com/TierNolan/bips/blob/bip4x/bip-atom.mediawiki
(7) I really like cats.
( 8 ) The window of time for such attacks would be possible depending on how close the attacker was on the network to the broadcasting node. If we assume around 50 - 400ms latency between hops, then the arrival time for the initial transaction would still make a double-spend possible given the current network propagation delays: http://bitcoinstats.com/network/propagation/

And now I'm done editing.

Thanks, that's probably the best-written and most thoughtful feedback I have received yet.

1. Transaction malleability. I agree completely that malleability is a major concern and I am not satisfied with the attack only being costly to perform. However, it is at least a better situation than the experiments in the paper you linked since those researchers were in possession of the double-spend TX at the same time as the attack TX. In my case, the "deposit"/"bond" TX is not directly sent to the would-be attacker directly which makes it at least slightly more unlikely to get the transaction fast enough to perform the attack. Additionally, the Mercury trade server already helps out by being well-connected to miners and relaying the transactions (but this means traders are trusting the Mercury servers to not perform the malleability attack, which of course I am not planning on doing). These are only precautions for the time being, I don't plan on making a marketing effort for Mercury until the protocol is secure against malleability attacks.

Obviously OP_CHECKLOCKTIMEVERIFY is the real solution, and while it is a painful barrier that all coins will need to adopt it, I believe I can lobby coins to put in that patch (thankfully it only requires a soft fork, not a hard fork). Micropayment channels, cross-chain atomic swaps, and any other contract protocols that need to have refunds all rely on OP_CLTV so it has a good case for being merged in.

2. Partial matching. Interesting point, I had not thought of that. But I must be missing something, because I do not understand where your "8 confirmations" figure is coming from. Trades will be able to be made safely with far less than 8 confirmations (maybe even 0 for small-value trades), and outputs are not  tied up while contracts are confirming. As soon as the deposit transactions are spent, the change should be spendable (however, chaining too many unconfirmed transactions could cause problems). If I'm understanding your point correctly, it can be solved simply by breaking up outputs in the wallet into many smaller outputs (balanced at a good size that doesn't make transaction sizes prohibitively large).

3. Non-standard transactions. This is already a solved issue since I am using TierNolan's clever protocol that only requires one chain to support non-standard transactions. Bitcoin Core 0.10 relaxes the rules and has already been adopted by ~40% of the network, and empirically my non-standard transactions are getting confirmed into blocks in 20-30 minutes on average (and will get faster as more miners update over time).

[vokain]

nice it looks like good work., any chance we see Monero on it?

Sure, Monero is a good candidate since it has a good amount of trade volume. I'll try to get it in the next release or two.

I think the bigger deal is having a trustless protocol for people to exchange bitcoins for XMR (when seeking financial privacy) and XMR for BTC (to access more merchants).

[iCEBREAKER]

nice it looks like good work., any chance we see Monero on it?

Sure, Monero is a good candidate since it has a good amount of trade volume. I'll try to get it in the next release or two.

I think the bigger deal is having a trustless protocol for people to exchange bitcoins for XMR (when seeking financial privacy) and XMR for BTC (to access more merchants).

Distributed xmr.to and xmr.me!   

Besides XMR (for volume) I vote VIA, XPM, and XCN as worthwhile inclusions, plus the standard/classic PPC and NMC, based on tech and PoW diversity.

VIA has CHECKLOCKTIMEVERIFY and a native Clearinghouse platform for Intellihashing^TM.

XCN has custom transaction messages, unmalleable transactions, and withdrawal limits.

[GingerAle]

^^^ OP and another dude currently working on a similar project .....


any reason why you guys aren't teaming up?

I mean, I know I have no grounds to comment on how you're developing things, because I can't develop, but it would seem to me that if you are both creating the same thing, and its decentralized, and at least one of them is open source.... whats the benefit of developing solo?

Convergent evolution does have its advantages - you may come up with unique solutions to the same problem that can ultimately strengthen the general ecosystem via diversity. But collaboration also has its advantages.

[Uptrenda]

Thanks for replying to me mappum. It's good to see you have a plan for the malleability issues because once that's fixed your scheme will be quite an elegant and simple approach to the trust problem. I also wasn't aware you were already using TierNolan's more realistic approach to cross-chain trading. That should be fine and it shouldn't cause too much inconvenience because you probably don't want to support arbitrary currency pairs anyway since there's currently hundreds of currencies so maybe only having restricted pairs (pairs with at least 1 side supporting the non-standard TX) would be better for liquidity. For example you could have say: the major currencies like Bitcoin and Litecoin serving as proxies for the lesser known alt-coins.

I thought of another possible attack for your exchange, btw. Not sure if you've thought of this issue yet but the actual deposit of funds isn't done atomically so an attacker could just reply to a large number of trades, pretend that he's going to go through with them and then just never proceed with his deposit. Obviously there would be no loss of funds here because of the time-locked refund but I am suggesting the attack could be used to DoS the order book and cause people to waste a large amount of time. Not sure on the exact details of your matching system but from what I can tell it seems to be pretty trusting.

(Your account idea would be a simple way to solve this.)

^^^ OP and another dude currently working on a similar project .....


any reason why you guys aren't teaming up?

I mean, I know I have no grounds to comment on how you're developing things, because I can't develop, but it would seem to me that if you are both creating the same thing, and its decentralized, and at least one of them is open source.... whats the benefit of developing solo?

Convergent evolution does have its advantages - you may come up with unique solutions to the same problem that can ultimately strengthen the general ecosystem via diversity. But collaboration also has its advantages.

Yeah, and to make matters worse I was even working on the exact same contract concept as mappum 6 months ago. It was actually my questions to TierNolan that prompted him to improve his contract protocol but I ended up not using it because I thought of a different solution. Maybe if I knew mappum was interested in this we would have a working beta by now but I guess that ship has sailed...

We now both have created completely different systems with completely different technologies and I doubt either one of us would want to merge. It's a shame really. But who knows, maybe we could work together in some small way? I know we're certainly not the only guys working on a decentralized exchange ATM, but we may be the first to make a practical one for alt-coins.

[becool]

Help us please.
It is not my picture. Other man screenshot it.
But I have some problem.
199 it is my too, but i sell this 199 dogs, and have some error.

"Canceled. Something went wrong, your funds where returned to you"

We want trade in mercury exchange.

[mappum]

Help us please.
It is not my picture. Other man screenshot it.
But I have some problem.
199 it is my too, but i sell this 199 dogs, and have some error.

"Canceled. Something went wrong, your funds where returned to you"

We want trade in mercury exchange.

Thanks for letting me know. Could you please PM me a link to your debug log so I can see what happened? It is located at ~/.mercury/logs/debug.log (on Windows, replace ~ with C:/Users/<username>).

[watashi-kokoto]

Hi. What about the situation when miner create cheaper order and give to orderer for original price, claiming profit??

[Jeremycoin]

Is there any "fee" for exchange?

[CryptInvest]

Is there any "fee" for exchange?

Yes, comission bitcoin network for transaction 10.000 satoshi, DOGE = 1, LITE - unknown.

[coinits]

Yeah this is a good attempt but it doesnt work!

Transaction malleability will destroy any trade. ONLY coins with checklocktimeverify can do AT. I also think Qora has it. If you try AT without it, you are going to run into Malleability and one partly will lose all their Bitcoins.

Also, SPV clients rely on a server correct?!? Then its not trustless because the servers data could be interfered with to say a tx has confirmed when it hasnt causing you to submit your TX and give the attacker coins. I might be misunderstanding SPV but from what I'm reading it communicates with servers and thus their data can be spoofed and it requires a lot of trust.

I would recommend manually rewriting the clients and pruning the blockchain instead of SPV. And then you can only wait for a Malleability patch or Checklocktimeverify.

BURST has successfully implemented AT , proof is here : http://ciyam.org/at/

All else can be mostly read on its bitcointalk thread https://bitcointalk.org/index.php?topic=731923.0

Here is also a little article , read also the comments , it seems Vitalik tries to talk it down out of envy … https://www.cryptocoinsnews.com/cryptocurrency-burst-makes-smart-contracts-reality-happened-ethereum/

Agreed but they are working on their own trustless exchange so it would seem that communication between communities will benefit everyone. I also suggest that Monero be added. A true private crypto and a bvery active community that would support a trustless exchange.

[Yaremi]

Hi dev, Please check CRAVE https://bitcointalk.org/index.php?topic=997356.5680

we would like to be sure you add us to

Thanks!

[Jeremycoin]

What do you mean with "trustless"? Whether we can trus this cryptocurrency or what?

[GingerAle]

What do you mean with "trustless"? Whether we can trus this cryptocurrency or what?

This is an exchange.

Usually, you have to trust that the exchange does not get hacked or the operators run away with your money.

With a decentralized exchange, there is no trust, because its all happening in the various blockchains.

[Jeremycoin]

What do you mean with "trustless"? Whether we can trus this cryptocurrency or what?

This is an exchange.

Usually, you have to trust that the exchange does not get hacked or the operators run away with your money.

With a decentralized exchange, there is no trust, because its all happening in the various blockchains.

So, for using this currency is not that easy right
It's a hard work to do it, but nevertheless it can make a good profit.