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