Thomas Eizinger
3 years ago
parent
0b17b1177a
commit
d6789508da
|
Before Width: | Height: | Size: 135 KiB |
@ -1,154 +0,0 @@
|
||||
# XMR<>BTC Atomic Swap - User Interface Prototype Definition
|
||||
|
||||
This document specifies assumptions concerning possible user interfaces on top of the [Monero-Bitcoin swap as described by Lucas on the COMIT-blog](https://comit.network/blog/2020/10/06/monero-bitcoin/).
|
||||
|
||||
We first specify assumptions and limitations imposed by the current setup and software needed for the swap, then outline possible solutions.
|
||||
This document will be used as a basis for defining and evaluating low-fidelity UI prototypes in the prototyping tool Figma.
|
||||
|
||||
## Assumptions
|
||||
|
||||
This section sums up assumptions around the current setup, protocol and existing software.
|
||||
|
||||
### Security Assumptions
|
||||
|
||||
Swap-solutions that run completely in the browser (webpage) and rely on connecting to a locally running blockchain node are currently not possible because specifying [CORS headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS) is a security risk.
|
||||
This means the browser will reject a response from a locally running Bitcoin node.
|
||||
Discussions have been ongoing, notably for [bitcoind](https://github.com/bitcoin/bitcoin/issues/11833), to add features that would allow webpages to communicate with locally running blockchain nodes directly.
|
||||
However, it is hard to verify the code of a webpage when accessing the webpage in a browser and thus not recommended to add features that would allow to do this.
|
||||
|
||||
Theoretically this could be overcome by creating a node infrastructure behind a proper REST API, or with a locally running proxy. However, it is questionable if these are favourable solution, as they adds additional software on top of the blockchain nodes.
|
||||
|
||||
We will focus on solutions that favour the use of locally running blockchain nodes and explore solutions that do not access locally running blockchain nodes from a webpage directly.
|
||||
|
||||
### Current Setup
|
||||
|
||||
To be able to provide a reasonably trustless setup, where the user is in control of his private keys the user is currently advised to run his own Bitcoin and Monero node.
|
||||
|
||||
Given the current setup this results in the following software necessary to achieve a swap:
|
||||
|
||||
* Bitcoin Blockchain Node
|
||||
* Monero Blockchain Node
|
||||
* Bitcoin Wallet
|
||||
* Monero Wallet
|
||||
* **Swap Execution Daemon**: Monitor the blockchain and move the swap forward to the next action.
|
||||
* **Interface to connect the trading partners**: The two parties have to find each other and start the `Swap Execution Daemon` with the correct parameters. The interface can be realised in multiple different ways, from single-maker, P2P trading platform to P2P marketplace.
|
||||
|
||||
For Bitcoin the current setup relies on a synced bitcoind node and bitcoind's wallet.
|
||||
For Monero the current setup relies on a synced monerod node and monero's wallet RPC.
|
||||
For funding Monero an existing wallet is unlocked and used for the swap.
|
||||
For funding Bitcoin an existing wallet is unlocked and used for the swap.
|
||||
The swap execution daemon has control over the wallets during the swap execution to allow automated broadcasting of the transactions.
|
||||
|
||||
The current setup relies on generating a *new* Monero wallet for `redeeming` or `refunding`.
|
||||
One trivial solution would be to add an additional transaction in the end, that transfers the Monero to the user's wallet.
|
||||
More optimized solutions are possible as well, but require more research.
|
||||
Since there are solutions to overcome the need of a second wallet we decided **not** to mock this part of the current setup in the UI prototypes.
|
||||
|
||||
### Current Protocol
|
||||
|
||||
The POC protocol is asymmetric and comes with several constraints that affect the user experience:
|
||||
|
||||
1. The party that funds Bitcoin has to fund first.
|
||||
2. The party that funds Bitcoin is always in the role of Bob.
|
||||
3. There is an information exchange (Bob sends Alice a key-part for redeeming) during the execution of the swap which requires (P2P) communication between the parties.
|
||||
|
||||
Even though that is not per se limiting we have to acknowledge that the protocol will behave different for the maker and taker for the respective direction of the swap.
|
||||
|
||||
The protocol comes with different incentives for the two roles Alice and Bob.
|
||||
We think that, for a maker it is favourable to be in the role of Alice, because in Alice is in the powerful position of holding the secret. Additionally Bob funds first in the POC.
|
||||
However, to be able to allow a product that offers XRM->BTC and BTC->XMR swaps, we decided to let the maker and taker be in either role.
|
||||
The UX of the swap might be different depending on the role a party takes, especially when depicting the swap steps.
|
||||
|
||||
### Additional Assumptions
|
||||
|
||||
The first version of a prototype will not include hardware wallet (e.g. Ledger Nano S) support.
|
||||
In previous products we focused on swaps directly from and to cold storage, however, this does not concern a large enough user base to support it in the initial version.
|
||||
Furthermore, hardware wallets add certain restrictions (forced user-interaction to sign transactions) that might conflict with the current prototol design.
|
||||
Using the wallets of the standard implementations (monerod and bitcoind) is the easiest, most straightforward starting point.
|
||||
Hardware wallet support can be added at a later point if requested as feature by the community.
|
||||
|
||||
## Possible Solutions
|
||||
|
||||
This section outlines possible solutions based on the assumptions stated above.
|
||||
This section does not focus on the UX of the swap and the use-case specifics, but on the interaction between browser and other applications needed to achieve the swap.
|
||||
|
||||
We have explored the following options:
|
||||
|
||||
1. Extending existing (wallet) UIs (e.g. monero-wallet-gui) for swaps.
|
||||
2. Webpage based swaps (completely running in browser).
|
||||
3. Browser extension for swaps.
|
||||
4. Desktop application for swaps.
|
||||
|
||||
Note that for desktop applications (4.) we explore the possibility of triggering the application through the browser.
|
||||
|
||||
### Extending existing (wallet) UIs
|
||||
|
||||
The nature of a swap requires management of both assets of the swap to be able to fund and redeem.
|
||||
This means, that a swap execution software has to interact with wallet software on both sides.
|
||||
|
||||
Additionally, due to the complexity of the current swap protocol's setup and the fact that there is information exchange during the execution phase, it is highly questionable that communities on both sides would extend wallet functionality to allow swaps.
|
||||
For the time being the way forward seems to be a swap tool that plugs into existing wallet and blockchain node software on both sides, but handles additional requirements necessary for swap execution without modifying the existing software.
|
||||
|
||||
### Webpage
|
||||
|
||||
Allowing webpages access to a locally running
|
||||
A complete webpage based solution is not easily possible because of the CORS header restriction of browsers.
|
||||
We could enable communication between blockchain nodes and the browser through e.g. a proxy, but such a solution would not have an advantage over running a desktop application, because either way one has to run additional software next to the blockchain nodes to enable the swap.
|
||||
|
||||
### Browser Extension
|
||||
|
||||
Browser extensions, are not as restrictive as webpages as can be seen in the [Google Chrome's documentsion](https://developer.chrome.com/extensions/xhr).
|
||||
A browser extension would be able to offer a well-defined API, that allows multiple different web-sites to offer services within the extension.
|
||||
This could range from discovery, negotiation to execution.
|
||||
|
||||
Implementing a browser extension that handles the communication between maker and taker, and is able to communicate with locally running wallets and blockchain nodes is a valid solution.
|
||||
We could also implement the decentralized orderbook on top of the browser extension, it is however, questionable if that would not be too much complexity packed into such kind of extension.
|
||||
We are still evaluating what is feasible for such an extension.
|
||||
To start with a desktop application is simpler to prototype.
|
||||
|
||||
Mozilla's [web-ext tool](https://github.com/mozilla/web-ext) - besides [other tools](https://extensionworkshop.com/documentation/develop/browser-extension-development-tools/) - can help enable cross-browser extensions.
|
||||
|
||||
### Desktop Application
|
||||
|
||||
A desktop application is a valid solution that is not subject to restrictions by the browser.
|
||||
|
||||
The problem of finding a trading partner can be outsourced to a webpage (e.g. single-maker only).
|
||||
Custom URL schemes can help to provide a better user experience, as they allow us to open the swap desktop application with parameters passed to the application through the customer URL.
|
||||
It can, however, be be quite a pain to achieve the proper registration of custom URL schemas for different kinds of operating systems.
|
||||
|
||||
A stand-alone desktop applications is possible, but can be seen as a hurdle, because every user first has to download the binary to see any form of user interface.
|
||||
For complex applications that involve a decentralized orderbook a desktop application might be advisable for the moment.
|
||||
|
||||
For previous MVPs we used [Electron](https://www.electronjs.org/) to implement cross-platform desktop applications.
|
||||
|
||||
## Use-case specific prototypes
|
||||
|
||||
Given the assumptions, technical limitations and resulting possible solutions described above this section specifies details for the prototypes described in the [initial project description](https://github.com/coblox/spikes/blob/master/0003-xmr-btc-product.md).
|
||||
In the initial project description we define two products to be mocked as prototypes, (A) single market maker and (B) peer-to-peer decentralized trading platform.
|
||||
|
||||
Note, that the use-cases of a single market maker product and a peer-to-peer decentralized trading platform are agnostic to the user interface.
|
||||
Both products can be realised as CLI or UI taken into account the assumption listed above.
|
||||
|
||||
The "product specific prototypes" focus on the setup and interaction of different software.
|
||||
When it comes to prototyping specific user interface details, like for example the swap execution steps, we may opt for creating separate detail-mocks focussing on these details.
|
||||
|
||||
### A. Single Market Maker product
|
||||
|
||||
The point of this product is to keep `finding a trading partner` (discovery) and `agreeing on a trade` (negotiation) simple by only having a single maker.
|
||||
A single-maker runs a webpage that gives a price. A taker can "take it or leave it".
|
||||
|
||||
We plan to create two prototypes:
|
||||
|
||||
1. **Webpage + CLI:** The webpage prints a command that instructs the taker how to start the swap execution daemon.
|
||||
2. **Webpage + UI:** The webpage uses a custom URL schema to trigger a desktop application passing the trading parameters to the application.
|
||||
|
||||
Additionally we might showcase a prototype that uses a webpage and browser-extension given that we can fit it into the project scope.
|
||||
|
||||
### B. Peer-to-peer decentralised trading platform
|
||||
|
||||
This product differs from product (A) by treating the discovery in a decentralized manner as well as allowing multiple makers.
|
||||
|
||||
The prototype will be modelled in a way, that keeps the negotiation (i.e. orderbook) simple.
|
||||
The discovery shall be depicted as peer-to-peer.
|
||||
It is planned to show specific orders of makers to takers, rather than prototyping a trading platform that includes order-matching.
|
||||
The prototype will be modelled as desktop application that includes and controls the swap execution daemon.
|
||||
@ -1,172 +0,0 @@
|
||||
# XMR<>BTC Atomic Swap - User Interface Prototype Validation
|
||||
|
||||
This document:
|
||||
|
||||
1. Collects the validation criteria.
|
||||
2. Lists the created user interface prototypes, and link to Figma.
|
||||
3. Maps the protoypes to the validation criteria.
|
||||
|
||||
This document will be updated with new information during the course of the project.
|
||||
|
||||
## Questions
|
||||
|
||||
The questions are split between `M`aker (liquidity provider) and `T`aker (normal user), because the objectives are somewhat different.
|
||||
|
||||
| **Topic** | **High Level Questions** | **More specific question** | **User is happy to...** | **Actor** |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| Node & Wallet Management | How do users monitor the Bitcoin and Monero blockchain? | Is a user fine with trusting a third party to monitor transactions? | use a service like blockchain.com to retrieve blocks for validation | TM |
|
||||
| | | | run his own Bitcoin node, third party service for Monero | TM |
|
||||
| | | | run his own Monero node, third party service for Bitcoin | TM |
|
||||
| | | | run both his own Bitcoin and Monero node | TM |
|
||||
| | How do users brodcast transactions to Bitcoin and Monero? | Is a user fine with trusting a third party to broadcast transactions? | use a wallet that connects to third party nodes | TM |
|
||||
| | | | send signed transactions through third part nodes | TM |
|
||||
| | | | run his own blockchain full node | TM |
|
||||
| | | | run an SPV node (Bitcoin) | TM |
|
||||
| | How do users manage their wallets to interace with other software? | Do users want to use already existing wallets? | fund and redeem from existing wallets | TM |
|
||||
| | | | fund from existing Monero wallet, redeem to new Bitcoin wallet | TM |
|
||||
| | | | fund from existing Bitcoin wallet, redeem to new Monero wallet | TM |
|
||||
| | | | fund and redeem into new wallets (explicitly used for swap execution) | TM |
|
||||
| | | What level of control does the user give to the execution daemon? | give the execution daemon control over the wallets (no user interaction, fully automated) | TM |
|
||||
| | | | use a Bitcoin transaction to give funds to the swap application | TM |
|
||||
| | | | use a Monero transaction to give funds to the swap application | TM |
|
||||
| | | | explicitly sign each transaction | TM |
|
||||
| Discovery | How do users discover trading partners? | Do users care about privacy? | go to website and take price from there | T |
|
||||
| | | | set up website (publicly) to advertise price (and connection information) | M |
|
||||
| | | | open "random" (tor) website found on various media (forums, chat) to access a single market maker. | T |
|
||||
| | | | configure Tor for trading | TM |
|
||||
| | | Do users care about P2P? | use a centralized service to find makers | TM |
|
||||
| | | | user a decentralized service to find makers | TM |
|
||||
| | | | discover peers automatically | TM |
|
||||
| | | | add peers manually | TM |
|
||||
| Software Setup | How does the user want to manage the swap software setup? | Is the user willing to download software? | download software (swap execution daemon) before being able to do a swap | T |
|
||||
| | | How does the user want to manage long-running tasks? | keep a GUI/CLI open for the whole length of the swap execution | T |
|
||||
| | | | keep a computer running (that hosts the daemon) for the whole length of the swap execution | T |
|
||||
| | | | keep the browser open for the whole length of a swap | T |
|
||||
| Protocol | How important are protocol details to the user? | Does the user care about the incentives of each role? | have different steps (locking first vs second) depending on the direction of the swap | TM |
|
||||
|
||||
|
||||
## Prototypes
|
||||
|
||||
In the initial project description we distinguished product `A` a single market-maker product and product `B` a product including peer-to-peer discovery and multiple makers.
|
||||
|
||||
```
|
||||
P ... Prototype that showcases a complete swap setup flow.
|
||||
D ... Prototype that focuses on a specific detail of swap setup / execution.
|
||||
|
||||
{}-A ... Prototype for product A (single market maker)
|
||||
{}-B ... Prototype for product B (decentralized trading platform)
|
||||
```
|
||||
|
||||
Example:
|
||||
|
||||
`D-A2-1`: Mock showing detail 1 for prototype `P-A1`
|
||||
|
||||
### Figma Links
|
||||
|
||||
Main prototypes
|
||||
|
||||
* [P-A1](https://www.figma.com/proto/QdvmbRYuBpEpFI3D1R4qyM/XMR-BTC_SingleMaker_LowFidelity?node-id=54%3A4894&viewport=1503%2C-52%2C0.5576764941215515&scaling=min-zoom): Webpage for discovery, CLI for execution
|
||||
* [P-A2](https://www.figma.com/proto/QdvmbRYuBpEpFI3D1R4qyM/XMR-BTC_SingleMaker_LowFidelity?node-id=7%3A4377&viewport=696%2C-250%2C0.362735778093338&scaling=min-zoom): Webpage for discovery, GUI for execution
|
||||
* [P-B1](https://www.figma.com/proto/JnZDMtdEIiqcW1A8pTCfWx/XMR-BTC_TradingPlatform_LowFidelity?node-id=392%3A0&viewport=-1132%2C957%2C0.5096595883369446&scaling=min-zoom): Manual or automated P2P discovery of trades, CLI for execution
|
||||
* [P-B2](https://www.figma.com/proto/qla2uA7bXeyAU0XYqf4APh/XMR-BTC-P2P-Trading-GUI?node-id=138%3A480&viewport=-49%2C1295%2C0.17819291353225708&scaling=min-zoom): Automated P2P discovery of trades, GUI for execution
|
||||
|
||||
Showcasing details:
|
||||
|
||||
* [D-A2-1](https://www.figma.com/proto/QdvmbRYuBpEpFI3D1R4qyM/XMR-BTC_SingleMaker_LowFidelity?node-id=235%3A1374&viewport=1336%2C-1825%2C0.7878535389900208&scaling=min-zoom): GUI swap execution steps for `send` `BTC`, `receive` `XMR`
|
||||
* [D-A2-2](https://www.figma.com/proto/QdvmbRYuBpEpFI3D1R4qyM/XMR-BTC_SingleMaker_LowFidelity?node-id=128%3A8016&viewport=1404%2C-1158%2C0.66261225938797&scaling=min-zoom): GUI swap execution steps for `send` `XMR`, `receive` `BTC`
|
||||
|
||||
|
||||
### Mapping of Prototype to validation criteria
|
||||
|
||||
| **User is happy to...** | **Actor** | **P-A1** | **P-A2** | **D-A2-1** | **D-A2-2** | **P-B1** | **P-B2** |
|
||||
| --- | --- | --- | --- | --- | --- | --- | --- |
|
||||
| use a service like blockchain.com to retrieve blocks for validation | TM | | | | | | |
|
||||
| run his own Bitcoin node, third party service for Monero | TM | | | | | | |
|
||||
| run his own Monero node, third party service for Bitcoin | TM | | | | | | |
|
||||
| run both his own Bitcoin and Monero node | TM | T | T | | | T | T |
|
||||
| use a wallet that connects to third party nodes | TM | | | | | | |
|
||||
| send signed transactions through third part nodes | TM | | | | | | |
|
||||
| run his own blockchain full node | TM | T | T | | | T | T |
|
||||
| run an SPV node (Bitcoin) | TM | | | | | | |
|
||||
| fund and redeem from existing wallets | TM | T | T | | | T | T |
|
||||
| fund from existing Monero wallet, redeem to new Bitcoin wallet | TM | | | | | | |
|
||||
| fund from existing Bitcoin wallet, redeem to new Monero wallet | TM | | | | | | |
|
||||
| fund and redeem into new wallets (explicitly used for swap execution) | TM | | | | | | |
|
||||
| give the execution daemon control over the wallets (no user interaction, fully automated) | TM | T | T | | | T | T |
|
||||
| use a Bitcoin transaction to give funds to the swap application | TM | | | | | | |
|
||||
| use a Monero transaction to give funds to the swap application | TM | | | | | | |
|
||||
| explicitly sign each transaction | TM | | | | | | |
|
||||
| go to website and take price from there | T | | | | | | |
|
||||
| set up website (publicly) to advertise price (and connection information) | M | M | M | | | | |
|
||||
| open "random" (tor) website found on various media (forums, chat) to access a single market maker. | T | | | | | | |
|
||||
| configure Tor for trading | TM | | | | | | |
|
||||
| use a centralized service to find makers | TM | T | T | | | | |
|
||||
| user a decentralized service to find makers | TM | | | | | T | T |
|
||||
| discover peers automatically | TM | | | | | T | T |
|
||||
| add peers manually | TM | | | | | T | |
|
||||
| download software (swap execution daemon) before being able to do a swap | T | | | | | | |
|
||||
| keep a GUI/CLI open for the whole length of the swap execution | T | | | T | T | T | T |
|
||||
| keep a computer running (that hosts the daemon) for the whole length of the swap execution | T | T | T | T | T | T | T |
|
||||
| keep the browser open for the whole length of a swap | T | | | | | | |
|
||||
| have different steps (locking first vs second) depending on the direction of the swap | TM | | | T (M) | T (M) | T (M) | T (M) |
|
||||
|
||||
|
||||
Legend:
|
||||
|
||||
```
|
||||
T ... Taker
|
||||
M ... Maker
|
||||
TM ... Taker and Maker
|
||||
T (M) ... Taker showcased, Maker implicitly concerned as well
|
||||
```
|
||||
|
||||
## Interviews
|
||||
|
||||
Through user interviews we plan to collect more information on the current setup of users, and how it could be used in a potential product.
|
||||
|
||||
Specific prototypes showcase specific answers to the questions listed above. We may use the prototypes in interviews to showcase scenarios.
|
||||
|
||||
|
||||
## Feedback
|
||||
|
||||
### Possible Features List
|
||||
|
||||
This section points out features that were mentioned by the community. These features will be evaluated and prioritized before we start building.
|
||||
|
||||
#### Avoid receiving tainted Bitcoin
|
||||
|
||||
Mentions:
|
||||
|
||||
* [27.11.2020 on Reddit](https://www.reddit.com/r/Monero/comments/k14hug/how_would_an_atomic_swap_ui_look_like/gdplnt8?utm_source=share&utm_medium=web2x&context=3)
|
||||
|
||||
The receiver of the Bitcoin should be able to validate the address to be used by the sender to avoid receiving tainted Bitcoin (i.e. coins that were unlawfully used).
|
||||
This feature is relevant for the receiving party of the Bitcoin, it is relevant for taker and maker.
|
||||
This feature is relevant independent of the user use case.
|
||||
|
||||
In order to be able to spot tainted Bitcoin, the receiver has to validate the address to be used of the sender.
|
||||
In the current protocol the party funding (sending) Bitcoin always moves first.
|
||||
|
||||
The party receiving the Bitcoin would have to request the address to be used by the sender.
|
||||
For the beginning it might be good enough to let the taker verify that the Bitcoin are not tainted manually, by enabling the taker to provide e.g. a CSV file with tainted addresses by themselves.
|
||||
Eventually, an automated service could be integrated, that keeps listings of tainted Bitcoin up to date.
|
||||
More research is needed to evaluate if reliable services exist.
|
||||
|
||||
Once the daemon of the party receiving the Bitcoin sees the Bitcoin transaction of the sender, the address has to be evaluated to ensure the correct address has been used for funding.
|
||||
This can be done automated.
|
||||
In case a tainted address was used the swap execution should halt and give a warning to the receiving party.
|
||||
|
||||
#### Improve Anonymity
|
||||
|
||||
Monero is a privacy focused coin, anonymity is important to the community.
|
||||
This section focuses on hiding your IP address when doind trades.
|
||||
|
||||
Mention happened in user interviews, mentions:
|
||||
|
||||
* 03.12.2020, PM
|
||||
|
||||
[Running Tor](https://web.getmonero.org/resources/user-guides/tor_wallet.html) is not the only possibility to to achieve levels of anonymity using Monero.
|
||||
Here is a collection of other tools/possibilities:
|
||||
|
||||
* [Run Monero node through I2P using I2P-zero](https://web.getmonero.org/resources/user-guides/node-i2p-zero.html)
|
||||
* [Dandelion++](https://www.monerooutreach.org/stories/dandelion.html)
|
||||
|
||||
@ -1,64 +0,0 @@
|
||||
@startuml
|
||||
database Bitcoin
|
||||
actor Bob as "Bob (User)"
|
||||
Actor Alice as "Alice (Service Provider)"
|
||||
database Monero
|
||||
|
||||
group Negotiation
|
||||
|
||||
Bob --> Alice: Establish connection
|
||||
|
||||
group Request Response Channel
|
||||
Bob -> Alice: Quote request
|
||||
note left: Btc Amount\naddress hints
|
||||
note right: Alice stores peer id & address hints\nto contact Bob
|
||||
|
||||
Alice --> Bob: Quote response
|
||||
note right: Exact XMR amount
|
||||
end
|
||||
end
|
||||
|
||||
group Execution Setup
|
||||
group Phase A [Messages can be exchanged in any order]
|
||||
Bob -> Alice: Message0
|
||||
note left: Pubkeys\ndleq proof s_b\nxmr viewkey v_b\nbtc refund addr
|
||||
|
||||
Alice -> Bob: Message1
|
||||
note right: Pubkeys\ndleq proof s_a\nxmr view key v_a\nbtc redeem addr\nbtc punish addr
|
||||
end
|
||||
|
||||
group Phase B [Messages must be exchanged in the given order]
|
||||
|
||||
Bob -> Alice: Message2
|
||||
note left: unsigned btc lock tx
|
||||
|
||||
Alice -> Bob: Message3
|
||||
note right: btc cancel tx sig\nbtc refund tx enc sig S_b
|
||||
|
||||
Bob -> Alice: Message4
|
||||
note left: btc punish tx sig\nbtc cancel tx sig
|
||||
|
||||
end
|
||||
end
|
||||
|
||||
group Execution
|
||||
Bob ->> Bitcoin: Lock
|
||||
|
||||
Alice ->> Monero: Lock
|
||||
|
||||
Alice -> Bob: TransferProof
|
||||
note right: xmr lock tx transfer proof\nThis can be removed if Bob watches the blockchain.
|
||||
|
||||
Bob -> Alice: EncryptedSignature
|
||||
note left: redeem tx enc sig S_a
|
||||
|
||||
Alice ->> Bitcoin: Redeem
|
||||
|
||||
Bitcoin ->> Bob: Signature
|
||||
|
||||
Bob -> Bob: Extract s_a
|
||||
|
||||
Bob ->> Monero: Redeem
|
||||
end
|
||||
|
||||
@enduml
|
||||
Loading…
Reference in new issue