bitcoinj and Lightning network

[Anton]

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.

[Wei Hsu]

Hi Anton, thanks for taking the lead on LN for bitcoinj. As a consumer of the library, I would much prefer Option 2, happy to help test if needed.

[Andreas Schildbach]

That's great news, and many thanks for your demonstration!

I'm pretty confident that if segwit activates, sooner or later bitcoinj
will by default create wallets with segwit addresses/outputs only. Old
wallets will either be migrated (to be decided: on demand, or forcibly),
or old wallets will simply not be able to use the lightning network
(unless you're willing to implement your option 1 just for that case).

We have to decide on an extension to the BIP32 wallet layout though;
guess I'll start a thread about that soon.

tl;dr: I'm in favor of option 2.


I'm interested in how people on this mailing list think about the Scala
language choice you've taken for your work.

> --
> 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+u...@googlegroups.com
> <mailto:bitcoinj+u...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

[v e]

Thanks and great work Anton. Please let us know as soon as production ready. I am happy to test it out.

On Thursday, June 29, 2017 at 1:51:07 AM UTC-7, Anton wrote:

[Neeraj Nagi]

Anton,

        We are a team trying to implement lightning-rfc. Current we are stuck with the idea of using a whole node the way lnd/c-lightning is doing. We want to take the same approach of bitcoinj thin client, could you guide us about any fork of bitcoinj which is supporting segwit completely not. BTW did you finished (2) proposal in your original post, we can use it as it is. Waiting for your guidance.