Robosats/taptrade-core
1
0
Fork 0
mirror of https://github.com/RoboSats/taptrade-core.git synced 2025-08-05 09:30:06 +00:00
Code Issues Packages Projects Releases Wiki Activity

add escrow output to readme

Browse Source
This commit is contained in:
fbock
2024-08-26 10:43:33 +02:00
parent 57ad701646
commit ef202d97f1
1 changed files with 45 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
README.md
View File

@ -16,7 +16,7 @@ Therefore the implementation of a purely on-chain pipeline would enable larger t
## Architecture
#### Bonds
#### <u>Bonds</u>
Traders are required to submit a bond to the coordinator as first step of their trade. This bond is required to prevent misbehaviour like orderbook spamming or unreliable trade partners, it establishes a real cost to create offers and not finish them as agreed upon.
The bond is sent to the coordinator in form of a signed bitcoin transaction spending to the coordinator with a high transaction fee. The required bond amount can be communicated by the coordinator. The input to the bond transaction should be the same input that will be used in the following escrow locking transaction to reduce the risk of a griefing coordinator.
@ -40,7 +40,7 @@ Trader input(s)-->|-----> Change output
|-----> Tx fee (high)
```
#### Escrow locking transaction
#### <u>Escrow locking transaction</u>
After a taker accepted a public offer (valid bond submitted) both traders have to lock funds in a locking transaction that can only be spent again in collaboration. This locking transaction is a collaborative transaction containing inputs of both maker and taker. Both traders have to sign the locking transaction
which is then combined by the coordinator. The coordinator will allow the use of the same inputs as in the bond transaction. Once this locking transaction has sufficient confirmations the fiat exchange can begin.
@ -50,10 +50,13 @@ Maker input(s)----|---> Coordinator fee output (service fee for coordinator)
|---> Maker change output
Taker input(s)----|---> Taker change output
|---> Transaction fee
Buyer input amount: Bond + 1/2 coordinator service fee + 1/2 tx fee
Seller input amount: Bond + 1/2 coordinator service fee + 1/2 tx fee + amount to sell
```
#### Escrow locking output
The taproot escrow output can be unlocked in different ways depending on the trade outcome. In the
happy case of a successful trade the output can be spent using the keyspend path with an aggregated signature two partial signatures from maker and taker, using the Musig2 scheme. In the case of disputes different script paths can be used to enable unlocking by the coordinator in collaboration with one of the traders.
#### <u>Escrow locking output</u>
The [taproot](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki) escrow output can be unlocked in different ways depending on the trade outcome. In the
case of a successful trade the output can be spent using the [keypath](https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#user-content-Taproot_key_path_spending_signature_validation) with an aggregated signature from two partial signatures of maker and taker, using the MuSig2 scheme. In the case of disputes different script paths can be used to enable unlocking by the coordinator in collaboration with one of the traders.
Other scripts can be added for edge cases, like a timeout script if the coordinator vanishes.
```
taproot output key
@ -62,11 +65,37 @@ Other scripts can be added for edge cases, like a timeout script if the coordina
--------------------------------------------
| |
| |
internal key Escrow spending scripts
Aggregated pubkey of Maker + Coordinator Taker + Coordinator
Maker and Taker
internal key escrow spending scripts root
= =
Aggregated pubkey of --------------------- ---------------------
Maker and Taker | Maker + Coordinator | + | Taker + Coordinator |
--------------------- ---------------------
and more potential useful scripts
```
The following script paths are currently implemented in the demonstrator:
```rust
// Maker wins escrow:
let policy_a_string = format!("and(pk({}),pk({}))", maker_pk, coordinator_pk);
// Taker wins escrow:
let policy_b_string = format!("and(pk({}),pk({}))", taker_pk, coordinator_pk);
// To prevent the possibility of extortion through the coordinator:
let policy_c_string = format!("and(pk({}),after(12228))", maker_pk);
// In case the coordinator vanishes or doesn't cooperate anymore,
// could be used with a cli toolkit as rescue method for traders.
let policy_d_string = format!("and(and(pk({}),pk({})),after(2048))", maker_pk, taker_pk);
// a fully assembled output descriptor would look like this (containing the XOnly pubkeys):
let escrow_output_descriptor = "tr(f00949d6dd1ce99a03f88a1a4f59117d553b0da51728bb7fd5b98fbf541337fb,{{and_v(v:pk(4987f3de20a9b1fa6f76c6758934953a8d615e415f1a656f0f6563694b53107d),pk(62333597c10487d959265bfc992514435daf74e26fd636f6b70e8936b4a82f3e)),and_v(v:pk(f1f1db08126af105974cde6021096525ed390cf9b7cde5fedb17a0b16ed31151),pk(62333597c10487d959265bfc992514435daf74e26fd636f6b70e8936b4a82f3e))},{and_v(v:and_v(v:pk(4987f3de20a9b1fa6f76c6758934953a8d615e415f1a656f0f6563694b53107d),pk(f1f1db08126af105974cde6021096525ed390cf9b7cde5fedb17a0b16ed31151)),after(2048)),and_v(v:pk(4987f3de20a9b1fa6f76c6758934953a8d615e415f1a656f0f6563694b53107d),after(12228))}})#wufuc530"
```
<!-- #### <u>Payout transaction</u> -->
## Trade protocol
WIP