Green Address has some kind of ability to have a 2 of 2 multisig account where if funds are not moved after a certain time period, then they automatically go back to the person that originally sent them. Here is how I see using this tech in a trustless exchange. Maybe I am missing something.
Alice has XEM but wants BTC.
Bob has BTC but wants XEM.
How can a third party facilitate this transaction trustlessly so that Bob and Alice with both know that their coins are theirs?
The name of this exchange for this discussion will be NEM Trustless Exchange (NTE).
Alice sends her XEM coins to her NTE account #1. That account is a 2 of 2 multisig. She has one key and NTE has the other. She now puts up a bid for how much BTC she wants if she sells her XEM.
Bob sends his BTC to NTE in his account #1 which is also a 2 of 2. (This account has a feature developed by GreenAdress where if after a certain time the funds are not used, then they are refunded back to Bob automatically and this happens even if GreenAddress goes offline. So Bob can feel safe that even though his money is in an exchange, it can't leave there without his permission)
Bob sees that Alice is offering her XEM for a good price and accepts her bid. When he clicks
Green Address has some kind of ability to have a 2 of 2 multisig account where if funds are not moved after a certain time period, then they automatically go back to the person that originally sent them. Here is how I see using this tech in a trustless exchange. Maybe I am missing something.
Alice has XEM but wants BTC.
Bob has BTC but wants XEM.
How can a third party facilitate this transaction trustlessly so that Bob and Alice with both know that their coins are theirs?
The name of this exchange for this discussion will be NEM Trustless Exchange (NTE).
Alice sends her XEM coins to her NTE account #1. That account is a 2 of 2 multisig. She has one key and NTE has the other. ...
Having a 2 out of 2 with any 3rd party you don't 100 % trust (and you can't trust any service since it could be compromised) is not feasable in NEMs current multisig implementation.
Since you only need n-1 to remove the other co-signatory a compromised (or scam to begin with) service could remove you from your own account and take the account over.
The only way to do this - while still keeping all keys on the same level i.e. no key can do more than the other in a multi-sig account - is an m out of n.
You would make a 2 out of 3 account, give one key to NTE and keep 2 to yourself. That way you can trade like with 2 out of 2 but the 3rd party service can't remove you from your own account. You however could remove NTE if you wish todo so (which might be a problem for the trustless exchange...not sure)
As for the rest...it's too early for me to read all of it :)
...
The only way to do this - while still keeping all keys on the same level i.e. no key can do more than the other in a multi-sig account - is an m out of n.
untrue ;) you can easily fix it by making 4-of-4 account and giving 2 keys to alice, 2 to nte :)
@jabo38 : nice idea, and btw, easiest way to limit time, without any changes it current version of NEM is simply deadline :)
...
The only way to do this - while still keeping all keys on the same level i.e. no key can do more than the other in a multi-sig account - is an m out of n.
untrue ;) you can easily fix it by making 4-of-4 account and giving 2 keys to alice, 2 to nte :)
...
I meant the only way that makes sense :P
I don't think everyone will want to handle 2 accounts per service. The accounts won't want to handle 2 account per user either.
Also with a 4 out of 4 you can't remove NTE anymore without it's consent (which is probably good for the trustless exchange but I wouldn't like it).
...
The only way to do this - while still keeping all keys on the same level i.e. no key can do more than the other in a multi-sig account - is an m out of n.
untrue ;) you can easily fix it by making 4-of-4 account and giving 2 keys to alice, 2 to nte :)
@jabo38 : nice idea, and btw, easiest way to limit time, without any changes it current version of NEM is simply deadline :)
Deadlines! That is like the first feature of an account control system and we already have it. Such a simple point and yet it went right past me. hahaha
...
The only way to do this - while still keeping all keys on the same level i.e. no key can do more than the other in a multi-sig account - is an m out of n.
untrue ;) you can easily fix it by making 4-of-4 account and giving 2 keys to alice, 2 to nte :)
...
I meant the only way that makes sense :P
I don't think everyone will want to handle 2 accounts per service. The accounts won't want to handle 2 account per user either.
Also with a 4 out of 4 you can't remove NTE anymore without it's consent (which is probably good for the trustless exchange but I wouldn't like it).
Good discussions here. On NTE's end handling two of four should be okay because they will have scripts automating it I think. On the users side having to log into two separate accounts would be painful. So I wonder if a person could have one log in, but then NTE generates both of their keys client side and pairs them in a way so that the user only sees a single send button after a single sign in, but the code is really sending two private keys generated client side?
I know Coinbase has a similar solution for their multisig vault. One password for the first key, and the second for the second key (but in this case NTE would just be one password for both. Maybe part of the password for the second key could be derived from part of the hash of the first key). So when I send a transaction from a Coinbase multisig vault, I have a single click button, but secretly behind the scenes with my browser and Coinbase's help, we have created 3 keys. I think that 1.5 of these were created client side, and 1.5 were created on the Coinbase side. To me 1.5 and 1.5 of three is pretty close to 2 and 2 of 4.
In the system designed above there are multiple points of failure where funds can either be temporarily or even permanently frozen, but at no point can they ever be stolen. While there can be a fear that a person might have funds held back, we can assume that if NTE was rational that it wouldn't do so. This is because NTE only stands to lose if it holds funds. It would be punishment not only to the user, but also itself. It loses its fees that it would have made by processing the transaction, and it loses its reputation and therefore future fees. So while some trust still needs to be put into NTE that it will fulfill its function, it is easy trust to give because we can assume that NTE wants to earn fees and that is its main purpose to be.