I don't think doing it off network changes anything about one party always being exposed to risk of having to sign first.
There's no risk of
signing first. Both signatures have to be valid before the transaction is accepted by the network. There is of course still the risk of
sending any physical goods first however.
thanks mmeijeri if we dont have a signing first problem than we dont have a sending first problem either. Lets say that i want to send you 1 bitcoin and you want to send me 100 ltc for it (lets just say thats the exchange rate). So what we do is we both send 3 bitcoins to be trapped up in this multisig transaction. If either person fails to honor his end of the deal than the other person fails to release the funds. Now if you sent but i didnt than i would lose 3 bitcoins in exchange for 100 ltc, 3 times the exchange rate, a very bad deal indeed. If i sent but you didnt than you would get my 1 bitcoin and lose the three leaving you with a loss of 2 bitcoins, not at all in your interest either.
i really love the service you are providing seongyupyoo the one thing that i would ask is that you try your hardest to implement what we have been discussing in this thread instead of trying to offer a centralized service. There would still be plenty of use for your sight in matching up buyer and seller and trying to find innovative ways to use this service for price discovery, potentially even the development of an api.
if you need help with the technicalities check out #bitcoin-dev on the IRC
Already working on it. Will be in the next revision
So, I've been designing how I'd use multi-sig for NashX, and running through all the scenarios, I found couple huge problems.
Here are the problems.
Alice sends money to the risk address, and Bob does not.
But both Bob and Alice are saying to NashX that the other party didn't risk any funds, so wants the risk funds sent back to them.
Now, there is no way to tell who actually risked the money, so NashX can't do anything about it. So the problem is now who risks first.
You might be thinking why not look at the transaction history. That's what I thought first too, but Alice has no control over from what addresses her transaction is sent from. It might show one address, or thousands of addresses, depending on how Alice has been getting her coins.
You might also be thinking, what if NashX was to initiate a transaction to send everything sent to all the from addresses distributing the sent amount evenly back to all the addresses. Well, that would work if Alice is using a standalone wallet, but if Alice is using one of those hosted wallets, then it won't get back to her. It also could be that she had a third-party like MtGox send a few bitcoins directly to the risk address, and sending sent amount back to from addresses would just be sending money to MtGox as they wouldn't credit that money back to her account. Much like the hosted wallet situation. This solution only works for those using standalone wallets. So, now deal cannot be made because nobody wants to risk first.
Only thing that can be sure, because of anonymous nature of Bitcoin and how things are transferred, is that how much can be spent from the risk address. The traders would at the end have to agree to how to split the coins that's in the risk address. Therefore raises another big problem. In order for everything to be Nash equilibrium, whoever sends first risks exact amount equal to the value of the trade, and whoever receives first must risk twice the amount of the value of the trade. So, let's say everything goes smoothly. But it in the end, Nash equilibrium is broken, because now, whoever sent first can play another strategy. Let's say Alice sent first, so she has 1 BTC risked, while Bob has 2 BTC risked. There is no way for NashX to actually know who sent how much money to it, as explained in previous problem. So, Alice and Bob has to agree on initiation a withdraw from that risk address distributing the risk amount fairly. However, since Alice has less risked, now Alice has incentive try to negotiate with Bob. The more Bob wants his 2 BTC back, more he'll be willing to take less % of the risk funds. Alice can say she wants 50% of the risk funds, when in fact she only put in 33%, and Bob 66%. Bob can't do anything about it. This means this deal was never in Nash equilibrium in the beginning because of using multi-sig in such a situatoin.
So if NashX implements multi-sig, NashX will not work. The very problem NashX solves right now, which is solving the problem of who sends first, comes back in the form of who risks first if NashX uses multi-sig. NashX also has no way to provide Nash equilibrium if it uses multi-sig because of the 2nd problem explained above. You might be saying second problem wouldn't be a problem if they both risked same amount, but then if they both risked same amount, they wouldn't be in Nash equilibrium in the first place, because neither of them would want to send first.
I thought it would work. I thought multi-sig would be awesome, but unfortunately, it's not going to work.
Only way to make it work is to change the way Bitcoin transfers Bitcoin. Unfortunately, Bitcoin will not change this drastically because it would fundamentally change things at the core, and everything that's already happened that's stored in the blockchain would need to modified as well. Essentially, it requires a new coin.
So, sadly, multi-sign transactions/addresses cannot be used for this purpose. I may not be seeing a solution to above two problems, so if anyone finds a solution to above two problems, please let me know. I will implement multi-sig then.
