Mercury - Fully trustless cryptocurrency exchange - Looking for testers!

[mappum]

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.

That is incorrect, SPV is considered trustless (even by Satoshi in the original Bitcoin whitepaper). The blockchain can still be verified by SPV clients using the headers, and transactions can be verfiied as being in the chain using Merkle branches.

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.

OP_CHECKLOCKTIMEVERIFY is not the only way to solve the problem, preventing any sources of malleability will also prevent this attack. Bitcoin Core 0.9 made a lot of advances in making malleability harder. Bitcoin Core 0.10 (which should be released any day now) makes the signature encoding more strict to prevent malleability in the signature (BIP 66).

You're right, we're not 100% secure against this attack yet, which is why the alpha version of Mercury only supports testnet trading. As soon as it seems we are safe (no cheap sources of malleability, or OP_CHECKLOCKTIMEVERIFY), Mercury can open up to real trading.

[1714140490]

1714140490

[mappum]

Additionally, a way to solve the malleability attack is to require party A to deposit some coins into party B's initial multisig deposit. If A mutates the transaction, they are also tying up their own funds in the process. This solution is already possible today, I may implement it in the Mercury alpha.

[NuProject]

+1 for NuBits support. We'll be watching this project with great interest!

[dzimbeck]

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.

That is incorrect, SPV is considered trustless (even by Satoshi in the original Bitcoin whitepaper). The blockchain can still be verified by SPV clients using the headers, and transactions can be verfiied as being in the chain using Merkle branches.

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.

OP_CHECKLOCKTIMEVERIFY is not the only way to solve the problem, preventing any sources of malleability will also prevent this attack. Bitcoin Core 0.9 made a lot of advances in making malleability harder. Bitcoin Core 0.10 (which should be released any day now) makes the signature encoding more strict to prevent malleability in the signature (BIP 66).

You're right, we're not 100% secure against this attack yet, which is why the alpha version of Mercury only supports testnet trading. As soon as it seems we are safe (no cheap sources of malleability, or OP_CHECKLOCKTIMEVERIFY), Mercury can open up to real trading.

Ok thanks for the link to the SPV paper thats really good to know. When I looked it up it was saying it relied on servers. In that case I would really like to use that in future implementations in my software as well.


Ok the new bitcoin core will not solve the problem. Even a 1% chance of malleability will end up becoming 100% with a dedicated scammer. For example, your program works with raw transactions. So I only need to hold on to the raw, change it a little bit and send it to as many pools and nodes as possible. If they mine my fake TX, then your TX will be considered bad and declined. Both parties work with raw transactions, thats the problem. So I can hold a bad copy and interfere.

I'm not trying to deter you, I'm genuinely concerned about this issue. As you may or may not know, Im the guy from BitHalo. One of the implementations of BitHalo is microtrading which is trustless. I used to consider AT but realized it was way too dangerous. I'm sure some Hero members or more crypto guys can comment on this.

[mappum]

Ok the new bitcoin core will not solve the problem. Even a 1% chance of malleability will end up becoming 100% with a dedicated scammer. For example, your program works with raw transactions. So I only need to hold on to the raw, change it a little bit and send it to as many pools and nodes as possible. If they mine my fake TX, then your TX will be considered bad and declined. Both parties work with raw transactions, thats the problem. So I can hold a bad copy and interfere.

"Sending the TX to as many pools and nodes as possible" is the part made difficult by newer versions of Bitcoin Core, nodes will now reject transactions that use e.g. non-standard signature encodings. The only way to get it in a block would be for a miner to be on a old version of Bitcoin Core, or for the attacker to mine the transaction themselves (which is expensive).

[fatbitcoinfan]

Additionally, a way to solve the malleability attack is to require party A to deposit some coins into party B's initial multisig deposit. If A mutates the transaction, they are also tying up their own funds in the process. This solution is already possible today, I may implement it in the Mercury alpha.

If A has to do that before B puts up any money, then doesn't that give B a chance to blackmail him?

That is, instead of proceeding with the transaction, B says, "Your coins are now inaccessible without my co-operation. You can get half back and give half to me, or get none back. Your choice."

Re: malleability, I think there are still a few parts of BIP62 that aren't implemented yet and there might be sources of malleability still undiscovered. It'll take time to become confident, but it'll happen eventually.

[mappum]

If A has to do that before B puts up any money, then doesn't that give B a chance to blackmail him?

That is, instead of proceeding with the transaction, B says, "Your coins are now inaccessible without my co-operation. You can get half back and give half to me, or get none back. Your choice."

No, it could be done trustlessly with SIGHASH_ANYONECANPAY. The deposit TX wouldn't be valid until both parties put in their inputs and sign it (they are both paying in the same TX). I'm not yet 100% convinced that scheme can work, and it's an inconvenience to users since they have to have collateral to be able to trade, but intuitively it seems like it could help.

[dzimbeck]

Ok the new bitcoin core will not solve the problem. Even a 1% chance of malleability will end up becoming 100% with a dedicated scammer. For example, your program works with raw transactions. So I only need to hold on to the raw, change it a little bit and send it to as many pools and nodes as possible. If they mine my fake TX, then your TX will be considered bad and declined. Both parties work with raw transactions, thats the problem. So I can hold a bad copy and interfere.

"Sending the TX to as many pools and nodes as possible" is the part made difficult by newer versions of Bitcoin Core, nodes will now reject transactions that use e.g. non-standard signature encodings. The only way to get it in a block would be for a miner to be on a old version of Bitcoin Core, or for the attacker to mine the transaction themselves (which is expensive).

By the way, congrats so far. Its nice to see more people out there writing software and you are very familiar with scripting which is awesome. Anyways, you think that the new Bitcoin Core will not have any malleability at all? If I possess the new Bitcoin Core, and I have on me a raw transaction you are saying there is no way I can alter a single byte to change the txid? Anyways do you have any good links on that. I'm not so sure about this. If I've got the raw tx, it shouldn't  be hard.

[dzimbeck]

I'm reading bip 66 now. +1 for removing OpenSSL. Its such a pain in the butt and there is no reason open source high security software should be trusting it. Also, I do a lot of work in Bitmessage and really would love to implement an alternative. The paper I read says "reducing malleability" not eliminate. When both parties are communicating p2p, they are holding on to the raws. With that raw tx malleability is so much easier, they dont need to be a miner to intercept it, they have it right there. Regardless, its a good idea to position yourself for AT because eventually all the coins should improve their own protocols. I'm happy to notice that Blackcoin just added checklocktimeverify preparing for v3.

Of course checklocktimeverify requires a hard fork and I can't imagine Bitcoin forking. And also, how can they add it and convince everyone to update their custom clients because with checklocktimeverify you can refund your own money if they counterparty isn't paying attention to the script.

[mappum]

The paper I read says "reducing malleability" not eliminate. When both parties are communicating p2p, they are holding on to the raws. With that raw tx malleability is so much easier, they dont need to be a miner to intercept it, they have it right there. Regardless, its a good idea to position yourself for AT because eventually all the coins should improve their own protocols. I'm happy to notice that Blackcoin just added checklocktimeverify preparing for v3.

"Raw" transactions aren't a part of the protocol, only part of the bitcoind API. I assume you mean that the protocol involves parties sending incomplete transactions to each other? In my implementation, the deposit transaction (the one that would get mutated) is never send between the parties, only its hash.

Of course checklocktimeverify requires a hard fork and I can't imagine Bitcoin forking. And also, how can they add it and convince everyone to update their custom clients because with checklocktimeverify you can refund your own money if they counterparty isn't paying attention to the script.

Actually, OP_CHECKLOCKTIMEVERIFY could be added in a soft fork.

[dzimbeck]

The paper I read says "reducing malleability" not eliminate. When both parties are communicating p2p, they are holding on to the raws. With that raw tx malleability is so much easier, they dont need to be a miner to intercept it, they have it right there. Regardless, its a good idea to position yourself for AT because eventually all the coins should improve their own protocols. I'm happy to notice that Blackcoin just added checklocktimeverify preparing for v3.

"Raw" transactions aren't a part of the protocol, only part of the bitcoind API. I assume you mean that the protocol involves parties sending incomplete transactions to each other? In my implementation, the deposit transaction (the one that would get mutated) is never send between the parties, only its hash.

Of course checklocktimeverify requires a hard fork and I can't imagine Bitcoin forking. And also, how can they add it and convince everyone to update their custom clients because with checklocktimeverify you can refund your own money if they counterparty isn't paying attention to the script.

Actually, OP_CHECKLOCKTIMEVERIFY could be added in a soft fork.

Yeah and the party has a raw tx, which they have the power to change by slightly altering the sig.

[p2pbucks]

If Mercury succeeded ,  it would be the killer APP of whole crypto industry .
I want to be a preAlpha-version tester  

[mappum]

If Mercury succeeded ,  it would be the killer APP of whole crypto industry .
I want to be a preAlpha-version tester  

I PMed you with the link.

[provenceday]

Will watch this project.

[Arnab biswas]

sooo cooolll.....I will surely download it right now 

[blacklizard]

@mappum awesome project!

Please do add support for the open assets protocol / colorcore. This is much needed in crypto and by far not supported enough.

Thanks for considering.

[jwinterm]

With several exchanges hacked in the last 24 hours, this is looking more relevant than ever...

[bassguitarman]

@mappum awesome project!

Please do add support for the open assets protocol / colorcore. This is much needed in crypto and by far not supported enough.

Thanks for considering.

Agreed, colored coins are bitcoin2.0 on bitcoin1.0, their potential is amazing

[mappum]

@mappum awesome project!

Please do add support for the open assets protocol / colorcore. This is much needed in crypto and by far not supported enough.

Thanks for considering.

I'm definitely planning to implement colored coins in Mercury. I expect a lot of interesting colored coin cryptoassets becoming available in the near future, and it would be cool to have Mercury be the most popular exchange for them as they start getting adopted.

Any ideas about which colored coin implementations are best? I'm hearing a lot about Open Assets, but I have a lot of faith in the Chromawallet team.

[timgri]

Could a service for automatic portfolio rebalancing be developed out of this?


Just posted this in the ethereum forum: http://forum.ethereum.org/discussion/1844/automatic-portfolio-rebalancing/p1

Would it not be nice to have a etherium service that could automatically rebalance a portfolio with a number of cryptocurrencies? With rebalancing i mean that when there is a change of the value of one of the currencies, it is bought or sold so as to keep the ratio between the currencies in the portfolio constant.

Do you know of such a service?

Best / Tim