Topic: Mercury - Fully trustless cryptocurrency exchange - Looking for testers! - page 3. (Read 35182 times)

Kids and their pocketmoney following such a usable and liquid currency 

Make sure also to add CYPHER, +64 bitcoin of volume in less than 24 hours (it is on bittrex, c-cex, yobit and alcurex). Someone said "it is the new cravecoin" with hardnodes.

Mercury is not a currency. Its an exchange.

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.

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.

+1

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

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

we would like to be sure you add us to

Thanks!

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.

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

Is there any "fee" for exchange?

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

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

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


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.

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

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.

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

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:
   (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.