Mercury uses atomic swap trades, its a simple matter of modifying the client to steal from any potential traders. Be wary.
I’m calm as I can’t get trades executed.
This sounds like a problem, that’s been tackled in several p2p applications like bittorrent and eMule.
I thought eMule had a working system to detect (modified) and ban hostile clients.
You can only execute trades with test coins.
They have all the fluff using a centralized server with no actual content - how to trade? Decentralized exchanges haven’t been created yet because it is hard to find a solution to the how to trade question not the how to store an orders in a decentralized way but they didnt even do that they use central server for order data. So far it is gimick until they provide code for the hard part of the problem which is not making a pretty UI.
Hostile clients that steal potentially lots of money and just change their key and ip address? Seems like a bad solution.
I tried to exchange Testnet BTC with main chain Dogecoin. The orders were visible in both clients but I could not buy / sell.
My experience and knowledge about bad-client detection in p2p networks is near zero. sorry.
@tehter my understanding was, that those trades are executed on blockchain. Can you explain briefly how an attacker would cheat on the blockchain?
I was talking with Matt from Mercury. He told me about some further technical requirements, that I can’t really appraise.
Here is what he told me:
I’m open to Nubits being on Mercury, but there are some technical
details that would need to be addressed before Nubit-centric trading can
be possible (the way things are now, Nubits could only be trustlessly
traded with Bitcoin). One is the ability to accept nonstandard
transaction scripts onto the network, Bitcoin Core 0.10 just made this
possible on Bitcoin, the Nubits developers would have to do the same.
Also, another is implementing OP_CHECKLOCKTIMEVERIFY, an addition to the
script system that would make trading much more robust (Bitcoin does
not yet have this, so implementing it would give Nubits an edge for
trustless trading).
Any thoughts from the devs? @JordanLee e.g.?
2 Likes
Yes they happen on the blockchain, but they are atomic. So they hope one person to write a custom client that initiates a trade, lets the other trader give them money and but have customizations that prevent them from sending their portion of the trade. Which is why the author is hoping OP_CHECKLOCKTIMEVERIFY will be implemented. But until that is a reality, they are just building fluff.
Ensuring early adoption of NuBits on decentralized exchanges is very important to lowering liquidity costs
Regarding OP_CHECKLOCKTIMEVERIFY, we should consider adding it to facilitate NuBit use on emerging decentralized exchanges such as Mercury. I won’t have time to research the issue for some time, so I’m wondering if @erasmospunk or @sigmike can look into this.
It is worth noting that OP_CHECKLOCKTIMEVERIFY is remarkably similar to parking, which suggests the following questions:
- Do we want to suggest Mercury use our parking mechanism instead of OP_CHECKLOCKTIMEVERIFY? Right now the protocol does not permit parking for zero premium, but changing the protocol to allow this is already planned for the next protocol release (formerly known as 0.6.0 but will be called 2.0 going forward).
- Another option is to implement OP_CHECKLOCKTIMEVERIFY but have it encapsulate the parking mechanism. Would this be optimal from the perspective of conforming to an emerging standard?
- We could also implement OP_CHECKLOCKTIMEVERIFY completely independent of the parking mechanism. We would need to evaluate how OP_CHECKLOCKTIMEVERIFY and parking might interact in our system (what happens if you use OP_CHECKLOCKTIMEVERIFY on an output and then attempt to park it?)
One thing to keep in mind is that parking is for a specific block duration, whereas OP_CHECKLOCKTIMEVERIFY can be for a block duration or a time duration.
I’m hoping someone will have time to research these issues, as I probably won’t be able to for a couple of weeks.
2 Likes
Hi @JordanLee, I am following Peter Todd’s OP_CHECKLOCKTIMEVERIFY proposal for quite a while so let me share what I know. The proof-of-concept is quite old and Peter submitted the draft last October as BIP 64 for Bitcoin:
I wouldn’t say that it is similar to parking, since the OP_RETURN field will not be used. Instead, it is just another ScriptSig operator that asks for a block height as integer (nLockTime) and clients agree that these funds are unspendable until the block height was reached.
In the “Detailed Specification” section of the document above you will see what I mean. It is extremely simple to implement. I can even point you to a PPC fork which already has it (the full commit contains 85 lines).
3 Likes
Haha that is the question all the Bitcoin main developers are fighting about, but Bitcoin is of course extremely conservative. In my opinion OP_CHECKLOCKTIMEVERIFY enables many use-cases and it is unlikely that it will lead to any unforeseen consequences. Compared to all the Nu stuff this protocol change can probably be considered as totally safe 
So yes, I would say we should make this operator. Of course special care has to be taken with parking and burning.
EDIT: Well with “we” I of course actually mean you if you are planning to implement it before going open-source. Ideally it should be combined with the 0.6 hard fork.
Nice to hear that there is interest in OP_CHECKLOCKTIMEVERIFY as it mitigates the risk of trasaction maleability and refund transactions when we deal with atomic cross-chain trading.
It is interesting to combine the parking feature with OP_CHECKLOCKTIMEVERIFY but we have to be very careful as the unpark transaction creates NBT.
1 Like
Regarding the parking transaction, the output could be replaced with something like this:
<unpark time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
The part after OP_DROP is the classical Pay-to-PubkeyHash
This parking output will contain more money than the inputs so the minter must validate that this amount is correct one factoring the current parking rates and the time the money will stay parked.
This transaction output will be spent like a normal transaction with the only difference is that the new transaction must set the nLockTime field to be after the <unpark time> and before the current network time.
One advantage is that there is no need for one separate unpark transaction because the output becomes spendable after a specific amount of time and it is not necessary to spend it once the time passes, it only needs to appear in the UI as spendable.
Mercury just got an update to 0.0.2
There is a bug hunt for Mercury on
https://www.crowdcurity.com/mercury
I would really like to see your explanations there, and the best thing: you will get a bounty!
I’m too busy building an actual distributed and decentralized exchange to review their java GUI.
They don’t even store the orders in a decentralized way, you connect to their centralized server that manages the orderbook. It would be very easy for them to cheat by switching around orders and giving them a lead on price changes. It is fluff.
1 Like
Any announcements soon?
More than an exchange apparently:
Quote from the home page
Price Growth, no more volatility
An upcoming revolutionary change is coming to crypto-currency in the Halo platform. We are working on a currency that has the ability to inflate and deflate. Interest rates are controlled by votes and thus, users can grow their own coin in a stable fashion ending the era of the infamous “pump and dump”. You will be able to sell reserve bonds, perform advanced contracts and be your own bank. For Blackcoin, this sister currency will be a stable hedge adding health to the economy.
They are talking about BitBay, which was launched as a scam and then recovered somehow through the developer of BlackHalo - not sure if this can be seen as serious threat. I didn’t follow it closely but I think it is safe to say that most people who got it touch with it regret it by now.
But if someone is still asking if people would wait for Nu to become open source before starting to implement their own pegging system: here is your answer.
However, the smart contract system (double escrow) is indeed interesting and although there are many critics on the idea from a game theoretical standpoint, I think this field test could be successful.
Not exactly. BlackHalo has been around for a while (at least as an alpha/beta release). David Zimbeck is the lead developer. The technology for BlackHalo was “licensed” to the BitBay team and David joined as lead developer.
Things went…poorly.
With that being said, in my opinion BlackHalo should be viewed separately from what happened with BitBay. There’s no question that David Zimbeck was involved in both and that his involvement in the BitBay fiasco certainly colors my opinion, but I don’t think it’s fair to imply that BlackHalo itself is anything more than it appears.