Topic: could an alt chain use the nash equalibrium to solve prisoners dilema? (Read 1636 times)

Please provide a solution if you think it's not a problem. I see you're a hero member, but just claiming so doesn't make it so. Maybe I didn't explain the problems clearly, but one of the problems I mentioned is the game of chicken problem as well. And I don't know what you suggested before, so I don't know anything about what you proposed. People in this post were talking about how NashX should use multi-sig, and I was going to, until I found these problems that I cannot get around. No personal attack on what you may have proposed.

Well, the lack of a user-friendly UI for it is still a serious issue.

Nope, no that isn't a problem.

Utter nonsense.  Before you propose to change how Bitcoin works, perhaps you ought to understand it yourself.

There are all kinds of challenges in the corner-cases for doing the kinds of things addressed in this thread, but they're in the form of byzantine attackers intentionally burning money, or simple games-of-chicken holdup. (And to be clear, as I recall my suggestion of multisig on this was an answer to a very specific question, not an evaluation of the whole proposal here)

In any case, atomically getting coins into an escrow is simply not a problem.

Absolutely, the UI is the thing to solve, everything else is already part of Bitcoin. The command line / JSON - RPC interface to bitcoind already lets you deal with raw transactions, but it's not user-friendly.


Well, there are plenty of parties that will manage other people's wallets online, but I understand that's not what you want to do.

The solution may be a custom client or additions to existing clients.

Thanks, maybe he'll see something I'm not. It really would be nice, if this can be done. It would take the target off of NashX and even me. If a lot of people start using it, and the risk funds start to get big, people will start trying to hack NashX and potentially come after me and my family even. But then again, this is something everyone has to deal with, so... It would be nice to not have to deal with it though.

That would work, but how would they initiate such a thing? I don't believe bitcoin-qt or even any wallet supports this feature. I'm making a service for everyone. It has to be easy to use. If I were to do such a thing on my side, seems I would need their wallet's public key and private key, which isn't going to work.

Multi-signature is only one part of the problem, but the other part is almost trivial, except for making the UI for it user-friendly. You could use a single transaction that transfers the money from both parties' accounts to the multi-signature risk account. The transaction would specify two inputs, one for each party, in the amount agreed as risk + half of transaction fees, and one multi-signature output. To do this, the parties need to agree which UTXOs in the right amount they would use as inputs for this. Once they do this, Alice constructs the partial transaction, adds her own signature to her transaction input, and sends the partial, as yet invalid, transaction to Bob. Once Bob receives it, he adds his own signature to his own input and sends the now potentially valid transaction to the network. Only then does the combined transaction go into effect, provided the inputs exist and haven't been spent yet. Done this way, both parties will pay simultaneously or not at all.

thanks so much for taking the time to look into it! GMaxwell is the one who suggested that multi-sig could be used for this. Ill point him to this thread.

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.

Still worth the risk but unfortunate indeed.

Already working on it. Will be in the next revision

Another con is that key lost possibility is doubled - if any party lost it's key both parties lose coins.

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

If your trying to design proper escrow then you really want 3 parties, buyer, seller and broker.  Each party could put in funds and then they can be be dispersed by any 2 consenting signatures.  Ideally their should be some means to guarantee the broker is compensated so maybe their should be some minimum and maximum outputs specified at creation so only resolutions that conform to those limits are valid.  This would prevent a broker from absconding with escrow funds themselves.

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.

I don't think doing it off network changes anything about one party always being exposed to risk of having to sign first.

What if one person signed it off network, then passed the signed transaction onto the other party outside of the bitcoin network and he was expected to sign it as well and publish it?

There is, but in the end one party will have to sign first and that party is at risk of the other party never signing the other tx afterwards.

Surely there must be a way to work to-gather outside of the bitcoin network to prepare the transaction and then one of the two of you could publish it.

Hi. This is Seong Yup Yoo from NashX. Let me know if you have any questions.

I just released the 3rd revision with significant improvements, so go check it out.

http://nashx.com

Also, just to chime in on some topics discussed here, bitcoin does have protocol in place for multi signature, but this doesn't solve the problem who sends first. There has to be a third party to prevent one party from harming another for no reason.

Also, I just made a new bitcoin trading simulation game yesterday called Million Dollar Portfolio Challenge at http://milliondollarportfolichallenge.com where everybody gets $1,000,000 and make fake trades against BTC-e rates for fun, strategy practice, and competition between friends for bragging rights and what not.