Bitcoin Forum

So let me start off by saying i was inspired by this thread. https://bitcointalk.org/index.php?topic=195012.0

The question is instead of relying on a centralized system could we use an alt chain to serve the same function as nashx. nashcoin lets call it =D. Basically, each party supplies a public key and these are combined to create a shared address, which they then both send funds too and this is recorded on the blockchain and those coins will remain forever trapped on that address that neither person really owns unless both parties publish their private keys. If they do both publish their private keys than the funds could be released to previously specified address.

inorder to protect against the depletion of the money supply we could just have a never ending block reward.

What this allows us to do is solve the prisoners dilemma. We can change the incentives so people who are questioned by the cops are literally and actually no longer self interested in rating out their partners. Just think of the implications! You could do blind trades with people on the internet, no trust required!

Ill go ahead and start a bounty of 1 btc for anyone who can create this altcoin but the opportunities for early adopters would be great since this would provide much needed coin with legitimate utility to the copy coin market. Anyone who knows how to make this shouldnt need my financial support as incentive to do it!

A colored coin for freicoin is in the works, from what I have heard. I hope something like this is going to be a part of it. Freicoin is especially suited as it has demurrage which keeps the money supply stable over time, regardless of how many coins are destroyed or trapped in coin-prison. I would like to add the option of both agreeing to withdraw the trade also, with yet another pair of private keys published.

If I understand things correctly, you can already do this with Bitcoin. The protocol supports it, but not all clients / miners (or any at all) support it.

Super awesome, i just need to find a client that supports this then.

I emailed the maker of Nashx a while back  - as i thought it was great - i told him to come onto this forum

he signed up so i just forwarded this topic to him  : )

so if you have questions for him his name is Nashx and his name on the forum he will likely respond  to  them here if asked.

Cheers.

Turns out the Satoshi client does support it, but only through the command line / JSON-RPC interface. Geek-only for now.

ok so what happens if this becomes a popular thing and so coins become regularly destroyed from disputes like this. It could cause bitcoin to be FAR more deflationary than we had originally imagined. If this were the case than what would this mean for the future utility, rate of adoption, price and stability of bitcoin.

Why would there be regular destruction? If it works, that ought to be rare.

better question .....

How did we survive the 80's?

+1

see comment about 80's

We should expect that only irrational actors would cause coins to be destroyed unnecessarily. Sometimes though people might have weird ideas of whats profitable, think ultra wealthy sadist who gets a kick from destroying poor peoples money. Also sometimes parties who were actually innocent would appear guilty, so i send a package but it gets lost in the mail and you just think that i didnt send the package.

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.

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.

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.

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?

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.

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.

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

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

Already working on it. Will be in the next revision :)

Still worth the risk but unfortunate indeed.

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.

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.

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.

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.

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.

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.

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 (https://bitcointalk.org/index.php?topic=139581.0).

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

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.