Before funding a cfd contract using a lightning transaction, the taker and the maker need to open a payment channel

Acceptance Criterias

• seed phrase is shown like in the screen shots
• checkbox click should mark the phrase to be backed up (only stored to the state, not to the database yet)

Acceptance Criterias

• Build dedicated widget for the balance.
• Create card for cfd trading navigate to another route. (empty screen)
• Create card for sports betting (disabled)
• Add fund wallet with bitcoin card - navigate to another route. (empty screen)

Add jobs that lint and build the whole app for different platforms.
Otherwise we risk inadvertently breaking the builds.

Upon first start of the app a wallet needs to be generated utilizing the Bip39 standard. This may be implemented using a combination of the bitcoindevkit and the lightningdevkit

Acceptance Criterias

• lightning wallet (on & off chain) is initialized and ready to use (exposed through the flutter_rust_bridge)
• a simple view showing the current balance - demonstrating that the wallet can be accessed from the view.

Send Rust logs to Flutter via stream so that they can be included in the file output (and have unified logging).

see:
https://cjycode.com/flutter_rust_bridge/feature/logging.html

Dependent on #103 and #83.

We need a way to share log files from the TenTenOne App with us. using FLog we can make use of the FLog.exportLogs()

Use tracing and direct all messages to the StreamSink(implemented in #83 ).

We need to be able to fund the on-chain wallet. A screen something like that could be implemented.

Upon the first start of the application, a new bitcoin wallet should be created from with a seed compatible with BIP39.
This should allow us to export the seed words.

Mobile wallet

Goal: Develop a mobile lightning wallet which offers non-custodial financial products based on bitcoin. The first financial product will be CFD trading.

• #9
• #11
• #10
• #7
• #8
• Setup build pipeline

Open Decisions

• What framework should be used for the mobile project? see discussion at #5
• Do we want to build the wallet in typescript (what library to use) or build a native module using neon (https://neon-bindings.com/)? Second option may be hard to cross-compile for all architectures.
• The wallet needs to run a background task which is listening for events from the taker daemon, respectively which is monitoring it's own cfds and triggers an action e.g. if it needs to be rolled over. How should we build that part? headless-js? (https://blog.logrocket.com/run-react-native-background-tasks-headless-js/)

Write up and publish the PPP (Plan, Progress, Problems) as weekly report to https://makers.bolt.fun/project/10101

Example PPPs

• https://makers.bolt.fun/story/ppps-week-1-lightsats--207
• https://makers.bolt.fun/story/ppps-week-1--160

The settle confirmation screen is missing. It is modelled in the wireframes, but was not implemented.

We have a confirmation screen for opening a positions, we should also have one for closing a position.
This gives the user the chance to review the action to be performed.
Confirmation screens are good practice in financial applications.

Like the title suggest, the possibility to withdraw funds from the wallet.

A lowfi set of user interfaces depicting the user journey through the app including the following flows.

• Initialize wallet
• Create payment channel with maker.
• Navigation to the CFD trading app (itchysats)
• Open a CFD trade (funding through the lightning wallet)
• Close a CFD trade

This is the maker part of the cfd trading. see also #82 for the taker part.

https://lightningdevkit.org/tutorials/build_a_node_in_rust/

This should be implemented as a server.

Initial exploration of flutter showed that we have a few unknowns.

Some questions:

• how to communicate with long-running tasks in Rust from Flutter, such as LDK
• where to keep state - singletons (e.g. conquer_once/lazy_static) in Rust, or keep them in Flutter and pass as parameters? (the latter is more library convention). By state I mean: things like the wallet, the db, the seed file etc.
• poll for changes or try to add some pub/sub system

Currently we have not way of configuring the app. Here are a couple of settings I think would make sense on a settings screen.

• Log level
• Network (testnet / mainnet, etc.)
• Electrum endpoint
• Maker endpoint
• View seed phrase
• Share logs with maintainers
• Preferred fiat currency
• Preferred display of bitcoin e.g. all as sats.

Acceptance Criteria

• A wire frame depicting the settings page.

Regardless if on the emulated android device or through wireless debugging on the physical android device. The following error gets printed repeatedly in the logs. The app gets started though.

E/flutter (29452): [ERROR:flutter/runtime/dart_vm_initializer.cc(41)] Unhandled Exception: Invalid argument(s): Failed to load dynamic library 'libten_ten_one.so': dlopen failed: library "libten_ten_one.so" not found
E/flutter (29452): #0      _open (dart:ffi-patch/ffi_dynamic_library_patch.dart:12:43)
E/flutter (29452): #1      new DynamicLibrary.open (dart:ffi-patch/ffi_dynamic_library_patch.dart:23:12)
E/flutter (29452): #2      dylib (package:ten_ten_one/ffi.io.dart:12:26)
E/flutter (29452): #3      dylib (package:ten_ten_one/ffi.io.dart)
E/flutter (29452): #4      api (package:ten_ten_one/ffi.io.dart:13:32)
E/flutter (29452): #5      api (package:ten_ten_one/ffi.io.dart)
E/flutter (29452): #6      _MyAppState._callExampleFfiOne (package:ten_ten_one/main.dart:41:33)
E/flutter (29452): #7      runPeriodically.<anonymous closure> (package:ten_ten_one/off_topic_code.dart:137:74)
E/flutter (29452): #8      _Timer._runTimers (dart:isolate-patch/timer_impl.dart:398:19)
E/flutter (29452): #9      _Timer._handleMessage (dart:isolate-patch/timer_impl.dart:429:5)
E/flutter (29452): #10     _RawReceivePortImpl._handleMessage (dart:isolate-patch/isolate_patch.dart:192:12)
E/flutter (29452): 

A widget which can be seen throughout multiple screens and gets updated if the balance changes.

Something similar to how it looks in the breez app.

Currently the seed is mocked, it should be wired with the seed phrase used to generate the BIP84 wallet.

Acceptance Criteria

• Seed Phrase is fetched from the rust lib

At some point we should think about storing the seed file to the mobile device, but this is not focus of this issue.

Goal

We want to build a wallet which speaks lightning and is able to do DLCs.

Possible approaches

Virtual channels

Probably the most complex solution is to have 2 virtual channels. One speaking lightning, the other one speaking DLCs.
E.g. something like this:

flowchart LR
    A1((Alice))
    B1((Bob))
   

    txf[tx_fund]
    
    txc_outer[tx_commit]
    
    txs[tx_settle]
    
    txcis[tx_commit_itchysats]
    txcln[tx_commit_ln]
    or{or}
    and{and}


    A1 -- fund --> txf
    B1 -- fund --> txf
    txf --> or
    or --> txs
    or --> txc_outer
    txc_outer --> and
    and --> txcis
    and --> txcln
    
    subgraph ItchySats
      txcet_is[tx_cetN]
      txr_is[tx_refund]
      txp_is[tx_punish]
      or_is{or}
      
      txcis --> or_is
      or_is --> txp_is
      or_is --> txcet_is
      or_is --> txr_is
    end
    
    
    subgraph LN
      htlc1((htlc1))
      htlc2((htlc2))
      htlcN((htlcN))
      txp_ln[tx_punish]

      txcln --> txp_ln
      txcln --> htlc1
      txcln --> htlc2
      txcln --> htlcN

    end

Advantages:

• we might be able to use ldk, this needs to be evaluated.
• we might be able to use maia.
• we should be able to receive standard LN payments from anyone in LN.

Disadvantage:

• clearly complex
• channels can only be opened to nodes running the same code because of the custom transaction structure. i.e. you can't open a channel to other LN nodes (LND or CLightning) with this.

Maia speak LN

We could implement the needed bolts into https://github.com/comit-network/maia/

Advantage:

• full control over the code base. We can decide to only implement what we really need
• we should be able to receive standard LN payments from anyone in LN.

Disadvantage:

• complexity
• only compatible with our own nodes, i.e. you can't open channels to other LN nodes (LND, Clightning) with this.

LN speak DLC

We could add the DLC feature to a lightning implementation (e.g. use LDK and extend it). The it's ok to be odd would allow us to add features to our client without breaking compatibility with other LN implementations.

Advantage:

• we can open a channel with other LN nodes
• we speak native lightning out of the box

Disadvantage:

• Complexity
• If we build on LDK we probably will need to fork the library to add what we need which could become a nightmare in pulling in upstream changes.

Fetch Bitcoin and Lightning payment history from the wallet backend and plug it in instead of the mocked data.

This concerns the Dashboard where we have a combined history of Bitcoin and Lightning, and the specific Lightning and Bitcoin wallet screens.

Furthermore this payment history could serve as the basis for the CFD trading overview (which is basically a subset of the Lightning history + some additional CFD specific data).

our current job, based on rust-flutter-bridge workflow is using macos-latest, which has strict quotas, which could lead to the jobs piling up in a queue.
There's no advantage to use it over standard linux container, so use ubuntu-latest instead (which would not cause such queuing )

With #78 we removed the generated code from the git repository and added a quick fix to generate the flutter rust bridge code in every step where needed.

It would be nice (and faster) if we could cache that bit.

• macOS
• Linux
• Windows

This is necessary to depict our Bitcoin hot-wallet. In the long run we might be able to get rid of this and focus on a pure Lightning wallet, but for the current onboarding / offboarding process it is very hard to abstract this way.

Note: It might be good to have either way, this makes the distinction between Lightning and BTC clearer, one could even allow trading using the BTC wallet, but that is not modelled / planned for now.

https://lightningdevkit.org/tutorials/build_a_node_in_rust/

• run ldk node on the phone

Our app is more complex than just a screen and sub-screens. The trading / bet screens are on the same hierarchy level as the wallet screen (siblings rather than child-parent).

With the introduction of go_router in #99 we are able to depict such kind of routing relationships, but without a proper navigation menu we can't navigate between the main screens (i.e. at the moment we are unable to navigate back to the wallet once on the CFD trading screen).

Introduce a proper navigation menu as depicted in the wireframes.

Discussed in #2

it would be great if FLog logs were formatted in a more similar fashion to tracing logs (they're pretty ugly right now), and are the main reason I disabled the same logs on the Flutter side from stdout (it's really hard to read them when they're interleaved).

https://makers.bolt.fun/story/ppps-week-2--219

🚨 Innovation: Is it something we've seen before or does it bring something new and exciting to bitcoin and beyond?

⚡️ Bitcoin Integration & Scalability: Have they used bitcoin/lightning? If so, how many features? How well will this product scale for either local or global adoption?

Setup the initial mobile wallet app.

Fund the CFD contract using the lightning channel

// edited by @bonomat: removed proposal how to solve it as the proposed approach is not yet final.

https://medium.com/flutter-community/logging-in-flutter-a583b3668228

On iPhone SE (3rd gen) we have several screen overflows.

We should arrange the design to be flexible enough to expand on different screens. This usually just requires a decision on what element can expand on the screen.
We can also agree to stick to a specific screen for the tournament to reduce

Screenshots:

Furthermore, our "confirmation" buttons are placed in different locations on different screens which is not a good design practice.

I looked into using FABs everywhere, but it appears that they are not meant to be disabled, see: flutter/flutter#76120
Instead of using FABs we can make use of the SafeArea widget, so that the bottom of the screen area (where we usually place our button) is correctly located according to screensize.

This issue summarizes the goals / features for the legends of lightning tournament.

Release app on desktop and android.

• #128
• #79
• #133
• #30
• #9

The taker gets a full fledged on and off-chain wallet

• This will allow the user to receive and send on-chain and off-chain funds
• The taker runs a full lightning node running on her phone.
• Use electrum (instead of bitcoind) to monitor onchain transactions.
• Taker opens an uni-directional lightning channel with maker with funds provided by the maker.

• #125
• #100
• #102
• #11
• #68
• #113
• #165
• #114
• #132
• #82
• #10
• #139

The maker runs a full lightning node server side.
(would be cool if this could also work eventually on the phone 😉 )

• Simple HTTP apis to fetch offers, propose settlement, etc.

• #89
• #106

Taker can trade a non-perpetual CFD position.

• Only happy case

• #106
• #126
• #87
• #115
• get10101/rust-lightning#2
• #85
• #126