it should be possible to send to an address (manual input) as well as scan a qr code

This task involves writing the first test for the ln-dlc-node crate.

Since it's the first test, it also involves a couple of tasks which will apply to all future tests:

• Writing the API to create an LN-DLC node.
• Setting up the ephemeral test environment (probably using nigiri or similar).

It is possible to reconsider if we should write an interactive CLI for manual testing instead of an automated test. As the author of this issue I am biased for automated tests (even if they don't get executed on every CI run), but that's just my opinion.

In the past (for itchysats and 10101-poc) we used sqlx which we found more than painful to work with as it had performance issues.
This time we want to go with a different implementation, e.g. diesel

This ticket covers a simple setup for a database layer.

The MVP is expected to enable multiple leverage choices.
At the moment the leverage slider is not usable in the prototype.
This makes it hard to try how it actually feels.

In order to be able to implement this component we should invest into the design of how the leverage slider would actually work in the UI.

Create a component out of the leverage slider that can be used. It is encouraged to change the design on the way to make the leverage slider more usable.

Depends on #45.

• The API should enable the features listed in #34.
• No implementation, just types and function signatures.
• Keep in mind that it will be hard to nail this down perfectly, as we always discover new information when we start implementing.

Scope:

• Create separate flow for the Designs and flow of the MVP wireframe (move copy of current flow to archive section)
• Remove the stable sats use case (MVP does not contain stable sats wallet)
• #37
• #42
• #54
• #52
• #53
• #38
• #39
• #40
• #41
• #56
• #58
• #59
• #60

We've decided to depend on rust-dlc (as opposed to e.g. a modified version of maia) and this means that we no longer have a library that supports Olivia by default. rust-dlc should support any oracle that conforms to dlcspecs and it provides an implementation of an oracle client that works with any instance of a p2pderivatives oracle.

This leaves us 3 choices:

1. Stick to Olivia and modify rust-dlc to support its bespoke attestation scheme and API. (Olivia won't be maintained long term).
2. Use a public dlcspecs-compliant oracle, such as some of the ones listed here: https://oracle.suredbits.com/.
3. Run our own instance of the p2pderivates oracle to bootstrap our setup.

Let's document our choice in an ADR.

Goal

Let the user set up the app to have a funded trading wallet.

Start

User starts from 0, i.e. he just downloaded the app: on-boarding-welcome-screen.
The user should fund the wallet using lightning.

End

User ends on the trading/funded screen and has some money in his trading wallet

Out of focus

• Evaluate the funding flow: We don't want to evaluate if the funding flow is the best in the world, but we want to educate the user how to get money into the wallet so that we can evaluate our USP: the trading flow.
• Trading: Don't show the trading screen. We will continue with another flow on this
• Wallet backup: Don’t show wallet backup details. Backup is important, but it’s not our main focus. We can evaluate the best backup options later.

Open TODOs

• Create a state where trading is not enabled because you do not have any money yet: if you click on the trade tab with an empty wallet you will not be able to trade.
• Rename the FOB on trading wallet to something like: Initial Funding.

Currently it is unclear where the funds that are being stabalized are coming from.

My thoughts:

I think we have to add a specific Move between wallets screen to achieve this.
We can consider modelling this together with funding the wallet from an external wallet, which would basically mean that upon clicking Receive the user has to decide if they want to receive from another 10101 wallet or an external wallet.

This commit (12e25a2) removes flutter lint from CI because it was failing and I was not able to fix it in this PR.

We want to lint flutter though, so let's re add it.

We want to have a clear picture of what and how things should be build.

The goal of this document is to describe the CI workflows we need and ensure that we think about them in advance.

Note: this issue covers only the coordinator while #11 covers the mobile app.

On a high level your orders actually define your trades - One order can result in multiple trades.
This means we don't necessarily need a trades tab in the trading screen, but can just structure the orders to contain the trades.
This simplifies the user interface, because there is only orders and positions in the trading screen.

Scope:

1. Remove the Trades tab
2. Change the Order entries in Orders tab to be more like a list view
3. When the user clicks on an Order the user gets a details view of the order: Design a details view of the order that shows the trades including the status of the order (filled = the order was completely executed by one or multiple trades, ...)

Goal

Let the user move funds into the stable sats wallet and pay a lightning invoice.

Start

User starts with a funded trading wallet.

End

User has funds in his stable sats wallet with 1 transaction.

Out of focus

• trading

Open TODOs

Potential things to evaluate

• Does the user understand what the stable sats wallet is about?

We want to have a clear picture of what and how things should be build.

The goal of this document is to describe the CI workflows we need and ensure that we think about them in advance.

Note: this issue covers only the mobile app while #13 covers the coordinator.

We need to define what happens when a DLC in a DLC channel is settled off-chain. This is a requirement, as we don't want to go on-chain every time that a CFD is closed. rust-dlc doesn't support settling the DLC output into the channel; it only supports collaborative settlement on-chain.

I can see 2 choices:

1. DLC is replaced by 1-2 outputs in the DLC channel paying directly to either party.
2. DLC channel is removed from the split_transaction and the coins are allocated to outputs paying to either party in the Lightning commitment transaction.

Option 1 requires modifying regular rust-dlc to support outputs other than a DLC in the buffer_transaction. Interestingly, this option means that the non-DLC funds in the DLC channel would only be readily available for trading.

[Preferred] Option 2 requires investigating the feasibility of going back and forth between a split_transaction and a regular funding_transaction as the user opens and closes positions.

Let's document our choice in an ADR and create a follow-up ticket with further steps towards the implementation.

Having discussed the product situation with @da-kami, we reached the conclusion that we want the funds in the sibling channels to either be (1) in a DLC or (2) readily available for Ligthning payments. This means that we've eliminated the concept of the trading wallet.

Given this, it appears to make little sense to go for option 1, as we don't want to write code to have coins sitting around in a hidden "trading wallet".

The purpose of this library crate is to provide the API that an application such as the 10101 app would want to use to be able to implement the features described in #34.

Even though it is a library, we need to remember that at this stage we only expect two consumers: app and coordinator. Thus, let's avoid premature generalisations.

Observations

• Eventually we should be able to move most of the code we write to p2pderivates/rust-dlc, but that requires more coordination than what we can afford right now.
• Depends on our forks of rust-dlc and rust-lightning.

When creating a release a new version of our app should be pushed to testflight.

Goal

Let the user create a market order and close his position using a market order.

Start

User starts with a funded trading wallet.

End

User ends on the Positions closed screen.

Out of focus

• everything outside of the trading screen

Open TODOs

When creating a release a new version of our app should be pushed to Android's Firebase App Distribution.

In the past we used a naive CD setup using https://github.com/containrrr/watchtower:

1. on every merge into master we published a new container
2. the watchtower polled this repository every 5 minutes and redeploys a new version if available

This works but is not optimal because even 5 minutes can be sometimes relatively long.

This task is about coming up with a new strategy which uses github actions to deploy the coordinator onto a vm.

note: in the past we used google's container optimized os which might have limited functionalities. We can move away from this if deemed necessary.

This epic assumes that we have chosen to follow the approach outlined in this blog post to build a node that supports Lightning and DLC channels side-by-side.

This decision to use this protocol will be documented in:

• #36.

The early development of this node will be carried out in a separate ln-dlc-node crate within this workspace, but ultimately the goal is to use the node as a long running process within the coordinator and mobile app binaries.

Notes on rust-dlc + rust-lightning

Forks

For the moment we focus on working on our own forks to speed up development, but eventually we are aiming to use a stable release of rust-dlc and even rust-lightning.

1. rust-dlc: https://github.com/get10101/rust-dlc/tree/feature/split-tx-manager-2

2. rust-lightning: https://github.com/get10101/rust-lightning/tree/split-tx-experiment

   • Changes are minimal but Tibo said that he would do it differently with more time.
   • It might be possible to rebase onto latest main if we need new features.

Observations

1. DLC channel does not yet support multiple outputs

   1. Multiple DLCs

      Not needed until StableSats or multiple contract symbols.

   2. DLC + regular output

      Needed to be able to open and close positions without affecting Lightning channel. This may affect ergonomics, because we don't know how long it takes to remake the split transaction and how smoothly it works.

      Theoretically it's not necessary though.

2. rust-dlc doesn't support Olivia

   1. Different attestation scheme

      Olivia uses a simpler, bespoke attestation scheme, whereas rust-dlc conforms to dlcspecs.

   2. Different API

      • Olivia uses bespoke messages, whereas rust-dlc conforms to dlcspecs.
      • We might be able to overcome this by transforming the responses from Olivia.

General

Tasks to prepare the codebase for the introduction of the ln-dlc-node crate:

• #45.
• #46.
• #47.

Features

Receive and send payments via Lightning (must)

This should be a given if we use rust-lightning and we don't mess with the commitment_transaction. In the 10101 PoC we did mess with the commitment_transaction and we broke it when the DLC was present.

Deposit into Lightning wallet using Lightning (must)

• #55.

This is effectively the same as receiving a payment without having a channel with the coordinator beforehand.

1. Options

   We figured out that routing the payment all the way to the coordinator first was best and also feasible. We list the other option in case we missed something and we end up needing a backup plan.

   1. Route payment all the way to the coordinator first

      1. Flow

         1. User tries to create invoice.
         2. App generates an invoice to the coordinator with a payment preimage that only the app knows.
         3. App shares payment hash with coordinator.
         4. Payer pays the invoice, which eventually reaches the coordinator as a HTLC.
         5. Coordinator matches the received HTLC to the one registered by the app.
         6. Coordinator opens channel with user, including HTLC with amount minus flat routing fee and liquidity-based routing fee.
         7. App claims payment.

   2. Open channel between coordinator and user first

      1. Flow

         1. User tries to create invoice.
         2. Coordinator opens channel with user with desired invoice amount as inbound liquidity for user (plus whatever inbound liquidity they would want).
         3. Invoice then generated, including route hint for final hop between coordinator and user.

      2. Drawbacks

         • Coordinator is at risk of opening the channel for no reason.
         • Slower process than the usual speedy generation of an invoice.

Receive and send on-chain (must)

In 10101-poc we achieved this by involving bdk via a fork of the bdk-ldk crate. Soon after we started using that code, the maintainer noted that the project was no longer maintained and suggested ldk-node as an alternative.

Transfer between DLC channel and Lightning wallet (must)

• Is the split_transaction always present even if only one of the channels is active?
• This is achieved by reconstructing split_transaction and children.
• Tibo said this is possible and doesn't immediately break the Lightning channel.

Send on-chain from the Lightning wallet (could)

Using submarine swaps. We may not need to implement this service ourselves.

Create a CFD based on a price event from an oracle (must)

• #126.
• #48.

Use the APIs already provided by rust-dlc.

1. Oracle options

   1. Use Olivia

      Will require code changes:

      • Custom implementation of rust_dlc::Oracle trait.
      • Modify rust-dlc to support Olivia's attestation scheme.

   2. Use a p2pderivatives oracle instance hosted by us.

   3. Use a dlcspecs-compliant oracle, such as the ones listed by Suredbits.

Create multiple CFDs at once (could)

This might only be needed when we support multiple contract symbols.

Punish publication of revoked DLC channel buffer transaction (should)

• We already left this till much later in ItchySats, hence the should label.
• One downside of Tibo's approach is that we have to handle revocation of the DLC channel separate from the Lightning channel.

Settling a DLC (must)

• #49.
• #50.
• #51.

1. Non-collaboratively (must)

   • This doesn't close the Lightning channel! Only the DLC channel. Theoretically, the vanilla Lightning channel could once again be "upgraded" to one where there is a sibling DLC channel, but the overall pool of funds would be smaller.
   • buffer_transaction, CETs and refund_transaction must work, but this is already done by rust-dlc.
   • split_transaction is the experimental component introduced by Tibo's recent rust-dlc branch. We should verify that it is properly tested and add tests if necessary.

2. Collaboratively (must)

   1. Options

      1. DLC into DLC channel "party" outputs

         • These are spendable after the buffer_transaction's revocation timeout.
         • rust-dlc does not yet support "party" outputs. We would need to extend the library for that.

      2. DLC into Lightning channel "party" outputs

         • Remove the DLC channel output from the split_transaction, moving the coins to the Lightning channel.
         • Essentially this automatically moves funds from the trading wallet to the Lightning wallet when the DLC is settled.
         • Could be needlessly expensive in terms of cryptographic work and communication between coordinator and app, as the split_transaction would need to change, affecting all the other Lightning-related transactions.

We need to collect the feedback we received from the user interviews, interpret and learn from it.
With this learning we need to go back to the prototype so that we know what to implement :)

Note: This ticket is still work in progress because more creative design work is needed to come up with the design specifics. That's why this ticket is an an epic - we may break it into more specific tickets after agreeing on a design.

Problems

• Multiple wallets with multiple (same or similar) actions are hard to understand for the user
• In the current prototype it can be unclear which wallet gets funded when trigging intial funding

MVP Context

Constraints:

1. The Trading wallet does not have a send/received; one can only transfer funds from the Lightning wallet into the trading wallet and from the Trading wallet back into the Lightning wallet
2. The Lightning wallet has send and receive actions
   1. [must] Fund the Lightning wallet from another existing Lightning wallet
   2. [could] The user can fund the on-chain wallet and then transfer funds into the Lightning wallet
3. There is an on-chain Bitcoin wallet that also includes send/receive (on-chain) but it is treated as "second class" citizen and the user is not encouraged to send funds into it. (In the future we can make this a more prominent feature and change this, but in the MVP the on-chain wallet does not get prominence)
   1. Moving funds between the Bitcoin and Lightning wallet and the Bitcoin and Trading wallet is our of scope

Funding needs

1. It needs to be clear to understand for the user that funding the Lightning wallet is the go to action
2. It needs be clear to the user that the Trading wallet is "attached" to the Lightning wallet, i.e. funds are moved out of or into the Lightning wallet from the Trading wallet

Note: #37 may have some influence on this ticket. E.g. a checklist with "initial steps to be done to trade" may help understand the relationship between the Trading and the Lightning wallet.

We want the coordinator to open a channel with the user while having funds on either side of the channel. This can either be done using dual funded channels or using submarine swaps after channel opening.

Note:

• rust-lightning does not currently have the former one.
• The feature of submarine swaps is needed for receiving on-chain payments in-side the channel as well.

This task is about investigating how we can achieve the following scenarios in the most straight forward way without having to extend rust-lightning :)

Scenarios:

• user wants to open a channel with coordinator with funding only on their side. (should be straight forward)
• user wants to open a channel with coordinator with funding on both sides
• user wants to receive payments which are bigger than their in-bound liquidity

This ticket is about investigating and documenting in form of an ADR how we can achieve these scenarios.

These options are also outlined in #34:

1. Route payment all the way to the coordinator first

1. User tries to create invoice.
2. App generates an invoice via the coordinator with a payment preimage that only the app knows.
3. App shares payment hash with coordinator.¹
4. Payer pays the invoice, which eventually reaches the coordinator as a HTLC.
5. Coordinator matches the received HTLC to the one registered by the app.
6. Coordinator opens channel with user, including HTLC with amount minus flat routing fee and liquidity-based routing fee.
7. App claims payment.

2. Open channel between coordinator and user first

1. User tries to create invoice.
2. Coordinator opens channel with user with desired invoice amount as inbound liquidity for user (plus whatever inbound liquidity they would want).
3. Invoice then generated, including route hint for final hop between coordinator and user.

Tasks

We want to:

• Test that option 1 is feasible, as it is the preferred option.
• Write an ADR to explain findings, decision and any other insights.

Create a highlevel architecture overview showing how mobile and coordinator are interacting with each other.

• #36
• #48
• #49
• #55
• #80
• #81
• #82
• #83
• #84
• #85

// edit: 31.01.2023 split this ticket up in multiple smaller ones to address the discussions started in #33 as individual ADRs

We need to model a flow where the user receives funds but does not have inbound liquidity yet.

There are two possible ways:

1. we ask the user upfront how much inbound liquidity he wants and charge him for that, e.g. when opening the channel, we say inbound liquidity costs 1%
2. we tell the user that an incoming payment above his inbound liquidity will always incure a fixed fee, e.g. 1%

Here is a little diagram showing the technical side of this:

sequenceDiagram

participant D1 as "Daniel-10101"
participant T as "10101" 
participant B as "Breez"
participant D2 as "Daniel Breez"

D1 ->> D1: create invoice: 1k sats
D1 ->> D2: send invoice
D2 ->> D2: pay invoice

D2 ->> B: pay
B ->> T: pay
alt channel present and enough inbound liquidity
T ->> D1 : pay
else no channel present
T ->> D1: open channel: 1k sats
Note over T: 10101 opens channel with funding on 10101 side. \nThen pay invoice and funding ends on Daniel-10101 side
T ->> D1: pay: 
end

We had trouble in two user interviews already, where it was unclear what is the exact starting point of the user case.

In my opinion there are two things needed:

1. Be clear that the task is about moving funds from the trading to the stable sats wallet.
2. Wire "Receive" buttons to the "not part of your task button
3. Make sure that there are no "Deposit" buttons in the task. The deposit buttons should only be shown if
   1. In case we want to change this constraint we have to clear that the scenario is about moving funds from the trading wallet into the stable sats wallet!

In our PoC we were not able to open a channel from our coordinator to the user who in on the phone. The was because we could not reliably reach the user on the phone who might be behind NAT.

This ticket is about investigating and documenting in form of an ADR how we can establish such a connection.

2 hints which come to mind:

• mutiny - is running in the browser and has a similar problem, i.e. 2 browser windows cannot directly communicate with each other.
• breez and phoenix - are running on the phone and should have the same problem.

A document which describes what and how we are testing our mobile app.

• Create proper components for the combined balance, transaction history, ...
• Replace the old flow with the new one, where Wallet and Home Screen are combined into one view
• Re-design the FAB to be Send and Receive only

Related tickets needed to complete for plugging the prototype togeher:

• #52
• #53

Note: This ticket is still work in progress because more creative design work is needed to come up with the design specifics. That's why this ticket is an an epic - we may break it into more specific tickets after agreeing on a design.

Problems

• Home screen is overwhelming
• Home screen is not well enough structured
• Home screen contains too many calls to action
• Important calls to actions on the home screen are actually no visible

MVP Context

The MVP scope defines that:

• The user always funds the Lighting wallet (no funding the trading wallet directly)
• The user transfers funds from the Lightning to the Trading wallet to enable trading.

This means that enabling trading is now a three step process (less flexible than before):

1. Fund the Lightning Wallet (from existing Lightning wallet)
2. Move funds from the Lightning to the Trading Wallet
3. Trade

Home Screen Needs

Here is a general overview what we see as "important item", that should have some representation on the home screen:

• [initial setup] Important “Actions”
  • related to security (backup, PIN)
  • Initial funding of wallet(s)
• Some "call to action" for trading
• Position overview of current trades
• Navigation / overview for wallets / balance
• Settings (Preferences for ths user) should be accessible there (not on the screen)
• Scanning should be accessible (can be in the bottom bar - but if we remove it there it has to be available on the home screen)

Careful with information hiding when initially opening the app; the most important action should point to the wallet backup initially. The user should be able to click around, but the go-to action (most present in the home screen, however it is designed) should be to do a wallet backup.

In the past (for itchysats and 10101-poc) we used sqlx which we found more than painful to work with.
This time we want to go with a different implementation, e.g. diesel

The goal should be to support a hosted db so that we can run the coordinator and connect it to e.g. Google's Cloud SQL or Amazon's RDS while at the same time being able to run it locally for dev purposes.

This ticket covers the setup for a database layer for the coordinator.

Pattern: Once the user successfully did an action don't just modify the screen to show that something happened, but add an explicit success dialog that tells the user that:

• The action the user did was successful
• What is going to happen on the screen

Success Screens are needed for:

• Wallet: Fund/Receive
• Wallet: Send/Withdraw
• Trading: Open Position
• Trading Close Position

Examples:

• Wallet Funding/Receive: should be some kind of waiting overlay that automatically closes once the incoming payment is detected or the user closes it
• Opening a position: success, your order has been submitted, your position will be opened once the order was filled (...)
• Closing position: success, you created and order to close your position, the position will be closed once the order was filled

Closing the DLC channel without collaboration requires the publication of certain transactions.

We want to verify that:

• #770
• On-chain DLC can be claimed via CET. (#612 proves this).
• #769
• Claimed DLC funds end up in the right wallets. (#612 proves this).
• The Lightning channel can once again be upgraded to an LN-DLC channel (see this test).

The settings screen can be accessed by clicking on the three dots in the top menu of the Wallet and Trade screen.
There is already a placeholder screen linked to the settings screen.

For the MVP we create a simple combined settings screen for the wallet and the trading.

Solution proposal:
A list view with two sections, one section for the wallet settings, one section for the trade settings. Depending on from which screen we open the settings the respective section is un-collapsed (e.g. if we click settings on the trade screen then the wallet settings are collapsed, the trade settings are un-collapsed when opening the settings screen.)

Note: We don't have to create this behavior in the Figma mock, it's good enough to just show all the settings (both sections un-collapsed) and add a comment.

This will contain our 10101 master node, i.e. a node where every 10101 user connects to.

Target platform should be linux as we intent to run it in a docker container.

Note: #9 should be in the same repository, i.e. in https://github.com/get10101/10101

A document which describes what and how we are testing our mobile app.
E.g. do we need to run a simulator, do we write unit tests for the front end, do we write integration tests, etc.

• Align all the Bitcoin amounts to be in sats! We still have amounts that are in Bitcoin which is super confusing. We noticed a Bitcoin value in the funding flow, but make sure to check the prototype overall.
• After the user traded we display two trades but only one order. This might be confusing. The problem here is that the orders tab content is not scrollable. We can consider enabling that.
• The $ sign of Stable Sats wallet is not aligned with the sats of the other wallets. (note: I aligned that already in the prototype)
• There was some confusion because other wallet deposits are not wired anywhere; we should at least wire them to the Not part of your task placeholder screen so it is clear to the user that these components can be clicked but it's not part of the prototype setup.
• Make sure that the values of our position make more sense. Users do focus on these values and if two screens (immediately after each other) don't align we have unnecessary confusion and the user focuses on the wrong things. Notable in the Buy flow we have to make sure that the values align (it's market order, price aligns, ...); the closing should also be somewhat aligned.

Other notes, might need alignment:

• When the user tried to fund the stable sats wallet, the user tried to use the Stable Sats Wallet's quick actions that one sees when clicking the Stable Sats Wallet tile on the home screen. For the Trading Wallet we wired that into the funding workflow, but for the Spending Wallet we did not.
  Note: If this is not enabled on purpose, because the user should use Move funds between wallets then we should explicitly state that Otherwise we should allow funding from external.
• Make sure it is more clear that the user has to do a Market order. It's nice to show that Limit orders are possible, but it is somewhat unclear that one cannot do them. Maybe good enough to mention this.

This will project will contain the flutter code.

Target platforms should be Android + iOS

Note: #10 should be in the same repository, i.e. in https://github.com/get10101/10101

For now the idea is a checklist, but we can consider moving away from that again.

We started with this in the MVP workflow, by re-adding the decision for selecting the wallet to be funded.
This may require some more beautifying.

Once values are filled in the user does not know what these values stand for.
(And the confirmation screen uses different values, so it's super confusing and one cannot make sense of it.)

Scope:

1. Redesign the tile representing the position in Positions to be more like a list-view item
2. When the user clicks the position he gets a details sheet on the bottom
3. Add the Close Position button to the details sheet as clear action button at the bottom
4. The confirmation swipe remains and should appear right after clicking the button (same location, so the user clicks close and the swipes in the same location to confirm)

Design and wire the send screen

Implementation contingent on #49.

Two properties to be verified:

• Funds correctly awarded to each wallet.
• Can still create another DLC using those funds without going on-chain.

In order to build the best product we want to collect user feedback early using our Figma prototypes.
Below is a list of flows/scenarios we want to build and evaluate in user feedback sessions.

• #2
• #3
• #4

Optional

• Using the "Savings"/"On-chain Wallet"
• Creating an app backup

Note:

Each flow has to be consistent on its own, but should also make sense in context (if we end one flow and another builds on top the state should be aligned as good as possible).
Each clickable element that is not part of the scenario assigned to a flow should be wired in a screen that shows the user that it was unexpected to click there.