Bitcoin Forum
April 25, 2019, 03:02:38 PM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 [2] 3 4 5 6 7 8 9 10 »  All
  Print  
Author Topic: Mercury - Fully trustless cryptocurrency exchange - Looking for testers!  (Read 34806 times)
mappum
Member
**
Offline Offline

Activity: 81
Merit: 10


View Profile
February 07, 2015, 12:31:17 AM
Last edit: February 07, 2015, 01:13:56 AM by mappum
 #21

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.
PLAY NOW
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1556204558
Hero Member
*
Offline Offline

Posts: 1556204558

View Profile Personal Message (Offline)

Ignore
1556204558
Reply with quote  #2

1556204558
Report to moderator
1556204558
Hero Member
*
Offline Offline

Posts: 1556204558

View Profile Personal Message (Offline)

Ignore
1556204558
Reply with quote  #2

1556204558
Report to moderator
1556204558
Hero Member
*
Offline Offline

Posts: 1556204558

View Profile Personal Message (Offline)

Ignore
1556204558
Reply with quote  #2

1556204558
Report to moderator
mappum
Member
**
Offline Offline

Activity: 81
Merit: 10


View Profile
February 07, 2015, 01:06:16 AM
Last edit: February 07, 2015, 02:01:21 AM by mappum
 #22

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
Newbie
*
Offline Offline

Activity: 3
Merit: 0


View Profile
February 07, 2015, 01:26:19 AM
 #23

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

Activity: 1792
Merit: 1026


View Profile
February 07, 2015, 08:38:49 AM
 #24

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
Member
**
Offline Offline

Activity: 81
Merit: 10


View Profile
February 07, 2015, 09:53:40 PM
 #25

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
Newbie
*
Offline Offline

Activity: 24
Merit: 0


View Profile
February 07, 2015, 11:41:54 PM
 #26

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
Member
**
Offline Offline

Activity: 81
Merit: 10


View Profile
February 08, 2015, 03:05:41 AM
 #27

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
Legendary
*
Offline Offline

Activity: 1792
Merit: 1026


View Profile
February 08, 2015, 05:22:01 AM
 #28

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
Legendary
*
Offline Offline

Activity: 1792
Merit: 1026


View Profile
February 08, 2015, 05:32:15 AM
 #29

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
Member
**
Offline Offline

Activity: 81
Merit: 10


View Profile
February 08, 2015, 08:50:46 AM
 #30

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
Legendary
*
Offline Offline

Activity: 1792
Merit: 1026


View Profile
February 08, 2015, 08:15:25 PM
Last edit: February 08, 2015, 09:53:04 PM by dzimbeck
 #31

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
Hero Member
*****
Offline Offline

Activity: 654
Merit: 500


Evolution is the only way to survive


View Profile
February 09, 2015, 10:22:29 AM
 #32

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

Activity: 81
Merit: 10


View Profile
February 10, 2015, 10:01:52 AM
 #33

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

I PMed you with the link. Smiley
provenceday
Legendary
*
Offline Offline

Activity: 1148
Merit: 1000



View Profile
February 10, 2015, 01:16:55 PM
 #34

Will watch this project.
Arnab biswas
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
February 10, 2015, 02:47:29 PM
 #35

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

▲▼▲▼▲▼▲▼ No.1 Bitcoin Binary Options and Double Dice ▲▼▲▼▲▼▲▼ █████████████████ ███████████████ sec◔nds trade █████████████████ ███████████████ ↑↓ Instant Bets ↑↓ Flexible 1~720 minutes Expiry time ↑↓ Highest Reward 190% ↑↓ 16 Assets [btc, forex, gold, 1% edge double dice] ↑↓[/ url]
jabo38
Legendary
*
Offline Offline

Activity: 1204
Merit: 1000


mining is so 2012-2013


View Profile WWW
February 15, 2015, 03:20:14 PM
 #36

This looks great!

blacklizard
Full Member
***
Offline Offline

Activity: 139
Merit: 103


View Profile
February 15, 2015, 06:35:35 PM
 #37

@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
Legendary
*
Offline Offline

Activity: 1918
Merit: 1022



View Profile
February 15, 2015, 11:16:17 PM
 #38

With several exchanges hacked in the last 24 hours, this is looking more relevant than ever...
bassguitarman
Hero Member
*****
Offline Offline

Activity: 728
Merit: 500



View Profile
February 15, 2015, 11:27:08 PM
 #39

@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
Member
**
Offline Offline

Activity: 81
Merit: 10


View Profile
February 17, 2015, 12:15:17 AM
 #40

@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.
Pages: « 1 [2] 3 4 5 6 7 8 9 10 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!