Onchain P2P pipeline as Taproot/MAST contract

[Reckless-Satoshi]

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 bitcoin/bitcoin#24861 . We would still need this to happen on a light client JS app.

Tasks

General

• Settle for Taproot/MAST leaves that account for every case
• Create Taspcript/MAST transaction templates ⚡600K Sats reward⚡
• Write libraries for coordinator/backend: contract creation / signature agregation / tx broadcasting, etc. Python, and javascript if needed for Peach.
• Write libraries for buyer-seller/frontend client: privkey/pubkey gen, signing and signature aggregation....

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

RoboSats Specific

• Create onchain trade order Model.
• Implement onchain Logics using libraries above.
• New API endpoints (or enhance existing one for /order/).
• Create new UI components and prompts for onchain trade pipeline.

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]

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]

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 🙈

[f321x]

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