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. On 06/29/2017 10:51 AM, 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 > <mailto:bitcoinj+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout. -- 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.
