Re: bitcoinj and Lightning network
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 >
Re: bitcoinj and Lightning network
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.
bitcoinj and Lightning network
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.
