From a5d61697606e85160805e0fcd67fb31dbcb300d6 Mon Sep 17 00:00:00 2001 From: h4sh3d Date: Wed, 26 May 2021 17:48:46 +0200 Subject: [PATCH] Rename Alice and Bob, fix #54 --- 00-introduction.md | 6 +- 01-high-level-overview.md | 16 ++--- 02-user-stories.md | 52 +++++++------- 04-protocol-messages.md | 26 +++---- 06-datum-and-instructions.md | 90 ++++++++++++------------ 07-cryptographic-setup.md | 12 ++-- 08-transactions.md | 132 +++++++++++++++++------------------ 09-swap-state.md | 22 +++--- 10-public-offer.md | 8 +-- 9 files changed, 181 insertions(+), 183 deletions(-) diff --git a/00-introduction.md b/00-introduction.md index 237b856..9adb66d 100644 --- a/00-introduction.md +++ b/00-introduction.md @@ -38,9 +38,9 @@ Such protocols can be designed with cryptography and sometimes game theory. Pure **Let's explain how the game theory works in Farcaster:** -The main goal of a swap is to have a successful trade. But imagine if one participant disappears or acts maliciously after all have locked their money. In such a case, the swap must be cancelled and participants must be refunded. The refund process in this protocol is heavily linked to one participant called Bob. He only has one choice: refund his money. By doing it he also refunds others' money. If Bob doesn't react the refund cannot happen for others. Now Bob can be honest or malicious: in the case he's honest he will behave according to the protocol and everyone will be refunded, but if he's malicious he can choose to do nothing, letting everybody hanging. +The main goal of a swap is to have a successful trade. But imagine if one participant disappears or acts maliciously after all have locked their money. In such a case, the swap must be cancelled and participants must be refunded. The refund process in this protocol is heavily linked to one participant called the arbitrating seller. He only has one choice: refund his money. By doing it he also refunds others' money. If the arbitrating seller doesn't react the refund cannot happen for others. Now the arbitrating seller can be honest or malicious: in the case he's honest he will behave according to the protocol and everyone will be refunded, but if he's malicious he can choose to do nothing, letting everybody hanging. -To incentivize Bob to do the action of refunding his money, a game takes place: if he doesn't react, after a determined time frame, the other participant can take his money for free, meaning he gets punished. +To incentivize the arbitrating seller to do the action of refunding his money, a game takes place: if he doesn't react, after a determined time frame, the other participant can take his money for free, meaning he gets punished. ## Glossary and Terminology Guide @@ -96,7 +96,7 @@ To incentivize Bob to do the action of refunding his money, a game takes place: * The phase a *daemon* plays after the negotiation phase to perform the swap. During this phase, the *daemon* is connected and interacts with *clients*, *syncers*, and a *counter-party daemon*. * #### *Swap role*: - * The role a *daemon* fulfills during the swap phase. Two roles are available: Alice and Bob. + * The role a *daemon* fulfills during the swap phase. Two roles are available: the accordant seller and the arbitrating seller. * #### *Syncer*: * Syncer or Chain Syncer; A piece of software bridging a *daemon* and a blockchain. Produces *blockchain events* and listens for *tasks*. diff --git a/01-high-level-overview.md b/01-high-level-overview.md index 3510b86..23b11a0 100644 --- a/01-high-level-overview.md +++ b/01-high-level-overview.md @@ -17,7 +17,7 @@ This RFC describes the high-level concepts associated with the protocol such as * [Roles](#roles) * [Blockchain: Arbitrating & Accordant](#blockchain-arbitrating--accordant) * [Negotiation: Taker & Maker](#negotiation-taker--maker) - * [Swap: Alice & Bob](#swap-alice--bob) + * [Swap: accordant seller & arbitrating seller](#swap-accordant-seller--arbitrating-seller) * [Reputation asymmetry](#reputation-asymmetry) ## Phases @@ -52,24 +52,24 @@ Those roles are determined by the outgoing blockchains' capabilities involved in To allow the interconnection among participants and set the parameters of a trade, we describe two negotiation roles: (1) Taker and (2) Maker. The former will browse the public offers and the latter will produce them. -Taker and maker roles are dissociated from swap roles. They are used in the negotiation phase. A taker can later be transformed into an Alice or a Bob role when moving from the negotiation phase into the swap phase, and vice versa. +Taker and maker roles are dissociated from swap roles. They are used in the negotiation phase. A taker can later be transformed into an the accordant seller or a the arbitrating seller role when moving from the negotiation phase into the swap phase, and vice versa. The maker role offers a trade, via the public offer. Its proposal sets the amounts, the asset pair, and what role each participant takes in the swap. There is no special limitation on what a proposal can be in theory. The maker then sends the offer to potential takers. A taker inspects an offer and decides whether or not to engage in the offered trade. -### Swap: Alice & Bob +### Swap: accordant seller & arbitrating seller -Emergent from the protocol's asymmetry, we identify two swap roles: (1) Alice and (2) Bob. Each plays a different and thus complementary game, together composing the entire atomic swap protocol. +Emergent from the protocol's asymmetry, we identify two swap roles: (1) the accordant seller and (2) the arbitrating seller. Each plays a different and thus complementary game, together composing the entire atomic swap protocol. -Alice always moves coins from the accordant chain to the arbitrating chain. In other words, Alice sells accordant assets in return for arbitrating assets. +The accordant seller always moves coins from the accordant chain to the arbitrating chain. In other words, the accordant seller sells accordant assets in return for arbitrating assets. -Bob always moves coins from the arbitrating chain to the accordant chain. In other words, Bob sells arbitrating assets in return for accordant assets. +The arbitrating seller always moves coins from the arbitrating chain to the accordant chain. In other words, the arbitrating seller sells arbitrating assets in return for accordant assets. ## Reputation asymmetry -Due to the protocol's asymmetry, Alice always locks her coins later in the swap process, implying that she gets an option to buy without cost. One way to resolve this issue is to introduce a reputation system between participants, but this is hard in a decentralized setup. +Due to the protocol's asymmetry, the accordant seller always locks her coins later in the swap process, implying that she gets an option to buy without cost. One way to resolve this issue is to introduce a reputation system between participants, but this is hard in a decentralized setup. -The reputation asymmetry is not linked to the negotiation role assumed by Alice's daemon: If she's a Taker she can cancel for free on any prices and if she's a Maker she can propose any prices and cancel for free if someone tries to take it. +The reputation asymmetry is not linked to the negotiation role assumed by the accordant seller's daemon: If she's a Taker she can cancel for free on any prices and if she's a Maker she can propose any prices and cancel for free if someone tries to take it. More broadly, the "one has to lock funds first" problem is not due to this protocol nor its asymmetry, but concerns all layer-1 protocols based on multilateral lock/refund primitives. diff --git a/02-user-stories.md b/02-user-stories.md index a5796aa..7a8cb4d 100644 --- a/02-user-stories.md +++ b/02-user-stories.md @@ -32,18 +32,18 @@ The maker starts her node in maker mode and registers all the parameters an offe ### Create an offer -To create an offer, a maker registers the following list of required inputs: +To create an offer, a maker registers the following list of required inputs (non-exhaustive list, see [10. Public Offer](./10-public-offer.md)): * The Arbitrating/Accordant blockchain identifier, e.g. BTC-XMR; *Must identify: blockchain chain and asset traded. E.g. bitcoin on mainnet or bitcoin on testnet. This can be done through a `chain_hash` parameter or be defined by an RFC in Farcaster.* * The arbitrating blockchain asset amount; *In the unit type defined by the blockchain.* * The accordant blockchain asset amount; *In the unit type defined by the blockchain.* - * The timelock durations used during the swap, they define the two-time frames for canceling the swap on-chain and punishing Bob if he doesn't react after a swap cancellation; *In the unit type defined by the blockchain.* + * The timelock durations used during the swap, they define the two-time frames for canceling the swap on-chain and punishing the arbitrating seller if he doesn't react after a swap cancellation; *In the unit type defined by the blockchain.* * The fee calculation strategy defines the transactions fee strategy to use on e.g. BTC transactions; *This might be fixed, within a range, or defined as a function or a more evolved type.* - * The future maker swap role (Alice or Bob); *Taker role is derived from this as the protocol always have one Alice and one Bob.* + * The future maker swap role (accordant seller or arbitrating seller); *Taker role is derived from this as the protocol always have one accordant seller and one arbitrating seller.* The client user interface should provide an easy way to define an offer through e.g. a Buy or Sell point of view, and may auto-fill the fee strategy based on user preferred fee estimators. -For the participant who plays Bob's role during the swap, the fee strategy and the timelock durations are critical values to guarantee safety and potential funds recovery. A too short timelock duration or too low fee strategy might allow Alice to punish Bob even if he behaves accordingly to the protocol. The swap client should carefully check these parameters as a regular wallet would do for the fees. +For the participant who plays the arbitrating seller's role during the swap, the fee strategy and the timelock durations are critical values to guarantee safety and potential funds recovery. A too short timelock duration or too low fee strategy might allow the accordant seller to punish the arbitrating seller even if he behaves accordingly to the protocol. The swap client should carefully check these parameters as a regular wallet would do for the fees. ### Create a public offer @@ -69,8 +69,8 @@ We define in this RFC the interface between the negotiation and swap phase. At t * They validated a set of parameters containing: * Blockchains & assets used as an Arbitrating-Accordant asset pair, e.g. BTC-XMR * Amount exchanged of each asset, e.g. 200 XMR and 1.3 BTC - * Transition from Maker-Taker roles into Alice-Bob roles - * Timelock durations for canceling the swap and punishing Bob's non-reaction + * Transition from Maker-Taker roles into accordant seller-arbitrating seller roles + * Timelock durations for canceling the swap and punishing the arbitrating seller's non-reaction * Fee strategy applied to arbitrating transactions ### GUI Example @@ -102,9 +102,9 @@ $ swap-cli --make > Punish Timelock: 10 > Fee strategy ([F]ixed, [R]ange, [D]ynamic): R > Fee range (sat/vB): 10-40 -> Role ([A]lice,[B]ob): A +> Role ([A]ccordant,A[r]bitrating) seller: A -You chose Alice: +You chose the accordant seller: > Bitcoin destination address: bc1qndk902ka3266wzta9cnl4fgfcmhy7xqrdh26ka Exchange 0.3 BTC for 10 XMR? [y/N] y @@ -127,12 +127,12 @@ Public offer : Cancel Timelock: 4 : Punish Timelock: 10 : Fee range (sat/vB): 10-40 -: Your role: Bob -: Counterparty role: Alice +: Your role: the arbitrating seller +: Counterparty role: the accordant seller Exchange 10 XMR for 0.3 BTC? [y/N] y -You are Bob: +You are the arbitrating seller: > Bitcoin refund address: bc1qkj370d9hc3seqauu9sujm96aqfw5ml9a46ejfa Connecting to counterparty daemon... @@ -142,11 +142,11 @@ Connecting to counterparty daemon... The swap phase for each role starts with the common set of parameters defined above as the interface: the public offer. -In addition, for Alice's role: +In addition, for the accordant seller's role: * The destination Arbitrating address -And, in addition, for Bob's role: +And, in addition, for the arbitrating seller's role: * The refund Arbitrating address @@ -163,7 +163,7 @@ We describe the high-level view of the swap phase with four steps: 3. Accordant locking step 4. Swap step -We describe a basic user experience with an atomic swap GUI client for Alice and Bob. This is provided for educational purposes and to give an idea to the reader; the swap GUI client may look different depending on the platform (mobile, desktop, cli, etc) and potential wallet integration. +We describe a basic user experience with an atomic swap GUI client for the accordant seller and the arbitrating seller. This is provided for educational purposes and to give an idea to the reader; the swap GUI client may look different depending on the platform (mobile, desktop, cli, etc) and potential wallet integration. The design proposed here does not make any assumptions about wallet integration. All the funds can be sourced from external wallets with no restriction on the form factor. While this has the cost of an additional transaction on the Arbitrating blockchain, this can be removed if the client is closely integrated in a given wallet. @@ -171,7 +171,7 @@ The design proposed here does not make any assumptions about wallet integration. *Fig 2. Example of a GUI executing a swap* #### 1. Initialization Step (1 in the diagram) -Alice and Bob start the pre-initialization. They exchange and verify parameters specified in [04. Protocol Messages](./04-protocol-messages.md) RFC. If the validation successfully terminates, the client moves to the next step. +The accordant seller and the arbitrating seller start the pre-initialization. They exchange and verify parameters specified in [04. Protocol Messages](./04-protocol-messages.md) RFC. If the validation successfully terminates, the client moves to the next step. ##### Messages exchanged: @@ -179,33 +179,33 @@ Alice and Bob start the pre-initialization. They exchange and verify parameters > Messages can arrive in any order -- Alice → Bob: [`commit_alice_session_params`](./04-protocol-messages.md#the-commit_alice_session_params-message) -- Bob → Alice: [`commit_bob_session_params`](./04-protocol-messages.md#the-commit_bob_session_params-message) +- Accordant seller → Arbitrating seller: [`commit_alice_session_params`](./04-protocol-messages.md#the-commit_alice_session_params-message) +- Arbitrating seller → Accordant seller: [`commit_bob_session_params`](./04-protocol-messages.md#the-commit_bob_session_params-message) *Second round, reveal values* > Messages can arrive in any order -- Alice → Bob: [`reveal_alice_session_params`](./04-protocol-messages.md#the-reveal_alice_session_params-message) -- Bob → Alice: [`reveal_bob_session_params`](./04-protocol-messages.md#the-reveal_bob_session_params-message) +- Accordant seller → Arbitrating seller: [`reveal_alice_session_params`](./04-protocol-messages.md#the-reveal_alice_session_params-message) +- Arbitrating seller → Accordant seller: [`reveal_bob_session_params`](./04-protocol-messages.md#the-reveal_bob_session_params-message) #### 2. Arbitrating Locking Step (2-3 in the diagram) -After the parameters are exchanged and validated, Bob asks the user for funding. Upon receiving funds, Bob creates the transactions, signs the cancel path, and sends them to Alice with the `core_arbitrating_setup` protocol message. He acquires Alice's signatures for the cancel path. The bitcoin are locked when Bob is able to trigger the cancel path and refund the assets, i.e. after receiving the `refund_procedure_signatures` protocol message. +After the parameters are exchanged and validated, the arbitrating seller asks the user for funding. Upon receiving funds, the arbitrating seller creates the transactions, signs the cancel path, and sends them to the accordant seller with the `core_arbitrating_setup` protocol message. He acquires the accordant seller's signatures for the cancel path. The bitcoin are locked when the arbitrating seller is able to trigger the cancel path and refund the assets, i.e. after receiving the `refund_procedure_signatures` protocol message. ##### Messages exchanged: -- Bob → Alice: [`core_arbitrating_setup`](./04-protocol-messages.md#the-core_arbitrating_setup-message) -- Alice → Bob: [`refund_procedure_signatures`](./04-protocol-messages.md#the-refund_procedure_signatures-message) +- Arbitrating seller → Accordant seller: [`core_arbitrating_setup`](./04-protocol-messages.md#the-core_arbitrating_setup-message) +- Accordant seller → Arbitrating seller: [`refund_procedure_signatures`](./04-protocol-messages.md#the-refund_procedure_signatures-message) #### 3. Accordant Locking Step (4 in the diagram) -Once Alice has received sufficient confirmations for Bob's `lock (b)` transaction to feel safe, Alice proceeds to lock her monero with the Monero `lock (x)` transaction. +Once the accordant seller has received sufficient confirmations for the arbitrating seller's `lock (b)` transaction to feel safe, the accordant seller proceeds to lock her monero with the Monero `lock (x)` transaction. #### 4. Swap Step (5-6 in the diagram) -Once Bob has received sufficient confirmations for the Monero `lock (x)` transaction to feel safe, Bob sends Alice the `buy (c)` encrypted signature, which Alice requires to execute the first branch of the `lock (b)` transaction output script via the `buy (c)` transaction. +Once the arbitrating seller has received sufficient confirmations for the Monero `lock (x)` transaction to feel safe, the arbitrating seller sends the accordant seller the `buy (c)` encrypted signature, which the accordant seller requires to execute the first branch of the `lock (b)` transaction output script via the `buy (c)` transaction. -Alice then signs the `buy (c)` transaction to complete it and publishes it, leaking her Monero key share and finalizing her swap at the same time. Bob sees the `buy (c)` transaction in the mempool, extracts the Monero key share, and displays it to the user. +The accordant seller then signs the `buy (c)` transaction to complete it and publishes it, leaking her Monero key share and finalizing her swap at the same time. the arbitrating seller sees the `buy (c)` transaction in the mempool, extracts the Monero key share, and displays it to the user. ##### Message exchanged: -- Bob → Alice: [`buy_procedure_signature`](./04-protocol-messages.md#the-buy_procedure_signature-message) +- Arbitrating seller → Accordant seller: [`buy_procedure_signature`](./04-protocol-messages.md#the-buy_procedure_signature-message) diff --git a/04-protocol-messages.md b/04-protocol-messages.md index 77275ef..c69dd92 100644 --- a/04-protocol-messages.md +++ b/04-protocol-messages.md @@ -45,9 +45,9 @@ Cryptographic and transaction types are assumed to be generic, so e.g. different ### The `commit_alice_session_params` Message -**Sent by**: Alice +**Sent by**: the accordant seller -`commit_alice_session_params` forces Alice to commit to the result of her cryptographic setup before receiving Bob's setup. This is done to remove adaptive behavior. +`commit_alice_session_params` forces the accordant seller to commit to the result of her cryptographic setup before receiving the arbitrating seller's setup. This is done to remove adaptive behavior. If not needed for the accordant blockchain the view key commitment must be set to a null hash. @@ -64,9 +64,9 @@ If not needed for the accordant blockchain the view key commitment must be set t ### The `commit_bob_session_params` Message -**Sent by**: Bob +**Sent by**: the arbitrating seller -`commit_bob_session_params` forces Bob to commit to the result of his cryptographic setup before receiving Alice's setup. This is done to remove adaptive behavior. +`commit_bob_session_params` forces the arbitrating seller to commit to the result of his cryptographic setup before receiving the accordant seller's setup. This is done to remove adaptive behavior. If not needed for the accordant blockchain the view key commitment must be set to a null hash. @@ -82,7 +82,7 @@ If not needed for the accordant blockchain the view key commitment must be set t ### The `reveal_alice_session_params` Message -**Sent by**: Alice +**Sent by**: the accordant seller `reveal_alice_session_params` reveals the parameters commited by the `commit_alice_session_params` message. @@ -114,7 +114,7 @@ If not needed for the pair of Arbitrating-Accordant blockchain the proof value m ### The `reveal_bob_session_params` Message -**Sent by**: Bob +**Sent by**: the arbitrating seller `reveal_bob_session_params` reveals the parameters commited by the `commit_bob_session_params` message. @@ -144,9 +144,9 @@ If not needed for the pair of Arbitrating-Accordant blockchain the proof value m ### The `core_arbitrating_setup` Message -**Sent by**: Bob +**Sent by**: the arbitrating seller -`core_arbitrating_setup` sends the `lock (b)`, `cancel (d)` and `refund (e)` arbitrating transactions from Bob to Alice, as well as Bob's signature for the `cancel (d)` transaction. +`core_arbitrating_setup` sends the `lock (b)`, `cancel (d)` and `refund (e)` arbitrating transactions from the arbitrating seller to the accordant seller, as well as the arbitrating seller's signature for the `cancel (d)` transaction. 1. type: 33710 (`core_arbitrating_setup`) 2. data: @@ -162,9 +162,9 @@ If not needed for the pair of Arbitrating-Accordant blockchain the proof value m ### The `refund_procedure_signatures` Message -**Sent by**: Alice +**Sent by**: the accordant seller -`refund_procedure_signatures` transmits Alice's signature for the `cancel (d)` transaction and Alice's adaptor signature for the `refund (e)` transaction. Upon receipt, Bob must validate the signatures. +`refund_procedure_signatures` transmits the accordant seller's signature for the `cancel (d)` transaction and the accordant seller's adaptor signature for the `refund (e)` transaction. Upon receipt, the arbitrating seller must validate the signatures. 1. type: 33720 (`refund_procedure_signatures`) 2. data: @@ -177,9 +177,9 @@ If not needed for the pair of Arbitrating-Accordant blockchain the proof value m ### The `buy_procedure_signature` Message -**Sent by**: Bob +**Sent by**: the arbitrating seller -`buy_procedure_signature`is intended to transmit Bob's adaptor signature for the `buy (c)` transaction and the transaction itself. Upon receipt, Alice must validate the transaction and the adaptor signature. +`buy_procedure_signature`is intended to transmit the arbitrating seller's adaptor signature for the `buy (c)` transaction and the transaction itself. Upon receipt, the accordant seller must validate the transaction and the adaptor signature. 1. type: 33730 (`buy_procedure_signature`) 2. data: @@ -191,7 +191,7 @@ If not needed for the pair of Arbitrating-Accordant blockchain the proof value m ### The `abort` Message -**Sent by**: Alice|Bob +**Sent by**: the accordant seller|the arbitrating seller `abort` is an `OPTIONAL` courtesy message from either swap partner to inform the counterparty that they have aborted the swap with an `OPTIONAL` message body to provide the reason. diff --git a/06-datum-and-instructions.md b/06-datum-and-instructions.md index e110a76..af39091 100644 --- a/06-datum-and-instructions.md +++ b/06-datum-and-instructions.md @@ -45,7 +45,7 @@ As sketched below, the `client`→`daemon` and `daemon`→`client` routes consis From a security perspective, an important distinction between the client and the daemon is that the daemon only knows public keys - private keys are the privy treasure of the client`(*)`. Nonetheless, the daemon MUST be viewed as a trusted component, since it exclusively verifies the correctness of the counterparty's data, controls the swap state, and can misreport the progress of the swap to the client or mislead the client into invalid protocol states. -For instance, assuming the client is Bob who initially owns BTC in a swap, and the cancel path is invoked: If the client signs the `refund (e)` transaction and instructs the daemon to relay it, a malicious daemon could abstain from relaying it, resulting in a loss of funds for Bob, if he does not detect this error and submit the signed transaction via an alternate route before Alice can submit the `punish (f)` transaction to punish Bob `(**)`. +For instance, assuming the client is the arbitrating seller who initially owns BTC in a swap, and the cancel path is invoked: If the client signs the `refund (e)` transaction and instructs the daemon to relay it, a malicious daemon could abstain from relaying it, resulting in a loss of funds for the arbitrating seller, if he does not detect this error and submit the signed transaction via an alternate route before the accordant seller can submit the `punish (f)` transaction to punish the arbitrating seller `(**)`. `*` *With the exception of all private keys needed to read the blockchain state, e.g. the private view key when the accordant blockchain is Monero.* @@ -118,20 +118,20 @@ The `key` datum is used to convey keys between clients and daemons. The key is t The type of the key is derived from the `key_id`: 1. `key_id`: - - `0x01`: `Ab` Alice buy key - - `0x02`: `Ac` Alice cancel key - - `0x03`: `Ar` Alice refund key - - `0x04`: `Ap` Alice punish key - - `0x05`: `Ta` Alice adaptor key - - `0x06`: `K_s^a` Alice spend key - - `0x07`: `K_v^a` Alice private view key - - `0x08`: `Bf` Bob fund key - - `0x09`: `Bb` Bob buy key - - `0x0a`: `Bc` Bob cancel key - - `0x0b`: `Br` Bob refund key - - `0x0c`: `Tb` Bob adaptor key - - `0x0d`: `K_s^b` Bob spend key - - `0x0e`: `K_v^b` Bob private view key + - `0x01`: `Ab` the accordant seller buy key + - `0x02`: `Ac` the accordant seller cancel key + - `0x03`: `Ar` the accordant seller refund key + - `0x04`: `Ap` the accordant seller punish key + - `0x05`: `Ta` the accordant seller adaptor key + - `0x06`: `K_s^a` the accordant seller spend key + - `0x07`: `K_v^a` the accordant seller private view key + - `0x08`: `Bf` the arbitrating seller fund key + - `0x09`: `Bb` the arbitrating seller buy key + - `0x0a`: `Bc` the arbitrating seller cancel key + - `0x0b`: `Br` the arbitrating seller refund key + - `0x0c`: `Tb` the arbitrating seller adaptor key + - `0x0d`: `K_s^b` the arbitrating seller spend key + - `0x0e`: `K_v^b` the arbitrating seller private view key ### The `signature` Datum @@ -147,8 +147,8 @@ The `signature` datum is used to convey signatures between clients and daemons. The swap role: 1. `role`: - - `0x01`: Alice - - `0x02`: Bob + - `0x01`: the accordant seller + - `0x02`: the arbitrating seller ### The `proof` Datum @@ -178,19 +178,19 @@ The `parameter` datum is used to convey parameters between clients and daemons s The type of the parameter is derived from the `param_id`: 1. `param_id`: - - `0x01`: Alice destination address - - `0x02`: Bob refund address + - `0x01`: the accordant seller destination address + - `0x02`: the arbitrating seller refund address - `0x03`: Cancel timelock - `0x04`: Punish timelock - `0x05`: Fee strategy ## Datum Bundles -Datum described above is succinct and used to convey an atomic chunk of data (datum) between clients and daemons. We also present here the bundles used during the different steps of a swap by both Alice and Bob. A bundle is an aggregate of 1 or more `datum` generally related to each other. +Datum described above is succinct and used to convey an atomic chunk of data (datum) between clients and daemons. We also present here the bundles used during the different steps of a swap by both the accordant seller and the arbitrating seller. A bundle is an aggregate of 1 or more `datum` generally related to each other. ### The `alice_session_params` Bundle -**Sent by**: Alice clients|Bob daemon +**Sent by**: the accordant seller clients|the arbitrating seller daemon Provides the (counter-party) daemon with all the information required for the initialization step of a swap. @@ -210,7 +210,7 @@ Provides the (counter-party) daemon with all the information required for the in ### The `bob_session_params` Bundle -**Sent by**: Bob clients|Alice daemon +**Sent by**: the arbitrating seller clients|the accordant seller daemon Provides the (counter-party) daemon with all the information required for the initialization step of a swap. @@ -229,7 +229,7 @@ Provides the (counter-party) daemon with all the information required for the in ### The `cosigned_arbitrating_cancel` Bundle -**Sent by**: Alice|Bob clients +**Sent by**: the accordant seller|the arbitrating seller clients Provides daemon with a signature on the unsigned `cancel (d)` transaction. @@ -239,9 +239,9 @@ Provides daemon with a signature on the unsigned `cancel (d)` transaction. ### The `core_arbitrating_transactions` Bundle -**Sent by**: Bob clients|Alice daemon +**Sent by**: the arbitrating seller clients|the accordant seller daemon -Provides Bob's daemon or Alice's clients the core set of arbitrating transactions. +Provides the arbitrating seller's daemon or the accordant seller's clients the core set of arbitrating transactions. 1. data: - The `lock (b)` transaction @@ -251,9 +251,9 @@ Provides Bob's daemon or Alice's clients the core set of arbitrating transaction ### The `signed_adaptor_buy` Bundle -**Sent by**: Bob clients|Alice daemon +**Sent by**: the arbitrating seller clients|the accordant seller daemon -Provides Bob's daemon or Alice's client with an adaptor signature for the unsigned `buy (c)` transaction. +Provides the arbitrating seller's daemon or the accordant seller's client with an adaptor signature for the unsigned `buy (c)` transaction. 1. data: - The `Bb(Ta)` `buy (c)` adaptor signature @@ -261,9 +261,9 @@ Provides Bob's daemon or Alice's client with an adaptor signature for the unsign ### The `fully_signed_buy` Bundle -**Sent by**: Alice clients|Bob daemon +**Sent by**: the accordant seller clients|the arbitrating seller daemon -Provides Alice's daemon or Bob's clients with the two signatures on the unsigned `buy (c)` transaction. +Provides the accordant seller's daemon or the arbitrating seller's clients with the two signatures on the unsigned `buy (c)` transaction. 1. data: - The `Ab` `buy (c)` signature @@ -272,9 +272,9 @@ Provides Alice's daemon or Bob's clients with the two signatures on the unsigned ### The `signed_adaptor_refund` Bundle -**Sent by**: Alice clients|Bob daemon +**Sent by**: the accordant seller clients|the arbitrating seller daemon -Provides Alice's daemon or Bob's clients with a signature on the unsigned `refund (e)` transaction. +Provides the accordant seller's daemon or the arbitrating seller's clients with a signature on the unsigned `refund (e)` transaction. 1. data: - The `Ar(Tb)` `refund (e)` adaptor signature @@ -282,9 +282,9 @@ Provides Alice's daemon or Bob's clients with a signature on the unsigned `refun ### The `fully_signed_refund` Bundle -**Sent by**: Bob clients|Alice daemon +**Sent by**: the arbitrating seller clients|the accordant seller daemon -Provides Bob's daemon or Alice's clients with the two signatures on the unsigned `refund (e)` transaction. +Provides the arbitrating seller's daemon or the accordant seller's clients with the two signatures on the unsigned `refund (e)` transaction. 1. data: - The `Br` `refund (e)` signature @@ -293,9 +293,9 @@ Provides Bob's daemon or Alice's clients with the two signatures on the unsigned ### The `signed_arbitrating_lock` Bundle -**Sent by**: Bob clients +**Sent by**: the arbitrating seller clients -Provides Bob's daemon with the signature on the unsigned `lock (b)` transaction. +Provides the arbitrating seller's daemon with the signature on the unsigned `lock (b)` transaction. 1. data: - The `Bf` `lock (b)` signature for unlocking the funding @@ -303,9 +303,9 @@ Provides Bob's daemon with the signature on the unsigned `lock (b)` transaction. ### The `signed_arbitrating_punish` Bundle -**Sent by**: Alice clients +**Sent by**: the accordant seller clients -Provides Alice's daemon with the signature on the unsigned `punish (f)` transaction. +Provides the accordant seller's daemon with the signature on the unsigned `punish (f)` transaction. 1. data: - The `Ap` `punish (f)` signature for unlocking the cancel transaction UTXO @@ -316,7 +316,7 @@ We define `instruction` messages as "courtesy" messages exchanged between a clie ### The `abort` Instruction -**Sent by**: Alice|Bob clients|daemon +**Sent by**: the accordant seller|the arbitrating seller clients|daemon Provides clients or the daemon the instruction to abort the swap. It is the daemon's responsibility to abort according to the current swap-state. Upon daemon `abort` instruction, the client must be able to provide any missing signatures. @@ -329,18 +329,18 @@ The `abort` instruction can come from the client because the user chose to abort #### Daemon's response to `abort` Instruction -**Sent by**: Bob and Alice daemon +**Sent by**: the arbitrating seller and the accordant seller daemon `abort` instruction MAY trigger Tasks, and their downstream effects, depending on who called it and the current swap-state, such as: - - Bob or Alice: `publish_tx cancel` | `watch_tx cancel` - - Bob: `fully_sign_refund` - - Bob: `publish_tx refund` & `watch_tx refund` - - Alice: `sign_arbitrating_punish` - - Alice: `publish_punish` + - the arbitrating seller or the accordant seller: `publish_tx cancel` | `watch_tx cancel` + - the arbitrating seller: `fully_sign_refund` + - the arbitrating seller: `publish_tx refund` & `watch_tx refund` + - the accordant seller: `sign_arbitrating_punish` + - the accordant seller: `publish_punish` ### The `next` Instruction -**Sent by**: Alice|Bob clients +**Sent by**: the accordant seller|the arbitrating seller clients Provides daemon the instruction to follow the swap protocol, daemon can create locking steps during the protocol execution and require the client to acknowledge the execution progression. diff --git a/07-cryptographic-setup.md b/07-cryptographic-setup.md index a9a4683..e4f2b83 100644 --- a/07-cryptographic-setup.md +++ b/07-cryptographic-setup.md @@ -12,8 +12,8 @@ This RFC specifies the cryptographic primitives used to transfer secrets through ## Table of Contents * [Cryptographic Keys](#cryptographic-keys) - * [Alice](#alice) - * [Bob](#bob) + * [Accordant seller](#accordant-seller) + * [Arbitrating seller](#arbitrating-seller) * [Signatures](#signatures) * [Adaptor Signatures](#adaptor-signatures) * [ECDSA Scripts](#ecdsa-scripts) @@ -33,9 +33,9 @@ For each public key described in the following section, we assume knowledge of t **Accordant example:** for Monero the `public_key` is an `ed25519` public key. -### Alice +### Accordant seller -Keys generated by Alice role at the beginning of the swap phase: +Keys generated by the accordant seller role at the beginning of the swap phase: ``` Ab: arbitrating buy public_key; @@ -52,9 +52,9 @@ where Ta = K_s^a projection over the arbitrating group ``` -### Bob +### Arbitrating seller -Keys generated by Bob role at the beginning of the swap phase: +Keys generated by the arbitrating seller role at the beginning of the swap phase: ``` Bf: arbitrating fund public_key; diff --git a/08-transactions.md b/08-transactions.md index 20df4af..4b7d1b0 100644 --- a/08-transactions.md +++ b/08-transactions.md @@ -42,8 +42,6 @@ The latter is the preferred option for privacy but depends on feature activation `[TIMEOUTOP]` is either `CHECKSEQUENCEVERIFY` or `CHECKLOCKTIMEVERIFY`. -> It is worth noting that `CHECKLOCKTIMEVERIFY` will probably not work if we want to support RBF (Replace By Fee) - #### Bitcoin transaction graph ![Arbitrating UTXO based transaction graph](./08-transactions/arbitrating-tx-graph.png) @@ -74,23 +72,23 @@ The `lock (b)` creates a (SegWit v0) UTXO `(ii)` with the locking script: ``` IF - 2 2 CHECKMULTISIG + 2 2 CHECKMULTISIG ELSE [TIMEOUTOP] DROP - 2 2 CHECKMULTISIG + 2 2 CHECKMULTISIG ENDIF where - Ab: Alice's buy key; - Bb: Bob's buy key; - Ac: Alice's cancel key; - Bc: Bob's cancel key; and - Ta: Alice's adaptor key + Ab: the accordant seller's buy key; + Bb: the arbitrating seller's buy key; + Ac: the accordant seller's cancel key; + Bc: the arbitrating seller's cancel key; and + Ta: the accordant seller's adaptor key ``` **Validation rules:** -Upon receiving the transaction, Alice must validate: +Upon receiving the transaction, the accordant seller must validate: * the buy script is composed of a 2-of-2 multisig with: * the first public key is `Ab` @@ -121,13 +119,13 @@ The `lock (b)` creates a (SegWit v1) Taproot UTXO `(ii)` with the locking script with `TapLeaf buy script`: ``` - CHECKSIG CHECKSIGADD m + CHECKSIG CHECKSIGADD m NUMEQUAL where - Ab: Alice's buy key; - Bb: Bob's buy key; and - Ta: Alice's adaptor key + Ab: the accordant seller's buy key; + Bb: the arbitrating seller's buy key; and + Ta: the accordant seller's adaptor key ``` and `TapLeaf cancel script`, the cancel script, a 2-of-2 multisig with timelock constraint used by the `cancel (d)` transaction. @@ -137,12 +135,12 @@ and `TapLeaf cancel script`, the cancel script, a 2-of-2 multisig with timelock ``` [TIMEOUTOP] EQUALVERIFY DROP - CHECKSIG CHECKSIGADD m + CHECKSIG CHECKSIGADD m NUMEQUAL where - Ac: Alice's cancel key; and - Bc: Bob's cancel key; + Ac: the accordant seller's cancel key; and + Bc: the arbitrating seller's cancel key; ``` #### Taproot MuSig2 @@ -165,30 +163,30 @@ The `lock (b)` creates a (SegWit v1) Taproot UTXO `(ii)` with the locking script P: Ab + Bb + Ta where - Ab: Alice's buy key; - Bb: Bob's buy key; and - Ta: Alice's adaptor key + Ab: the accordant seller's buy key; + Bb: the arbitrating seller's buy key; and + Ta: the accordant seller's adaptor key ``` `TapLeaf cancel script`, the cancel script, as described in *Taproot Schnorr Scripts*. ### Buy -The `buy` transaction is available as soon as the local confirmation security threshold is reached by Alice. +The `buy` transaction is available as soon as the local confirmation security threshold is reached by the accordant seller. #### ECDSA Scripts Consumes the `lock`'s output `(ii)` with: ``` -0 TRUE