Challenges June 2020
Projects with Challenges
This is the list of Lightning Network related projects that registered for this HackSprint (please contact @rootzoll on twitter to add your project):
Github issues with label "hackathon": https://github.com/rootzoll/raspiblitz/issues?q=is%3Aissue+is%3Aopen+label%3Ahackathon
Video helping you to get started with RaspiBlitz development: https://youtu.be/qTHDkFppsz0
Chatroom to get started: https://mm.fulmo.org/fulmo/channels/raspiblitz
frennkie build for the last hacksprint https://github.com/frennkie/django-ip2tor and its now integrated into the RaspiBlitz v1.6RC1 to test out. So this challange is for people that have a RaspiBlitz to play with and like to test the IP2Tor-Tunnel service and help with feedback.
Chatroom to get started: https://mm.fulmo.org/fulmo/channels/x-tor2ip-tunnelservice
Wiki Lightning Spam Protection
Chatroom to get started: https://mm.fulmo.org/fulmo/channels/media-wiki-spam-protection
Full node interface for standard banking software via FinTS
Merchants accepting Bitcoin (over Lightning) need an easy way to integrate transactions into their existing bookkeeping software. Like you can connect your bank account to your bookkeeping software by the FinTS it would be great of you can connect your Lightning Node (running on a RaspiBlitz) to that software and manage your Bitcoin Holdings as a "Foreign Currency Account".
The GitHub-Issue with details: https://github.com/rootzoll/raspiblitz/issues/1186
There is a 0.03 BTC bounty to create a small server software (running on a lightning node) that implements a subset of the FinTS standard to connect and manage your Lightning transactions with a FinTS supporting bookkeeping software.
Quickening - Room77 Point of Sale
Github issues starting with "Room77" https://github.com/arcbtc/M5StackSats/issues
Chatroom to get started: https://mm.fulmo.org/fulmo/channels/x-pos-room77-quickening
Chatroom to get started: https://mm.fulmo.org/fulmo/channels/x-lnbits
In a push to get lnbits new update out and extend its functionality, x3 0.03btc bounties are available for anyone developing extensions. If you're interested in making an extension, pop into the stream for a chat. If the community likes the idea, you can make it and on completion get one of the bounties!
see video: https://www.youtube.com/watch?v=xnHz6NbTgZg
Need more ideas?
Looking for yet another idea to build a small LApp? Check out Ideas for LApps!
Adding your Project
Feel free to add a challenge yourself! Ask Jeff or Rootzoll on the Mattermost for the password to edit the Wiki-Page. If you have a GitHub Repo best practice is to put the label "hackathon" (yellow) next to issues you like people to join/help for the weekend. If you added a challenge please also get in touch on Mattermost for more information and collaboration.
Projects from last Hacksprint (maybe joining again)
Chatroom to get started: https://mm.fulmo.org/fulmo/channels/x-keysendsendmany
Develop a C# LNURL-AUTH library which can integrate with .NET (MVC) websites.
Chatroom to get started: https://mm.fulmo.org/fulmo/channels/x-zapread
Github issues with label "hackathon": github.com/21isenough/LightningATM (Python)
Chatroom to get started: https://mm.fulmo.org/fulmo/channels/x-lightningatm
This is the new name for the cheapnode project: Building the cheapest possible bitcoin fullnode (+lightning and other services) on old Android phones.
Help wanted on Github issues with label "hacksprint"
Chatroom to get started: https://mm.fulmo.org/fulmo/channels/x-weenode
Rust Lightning network node
Another LN node? Why we need it?
The problem with the existing Lightning node implementations is their very limited extensibility for such things as:
- future LN upgrades (channel factories, pay-to-ec-point, taproot),
- protocols on top of LN (layer 3), like DLCs on LN or proposed Lightspeed payments, which require modification on the structure of the commitment transaction.
Last time we started building new rust LN node based on LNP/BP library — and this time we will continue the challenge! We will work on further node development; for more details you can refer our project backlog and todo issues here: https://github.com/LNP-BP/lnp-node/projects/1
In brief, we will
- update to use the latest version of rust-lightning, that had migrated on new rust-bitcoin type system
- update the code to use the lates version of rust-lnpbp library
- improve multi-thread architecture, in particular message bus with ZMQ
- complete BOLT-1 implementation
- (optionally) implement gossip protocol
Chatroom to get started: https://mm.fulmo.org/fulmo/channels/x-rust-ln-node
1. The node was updated to use the most recent version of rust-lightning and LNP/BP library: https://github.com/LNP-BP/lnp-node/commit/5d6fc3d1c85ca35bbcda0bec59b27c641fd07994
2. We decided to split input and output parts of the stream into separate threads within peer module of wire connection daemon; however it turned out to be not possible to implement due to the current rust-lightning and rust-lnpbp architectures. In order to fix this:
- we have adopted PR from rust-lightning that modularizes peer components https://github.com/LNP-BP/rust-lightning/commit/d88c59c48da986b1eda6a19334e64494b31958d4
- also we proposed the required changes to it: https://github.com/rust-bitcoin/rust-lightning/pull/494#pullrequestreview-408763344
- made Connection and Peer objects splittable: https://github.com/LNP-BP/rust-lnpbp/commit/92fa54f5a45d3f91e78f39bf67a839fce231f20d , https://github.com/LNP-BP/rust-lnpbp/commit/fe01f5401f96596520f67e7ff4ec665a9855b7c3
RTL (Ride The Lightning)
Github issues with label 'hackathon': https://github.com/Ride-The-Lightning/RTL/issues?q=is%3Aissue+is%3Aopen+label%3Ahackathon
Chatroom to get started: https://mm.fulmo.org/fulmo/channels/x-rtl-ride-the-lightning
User:Cdecker is available on Mattermost for mentoring of c-lightning projects. Feel free to propose your own ideas, and we'll help you design and implement them :-)
Some ideas for projects / challenges:
- Hardware wallet integration: c-lightning has supported external funding via the `fundchannel_start` and `fundchannel_complete` RPC methods for quite some time, in addition the `close_to` parameter allows you to specify where funds should be sent once the channel closes. These can be combined to have all on-chain funds sourced from a hardware wallet and, after they were borrowed to operate a channel, they can be returned to the hardware wallet. The idea here is to write a plugin that interacts with the hardware wallet to fund channels, so funds are only temporarily controlled by c-lightning.
- `hsm_secret` generation from a seed-phrase: c-lightning will securely generate a random seed when first starting a new node. Given the lack of functional backup, and the seed not being sufficient to restore all the state, c-lightning has so not included any seed-phrase to restore the seed. However due to recent improvements both in backups and replicated DB backends, it would be great to also safely store the `hsm_secret` using existing tooling, such as paper backups, encrypted BIP39 seed-phrases, or even steel backups. Goal of this challenge is the creation of a launcher or plugin that takes a seed-phrase and generates the associated `hsm_secret` file.
- Trampoline Proof-of-concept: Trampoline routing is a recent proposal to outsource some aspects of route-finding to another node in the neighborhood of the sending node. This is useful for nodes that may be unable to sync the network topology through gossip, or do not have time to sync before they need to send out a payment, e.g., mobile nodes. Using c-lightning's ability to implement custom protocol extensions (`custommsg`) and the ability to create routing onions with arbitrary payloads, you can implement a fast gossiping extension with which nodes announce their ability to route on behalf of others, and the sender to encapsulate the instructions for a trampoline node (where to go and how much to send).
- Networked RPC interface: c-lightning is purposefully not exposing its JSON-RPC over the network, in order not to mandate a specific method of interaction. Plugins can take care of exposing the API in a variety of ways (grpc, JSON-RPC, REST, ...) and they can also be used to enforce arbitrary access policies using the `rpc_command` hook. These two aspects can be handled independently, i.e., one plugin exposes the API over some transport while another plugin enforces the authentication and authorization required to access the API. This in turn allows to mix and match arbitrary networked API endpoints and authentication mechanisms. Goal of this challenge is to come up with a generic way to have one plugin expose the API, and pass along any authentication information that was submitted with the request, so another plugin can enforce access policies.
- Backup plugin: https://github.com/lightningd/plugins/tree/master/backup Currently it supports only backup to the local file. There are several rooms for improvement, contact User:mrostecki if interested.
- "partial file" backend - saving each database change/transaction to a separate file, which will be helpful for ideas below
- PGP backend - based on the "partial file" plugin, which encrypts each file
- Dropbox, Google Drive backends - uploading backups to Dropbox and Google Drive, based on "partial file" backend (to not upload a huge file every time), with optional usage of PGP
Executing a DLC (discreet log contract) on Rust Lightning
A discreet log contract is a protocol that allows for the use of oracles in bitcoin. They have been designed such that they can be lifted off of the bitcoin protocol into the Lightning Network.
The current discreet log contract spec is available here: https://github.com/discreetlogcontracts/dlcspecs
Here is the github issue describing the work we are trying to accomplish this weekend to execute a DLC on the Lightning Network (using Rust Lightning):
Please join us in this chatroom: https://mm.fulmo.org/fulmo/channels/rust-ln-dlc
JIT Routing / Sharing balance information
Recent - unpublished / work in progress - research that i am conducting suggests that JIT routing is indeed superior to our current path finding mechanism of probing channels until a path is found as JIT Routing
- has on average a higher success rate
- invokes on average less network communication messages to be sent
- on average leaks less information of channel balances of the network to the sender / participating nodes
- seems to prevent channel probing attacks (c.f: https://arxiv.org/abs/2004.00333 )
Previous research (c.f.: https://arxiv.org/abs/1912.09555) suggests that even without JIT rebalancing if the channel rebalancing is used proactively and opportunistically by nodes the overall payment success rates and routable amounts increase.
Thus on the Lightning Hacksprint we want to start working on a proof of concept implementation of JIT - routing. This effort has two parts:
- a communication protocol for nodes to share balance information with neighbors
- a modified transport layer for fee free rebalancing.
This weekend we will focus mainly on the communication protocol for sharing balance information with peers as an extension of BOLT7 as this would be needed in the JIT case and the proactive rebalancing case. If time permits we shall also look at the second goal to achieve fee free rebalancing.
We will write a spec for new gossip messages and provide a proof of concept as a c-lightning plugin. If time pemits we also invoke the rebalancing with fees during forwarding of HTLCs - which later can be exchanged with the fee free version.
Chatroom to get started: https://mm.fulmo.org/fulmo/channels/x-jit-routing