Pages:
Author

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

member
Activity: 82
Merit: 13
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).
legendary
Activity: 2412
Merit: 1044
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.
newbie
Activity: 3
Merit: 0
+1 for NuBits support. We'll be watching this project with great interest!
member
Activity: 82
Merit: 13
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.
member
Activity: 82
Merit: 13
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.
sr. member
Activity: 269
Merit: 252
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://bitcointalksearch.org/topic/annburst-burst-efficient-hdd-mining-new-123-fork-block-92000-731923

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/

legendary
Activity: 2412
Merit: 1044
Although I see your response and P2SH is maybe only slightly more expensive to change TXID, I used to quote articles on that. However, I believe its a lot easier than you realize to change the txids. You dont need to mine the block, only get access to the mempool and inject your changed TX to other pools in the hopes they get mined. I really would not risk users funds like this. If it happens even once, they lose all their coins.
legendary
Activity: 2412
Merit: 1044
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.
member
Activity: 82
Merit: 13
How long till launch?

I'll release the alpha within the next 2 weeks, stay tuned!
full member
Activity: 189
Merit: 100
I'm interested in testing as well.
legendary
Activity: 1764
Merit: 1000
Mercury exchange looks promising, hopefully will be able to use it when it formally launch. Wanting to see more coins get listed on it.
Thanks.
hero member
Activity: 765
Merit: 503
I vote for coloured coins as next feature Smiley
sr. member
Activity: 269
Merit: 252
Please add the very innovative BURST to your Project , it's JAVA based so that should make it easier …

Burst community and Devs are very active and helpful , too .

All the Best !

BURST Source Code https://github.com/BurstProject/burstcoin
member
Activity: 82
Merit: 13
At first glance, it looks like it's vulnerable to transaction malleability, though. Do you have a way to defend against the following attack?

That's a reasonable concern. It will be completely solved once OP_CHECKLOCKTIMEVERIFY is implemented in Bitcoin Core (refunds can then come from a timelocked output, instead of a pre-signed timelocked refund transaction). Until then, changes in Bitcoin Core 0.9 have made mutating transactions expensive enough that this should not be a huge issue (the attacker would need to mine the mutated transaction in a block). The alpha version of Mercury only allows trading with the Bitcoin Testnet, and before I open it up to real trading I'll have to be sure this attack is not viable.
sr. member
Activity: 283
Merit: 250
How long till launch?
member
Activity: 93
Merit: 10
I wish you to carry forward your development, being trustless lot of core, hack possibilities there. Too far to go to have an secured working exchanger. Will see if I can test it.
newbie
Activity: 24
Merit: 0
This looks great!

A decentralized exchange is tantalizingly close.

At first glance, it looks like it's vulnerable to transaction malleability, though. Do you have a way to defend against the following attack?

In this context:

Quote
B creates TX3: "Pay v alt-coins to if (x for H(x) known and signed by A) or (signed by A & B)"
 
B creates TX4: "Pay v alt-coins from TX3 to , locked 24 hours in the future, signed by B"
 
B sends TX4 to A
 
A signs TX4 and sends back to B
 
 2) B submits TX3 to the network

A broadcasts an equally valid TX3' with a different hash, which eventually gets into the blockchain instead of TX3. (A has deliberately made connections to many more nodes than B, so A will receive TX3 quickly and can then send TX3' to many nodes in one hop.)

Now TX4 is useless. A waits until his timelock expires and gets his coins back. B's coins are stuck.

A watches the Mercury community's public discussions to see if anybody complains that their coins are stuck.

If so, A creates TX5: "Pay 0.5*v alt-coins from TX3' to A and 0.5*v alt-coins to B", signs it, and sends B a private message saying,
"Hello B,

I'm scamming you. You can sign TX5 and get half of your coins back. Or not. It's up to you.

Don't bother replying. I won't read it.

Your friendly scammer,
A"
hero member
Activity: 728
Merit: 500
legendary
Activity: 1680
Merit: 1001
CEO Bitpanda.com
This looks awesome. Once you are out of Beta, I will sure use it!
Pages:
Jump to: