Bitcoin Forum
May 25, 2024, 03:41:32 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Multisig Escrow Manager - helping users use advanced transactions  (Read 1791 times)
AgentME (OP)
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
November 25, 2013, 04:24:01 PM
Last edit: November 25, 2013, 04:35:15 PM by AgentME
 #1

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.
VTC
Member
**
Offline Offline

Activity: 84
Merit: 14



View Profile
November 28, 2013, 04:36:10 PM
 #2

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
qwk
Donator
Legendary
*
Offline Offline

Activity: 3542
Merit: 3413


Shitcoin Minimalist


View Profile
November 28, 2013, 10:27:35 PM
 #3

Couldn't you have developed that a few days earlier?
I had set up a bounty for something like this Roll Eyes
https://bitcointalk.org/index.php?topic=294606

Yeah, well, I'm gonna go build my own blockchain. With blackjack and hookers! In fact forget the blockchain.
AgentME (OP)
Member
**
Offline Offline

Activity: 84
Merit: 10


View Profile
November 28, 2013, 11:18:04 PM
Last edit: December 25, 2013, 03:59:40 AM by AgentME
 #4

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.
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.)

Couldn't you have developed that a few days earlier?
I had set up a bounty for something like this Roll Eyes
https://bitcointalk.org/index.php?topic=294606
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.)
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!