search

RoboSats / robosats

A simple and private bitcoin exchange
https://learn.robosats.com
GNU Affero General Public License v3.0
707 stars 141 forks source link

Onchain P2P pipeline as Taproot/MAST contract #230

Open Reckless-Satoshi opened 2 years ago

Reckless-Satoshi commented 2 years ago

Implement a new trade mode for full onchain escrow. Compared to the current LN mode, it will allow for larger trades, fully trust-less pipeline and higher safety assurance (zero custodial risk). It will also allow users to sell Sats directly onchain (requested feature).

The onchain TR/MAST pipeline is potentially useful and wanted for other platforms such as Peach (@Czino) or Hodlhodl. In addition, there are benefits to find a joint solution for the contract and build shared libraries (back and frontend), e.g., higher security and scrutiny, lower dev cost, higher anonymity set for unlocking scripts etc. If a joint solution is desired, the libraries will be MIT licensed to be compatible with closed source models, otherwise we will stick to AGPL as usual for RoboSats.

Note: I only know the very basics of Tapscript and MAST. So while I believe this feature is possible, some more experienced dev should take a look. Help is specially very appreciated for this feature.

Multisig Taproot/MAST contract

A brief description of what is wanted by a non-technical

One can think of it as a 2-3 multisig. The buyer holds a key, the seller holds a key and the coordinator (dispute solver) the last one. This is, in fact, similar to the current model of Hodlhodl.

The most common case is for the escrow Sats to be released to the buyer, so that TX should look like a regular P2TR. All other conditions are to be fully defined and implemented as MAST leaves. Be aware the next table can be buggy, incomplete, inaccurate or plain impossible. I did not study enough.

Case TR/MAST Signers Sats move to Onchain trace
1. Cooperative Success Default spending path Buyer and seller escrow to buyer, fee to coordinator P2TR: 1 input 2 outputs
2. Cooperative Cancellation Script_A Buyer and seller escrow back to seller Reveals TapLeaf
3. Seller wins dispute Script_B Seller and coordinator escrow back to seller Reveals TapLeaf
4. Buyer wins dispute Script_C Buyer and coordinator escrow to buyer, fee to coordinator Reveals TapLeaf

E.g. As output descriptor:

P1 = Seller Pubkey P2 = Buyer Pubkey P3 = Coordinator Pubkey

tr(pk(musig(P1,P2)),{pk(musig(P1,P2)),{pk(musig(P1,P3)),pk(musig(P2,P3))}})

Note musig is not a valid output descriptor. It denotes key information used to populate fields in the PSBTs participatns use to coordinate signing.

Other comments

The seller will deposit the Sats into the contract either (1) when the order is created or (2) when the order is taken. The approach (1) will allow for much shorter trade time for order takers while (... but... difficult... how to write the contract if the buyer payout address is still unknown? (2) makes for less overhead for makers whose order is not taken and the Sats have to be returned (incurring loss of mining fees).

As for Schnorr signature aggregation MuSig2 protocol seems to have good properties. Are there production ready JS/Python libraries implementing this protocol? LND on v0.15.0 has added experimental support for MuSig2 signing on signrpc https://github.com/guggero/lnd/blob/93e069f3bd4cdb2198a0ff158b6f8f43a649e476/docs/musig2.md . There also seems to be some work to add multisig (MuSig2) functionality to bitcoin-core https://github.com/bitcoin/bitcoin/issues/24861 . We would still need this to happen on a light client JS app.

Tasks

General

A client library should never sign an "I lose the dispute" TX

RoboSats Specific

Let's start with settling for a polivalent contract Taproot/MAST with leaves that account for every case. Brainstorming will be needed. If you know anyone interested and can help developing it please tag in comments. I'm tagging devs with good understanding of TR whose input would be very valuable: @sr-gi @esneider.

We are allocating ⚡600K Sats in rewards⚡ from the dev fund for the creation of the generic TX templates.

Czino commented 2 years ago

Some thoughts regarding (1)

Naturally the escrow would need to be a 2-2 between seller and coordinator. The buyer is a bit at the mercy as the buyer doesn't hold any of the keys. This can be mitigated by handing out a presigned (by coordinator) release transaction to buyer and seller.

We are also looking into a timelocked escrow solution where the script is a regular multisig. To guarantee the seller can be refunded, we'd presign a timelocked refund transaction. However, to ensure we can still payout the escrow to the buyer in case of a dispute, we will force the seller to presign a timelocked release transaction for one day earlier. We still didn't go through all the use cases and edge cases but I think it could work.

Reckless-Satoshi commented 2 years ago

We are also looking into a timelocked escrow solution where the script is a regular multisig. To guarantee the seller can be refunded, we'd presign a timelocked refund transaction. However, to ensure we can still payout the escrow to the buyer in case of a dispute, we will force the seller to presign a timelocked release transaction for one day earlier.

I see, this is clever. I understand Peach wants to optimize for best UX of the order taker, so (1) is preferred as there is no block confirmations to wait for. Unfortunately it involves a bit of trust (... hence it may carry some ~mafia~ regulatory risks). Question: Isn't the seller in this 2-2 with timelock also a bit subject to the mercy of the coordinator?

I guess you guys might still be very busy with the initial release / growth / bug hunting on the current model. I will keep maturing this line, it might be a lifesaver to have a plan B (trustless TR 2-3 multisig) at hand, ready to flip the switch, for a plausible regulator whim :see_no_evil:

f321x commented 1 month ago

This issue is currently being worked on in this repository: taptrade-core