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: > > 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
