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.
On Thursday, June 29, 2017 at 2:21:07 PM UTC+5:30, 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.
