Hi everyone, currently I work on a Lightning network implementation which is intended to be used on lite clients such as mobile phones, a repo can be found here: https://github.com/btcontract/lnwallet and also recently I've made a demo if anyone is interested: https://www.youtube.com/watch?v=yNFfUfyL2xE
My goals are: - build a core Lightning library which is not tied to any specific wallet or platform and can be reused, related code can be found here: https://github.com/btcontract/lnwallet/tree/master/app/src/main/java/com/lightning/wallet/ln, it's a work in progress and a modification of https://github.com/ACINQ/eclair project where I basically dumb things down (by not using an Akka actor framework which may be too heavy for phones, not assuming a locally accessible Core node API is available, not relaying third party payments for now and so on). It's coming along nicely and I'm confident it will reach a production ready state sooner rather than later. - build an end-user mobile Bitcoin/Lightning wallet on top of an aforementioned Lightning library (for Lightning part) and bitcoinj (for Bitcoin part). This seems like a very convinient and natural solution since users will be able to at once fund Lightning payment channels right from their Bitcoin wallet and also fall back to Bitcoin payments if Lightning is not available for some reason. And this is where some bitcoinj-specific help is really needed. Two things are required for bitcoinj to power a mobile Lightning wallet: segwit support and ability to create segwit outputs. Thanks to Jean-Pierre Rupp's work at https://github.com/bitcoinj/bitcoinj/pull/1334 segwit support is already here, I use his segwit-enabled modification to create a P2WSH output (as required by Lightning funding transaction for a payment channel) and it does work great, as can be seen on a demo video. Sadly, this alone is not enough as not only a funding tx should have a P2WSH output but also all of it's inputs must come from segwit outputs. This is a problem because currently bitcoinj uses base58 addresses which produce non-segwit outputs. A funding tx can be created using such non-segwit outputs but it can be malleated so payment channel can't be established in a trustless manner, basically it's a show stopper. The way I see it, there are two options of getting over this, one requires no big changes to bitcoinj beyond what is already done but is quite horrible from UX point of view, the other one requires some deep changes in bitcoinj: Option 1: instead of creating a funding tx directly, we create an intermediary non-segwit -> P2WPKH tx, then we use it to P2WPKH -> P2WSH (payment channel output). Pros are: no changes to bitcoinj. Cons are: doubled fees, doubled confirmation waiting time, implementation complexities (sending two txs is not atomic, things can happen in the middle). Option 2: add bech32 support to bitcoinj and change it to generate bech32 addresses instead of base58 addresses in order to get native segwit outputs. Pros are: Lightning support out of the box, fee discounts for native segwit txs. Cons are: probably a lot of work and testing, a breaking change (?) which perhaps should live in a separate branch, probably something else I haven't thought of. Despite implementation complexities associated with the sencond option I really like it much more since the first one essentially makes users handle those complexities and I'm not sure they would want to do that, plus sooner or later bech32 support and address generation will have to be done anyway. I'm not sure if I can handle all this myself since my knowledge of bitcoinj if fairly limited and I spend most of my free time working on Lightning but I'm definitely ready to help with programming work, especially if the whole process could be split into more or less clear tasks. Please let me know what you think of all this. -- You received this message because you are subscribed to the Google Groups "bitcoinj" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoinj+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
