Topic: Armory newcomer, seeking advice for an escrow transaction (Read 1597 times)

Got it, thanks. There's a lot to all of this, but it's starting to come together and make sense.




I just realized that. He's got everything, I've got nothing. This ounce of prevention has gained about forty pounds since I started it all. Angst: it's just not worth it!

I'm changing my terms. If he wants the code, he can pay for it up front before I ship. Via bank wire or Bitcoin (latter preferred). If he wants a contract he can pay to produce one and I'll review it.

http://vimeo.com/22053820

Simple, easy, done.

You've been VERY helpful.

Thanks,
Jeff Bowman
Fairbanks, Alaska

3) Ok I got your original question wrong. There are 2 stages in backing up a lockbox: You have to backup the lockbox itself (a short string saved in multisigs.txt in Armory's datadir), and each participant has to backup the set of private keys he used to create the lockbox.

The lockbox string is public data. If it is revealed to the public, you lose privacy but not coins. So you can back that up in quite a lot of ways, and each one of the involved parties should have that string as well, so this part is the least likely to be destroyed over time.

As for the private keys, if you can expect the buyer to protect his private keys properly, you should also expect he can lock funds in a lockbox without throwing his private keys out the door. Sure, he may be stupid, cycle his wallets at some point, get rid of all backups to the old ones without realizing he just lost his signatory power for his lockboxes. But then the 3rd party is expected use a dedicated wallet to provide private keys for lockbox creation (instead of picking a key from his own funded wallets), so he has less of a reason to just lose these keys.

Your proposal is fine. Short term escrow is another way to look at it. It reduces the amount of time the 3rd party is exposed to the funds so assuming he started honest but may be corrupted over time, it limits his window of action. The drawback is that you give the buyer a lot of protection. He can simply refuse to pay you after a few months of work for various reasons: he doesn't need your work anymore, he commissioned several individuals with the intent to only pay one, he can pressure you to do more for the same pay after you committed T amount of your time getting that far, etc...

The idea of using a multi-party technological solution for this type of contracts is to alleviate trust in the interested parties (buyer/seller), and put it in a commonly agreed upon 3rd party, whom at the same time doesn't retain enough power to just run with the funds. The solution you propose puts a lot of trust on the buyer. If you think the customer is king and you want them to feel treated that way, then your approach is well suited. If you want to retain some protection from potentially uncivilized customers, you should consider to at least lock litigation fees upfront.

My, but that's an extensive reply (and quite helpful). It's clear that you spent a lot of time on it. I'm grateful, thank you.

1) OK, that's the answer I was looking for. We won't do it that way. We'll find a neutral arbitrator as third-party.
2) OK, I'll get my spreadsheet out for that one  
3) I didn't phrase my question clearly enough...  when I say backup, I mean Armory backup. I've been reading about Wallet backup, but is that the same as LockBox backup?

In any case, I've decided not to let funds sit in a LockBox not under my control for a full year. Any number of untoward events could take place during that time, resulting in both parties losing access to those funds forever.

Here's something I've come up with, likely using some variation of your answer #2:

• We find and agree on an impartial arbitrator for an MxN LockBox
• Via a screen share session I demo the code to the buyer's satisfaction
• With him watching, I:
  - Archive the code into a single zip file
  - Run a SHA1 hash against the file
  - Send him the signature
  
• He posts full payment to the LockBox (I can't receive it, nor can he retrieve it)
• I send him the zip file
• The matching signature is his guarantee that I've performed
• He signs the LockBox, releasing the funds to me

What is your critique? Can you see a way that this doesn't protect everyone's interests?

Thanks,
Jeff Bowman
Fairbanks, Alaska

1) Why would the buyer have protection? This is the same as giving the seller full control of the funds. The scheme you are thinking of is a 2-of-3 with one key to the seller, one to the buyer and one to an arbitrating 3rd party. The buyer and the seller have to cooperate for the funds to go anywhere. If they fail to find an understanding, then the 3rd party can come in and act as a judge, and has enough power to sign the coins off to the party he declares rightful in its demands.

2) Depends on the scheme again. M-of-N lockbox with M keys to any party is the same as giving full control of the funds to that party. If you want the 2 parties to have same power over the coins without the ability to wrong the other, each party has to have an amount K of keys, where K < M and 2*K >= M, and the 3rd party needs to have an amount of S of keys, where S < M and S+K >= M

3) The nature of the transaction doesn't change. Part of the due sum is paid in advance, the rest at delivery, kept in the 2-of-3 escrow. This concept doesn't mix well with 2-of-3 escrow however. The idea of paying a part of the price in advance is to mitigate the risk to the seller while keeping the risk to the buyer lower than if he just paid upfront.

2-of-3 escrow bypasses that entirely. With a 3rd party judge, buyer and seller have to agree for the funds to go anywhere. In case they disagree, the judge comes in. So the buyer puts full payment in escrow upfront, in the 2-of-3, at which point the seller starts on his work. The buyer then signs his half of the lockbox when the product is delivered, to the expected specs.

If the seller needs some money upfront to start on development, then that's part of another agreement, usually some sort of non refundable pre-order clause.

If you want to give even more protection to the buyer, you can use a simulfund to get the seller to put some funds in escrow at the same time the buyer puts in the full price of his purchase + extra, to cover litigation fees and pay for the 3rd party's time.

If the whole thing goes smooth, the 3rd party won't be involved beyond providing his public key once, so he could be entitled to small fee for his small burden. If there is a dispute between buyer and seller, the 3rd party has to kick in and review both sides' evidence. As he comes to a conclusion, he will then release the fees to the party he deems righteous, and pocket in the fees for his work from the guilty party.

This keeps the 3rd party motivated to review the case if needs be, and gets the seller involved more in the transaction: if he walks away, neglects this job, or takes something juicer on the way and doesn't try to release the buyer's funds asap now that he failed on his obligations, then it will cost him the litigation funds.

The flaw in this basic model is if the 3rd party colludes with one of the other parties to steal the funds, so you have to find a trustworthy individual to act as escrow. However this method is a lot better than just letting the buyer deal with the seller, and better than 1-of-1 escrow where the 3rd party holds all the funds and may run with them at any point in time, and usually commands a hefty fee whether the transaction is successful or not, in the case he is trustworthy, since you have to trust him a lot more, and he has a lot more work to do, regardless of the outcome.

If you walk out of that model, you'll most likely end up giving one of the parties too much power over the other one. I'm not saying it can't be done, but you're gonna have to get creative, and I don't thing multisig is the sole technological answer to that one.

Upon rereading my question, I can see that the majority of it is off-topic for this forum. Pardon me please; I appreciate your patience in this regard. Thank you also for the reference.

Do you have any insight toward the remaining three questions:

• If the seller acts as the organizer, creating a 2x3 LockBox with a two-wallet combination under his own control, does the buyer retain his protections?
• Once the buyer commits funds to the LockBox, can they be extracted without separate permission from each party?
• If the transaction is split, with final remittance occurring after a year, what backup measures should each party take in the meantime?

Thanks,
Jeff Bowman
Fairbanks, Alaska

I think you are looking for an arbitration service. I have not used them, but for example https://www.bitrated.com/ has plenty arbitrators listed, might be there's one with IP experience. I'm sure there are other sites / arbitrators.

I'm a software developer, wishing to sell some of my source code to an interested party.

The inherent problem with selling this sort of intellectual property is that neither party is able to receive sufficient guarantee before committing.

From the seller's point of view, merchandise sent first:

• Upon receipt of the code for evaluation, the buyer could 'change his mind' yet still retain a copy to use at his pleasure
• Copyright violation would be undetectable
• In this case at least, legal action would cost more than the value of the transaction

From the buyer's point of view, payment sent first:

• The code could contain deficiencies, ranging in any number and level of severity
• The seller could refuse refund or simply not send the goods in the first place
• In this case at least, legal action would cost more than the value of the transaction

I'll be appreciative of any suggestions toward resolving this dilemma.

Continuing: I'm considering using Armory's LockBox feature to facilitate the transaction. I have some preliminary questions:

• If the seller acts as the organizer, creating a 2x3 LockBox with a two-wallet combination under his own control, does the buyer retain his protections?
• Once the buyer commits funds to the LockBox, can they be extracted without separate permission from each party?
• If the transaction is split, with final remittance occurring after a year, what backup measures should each party take in the meantime?

Advice and assistance is much appreciated.

Thanks,
Jeff Bowman
Fairbanks, Alaska