Topic: Multisig Escrow Manager - helping users use advanced transactions (Read 1829 times)

Ooh, possibility to notice. Though I'm actually planning on having the server generate a fresh address and private key for the arbitrator to use, so there wouldn't be a chance of a multsig address repeats. (I have the server generate the arbitrator's key and give it to him so that the server can immediately sign the failsafe transaction with the arbitrator's signature. Then the seller would have no reason not to sign the failsafe transaction, so his signature is guaranteed. This means that the failsafe transaction will work even if the buyer and arbitrator refuse to sign any further transactions. It does mean that a malicious server could act as the arbitrator, but I think that's a small acceptable amount of risk. If enough people found this too debatable, I could add an option to allow the arbitrator to provide his own address, and I'll make sure that the arbitrator's address isn't already in the system in order to address the possibility you bring up.)

Ha, funny thing is I've been implementing this on a coincidentally similar (even to the price) bounty given by someone else.
(Bit of criticism of knowitnothing's solution: in his, the server generates the private key that the payment goes to. It's just a regular single-key address, not a multisig address. The users have to trust the site to not run away with the funds. The server then splits the private key that it knows with a secret-splitting algorithm allowing any two users to create a copy of the private key. There's no way for the users to verify that the split-key values that they get from the server are valid until after the funds have been sent and they attempt to recombine the key to claim its funds.)

Couldn't you have developed that a few days earlier?
I had set up a bounty for something like this
https://bitcointalksearch.org/topic/awarded-bounty-split-key-wallet-escrow-1-btc-294606

I took a quick look.  Users that have a single address (web wallet usually) will get an error message if they try to do a repeated escrow transaction with the same buyer/seller pair because you will generate the same escrow address.  Good thing you have an error for this , otherwise the release code would already be known to one party.  Notify users to use a fresh address when doing escrow with the same buyer/seller.

  Hmm look like it still let me use the repeat of the address pair.
https://crashcoherency.net/multisig/transactions/10e6517d-9668-45eb-9d8c-9d62c7e48c08
https://crashcoherency.net/multisig/transactions/86737628-a591-4ff5-87f8-25ddbc3513ab

I've been fascinated for a while by how Bitcoin is programmable money, and at the many protocol-enforced possibilities such as those on the Bitcoin wiki's Contracts page, but I've been disappointed how even years later most of those special transactions are still very theoretical not used much besides by a few tinkerers here and there. Even if you were in a situation where one of those types of contacts could be useful, you would have to spend most of your time explaining it to the other would-be parties and trying to convince them that you're not just trying to trick them somehow. It's a shame because a lot of those systems done right drastically reduce the possible risks by allowing the Bitcoin protocol to enforce rules. We need better tools and/or tutorials for this stuff.

I've recently been working on the Multisig Escrow Manager, a web application for managing Escrow transactions that will provide a communications platform for Bitcoin Escrow transactions, not too unlike other sites that I'm sure exist, but with the twist that you never have to fully trust any money to the site or the arbitrator. Instead, participants in an Escrow transaction give their addresses, the site generates a 2-of-3 multisig address (with a description showing how it can be verified) that the buyer sends his funds to, the site provides a simple communications platform for them to discuss the progress of the transaction and raise disputes in a way they can each see, and instructs them on how they can resolve the Escrow transaction by signing transactions for the funds in the multisig address. Any partially-signed transactions are displayed on the Escrow transaction page so other participants can easily find them and finish signing them. A failsafe transaction sending the funds from the multisig address to the seller with a lock_time set to a pre-agreed time is also generated, so if no disputes are raised during the time and/or several of the participants stop participating, the transaction can still automatically complete.

We've seen a lot of Bitcoin sites shut down with their users' bitcoins; a different type of site where that's not possible is surely valuable.

The Multisig Escrow Manager is live, though currently very much still under development. Most of the actual bitcoin/multisig stuff is incomplete right now. The system for organizing Escrow transactions and inviting other people to participate them is working. Feel free to test it out! (You can even act as multiple roles within the same Escrow transaction to test it out.) All of the source code is released on github under a permissive MIT license for anyone to use. It's not even too hard to install and run locally on your own machine (though some of the dependencies might not currently play nicely under Windows; I'll look into that sometime). Feedback is appreciated.