I have a thread here where I outline why I think this is so cool. Here I've copy pasted it with slight modifications:
At its core it's "just" escrow software. It helps you create a 2 of 3 multisig where the escrow agent has 1 of the keys and the buyer and seller have the other two. But it's particularly cool because it takes that to the next level: it supports frost multisig, which makes it one of the first bitcoin apps to actually use taproot for what it was meant for, and it's also designed so that users can reuse their bitcoin as collateral in multiple contracts without actually moving it. So you can use this as the basis for bitcoin layer twos.
I also love what they do with their integrated signing device. There's this separate little module that holds your keys and does all of the signing, so the website never has your keys, it just asks this module if you want to sign the contracts, and the module asks you.
I would love to see that piece in particular spun off into its own little app. Too few bitcoin apps do this "separation of concerns" thing where your signing device is separate from the apps you interact with. The signing module could change all that and is worth a lot on its own.
Sovereign Origin asked me the following question on twitter "This one [the part about using bitcoin as collateral] is not clear. They can do what now? This sounds very interesting!!"
I'm probably butchering this but I think it works like this. There are four people involved in every contract:
Alice = buyer Bob = seller Carol = agent Bitescrow = coordinator
Alice's funds go into a 2 of 2 multisig with bitescrow and she gets a presigned "backout transaction" so that bitescrow never has custody of her funds. Suppose Alice wants to buy a car from Bob for $60k. Alice and Bob must first agree on who Carol should be (their agent, separate from bitescrow), then Alice gets bitescrow to cosign a transaction that would, if broadcast, move Alice's funds (1 btc) from the 2 of 2 multisig into a 2 of 3 multisig, where Alice, Bob, and Carol have the keys.
Now Alice sends Bob $60k "real" dollars (USD, not bitcoin). In the "happy path" Bob sends her the car and everyone is happy so Alice and Bob just cooperatively tell the escrow "nevermind, don't actually broadcast anything." And Alice's money thus stays in the 2 of 2 multisig with the escrow. If there's a dispute, bitescrow broadcasts the transaction putting the money into the 2 of 3 multisig whereupon what happens next is up to Carol, the agent: if she sides with Alice, that means Carol thinks Alice got jipped, so Alice gets her bitcoin back. If Carol sides with Bob, she thinks Alice never sent the USD, so Bob gets Alice's money.
But in the "happy path" Alice's money never moved! It still remains in her original 2 of 2 multisig with bitescrow, so she can reuse it in another contract. Your bitcoin is used as collateral for contracts where you actually send something else (not bitcoin) and only use bitcoin as a fallback in case there is a dispute. This should scale really well, and it's also neat that bitescrow never custodies any user funds. They do have to be trusted not to collude with Alice though.
I think that's the basic model but @BlueSlime or @Tristan can correct my errors.
We don't have frost implemented yet, but when it's ready we will be using it to federate the escrow server's side of the 2-of-2 address. For the user side of things, all multi-sig inputs are handled by the smart contract (we have a whole smart contract execution layer).
reply
How do the parties pick their Carol? Do Carols get paid?
reply
You can specify any pubkey you wish to be Carol, and Carol can specify any funds she wants to get paid.
Carol could also act as a coordinator between Alice and Bob, and just use BitEscrow as the escrow service. Our protocol is designed for third-parties to help handle contract negotiation and mediate.
reply