Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2018-11-20 Thread Matt Corallo
Not sure if others already realized this, but in thinking about our RBF policy hack from Adelaide a bit more, to allow the carve-out exception of "last tx in a package, which has only one unconfirmed ancestor" to always be available for the "honest party" when broadcasting a commitment

Re: [Lightning-dev] Base AMP

2018-11-20 Thread ZmnSCPxj via Lightning-dev
Good morning Rusty, > And do not play with `amount_to_forward`, as it's an important > signal to the final node that the previous node did not offer less value > for the HTLC than it was supposed to. (You could steal the top bit to > signal partial payment if you really want to). I do not view

Re: [Lightning-dev] Base AMP

2018-11-20 Thread Rusty Russell
René Pickhardt via Lightning-dev writes: > Hey List, > > as this base AMP proposal seems pretty small I just started to write this > up to make a PR for BOLT04 and BOLT11. While doing my write up I realize > that there are smaller things that I would want to verify / double check > and propose

Re: [Lightning-dev] Invoice Address Format

2018-11-20 Thread Rusty Russell
Varunram Ganesh writes: > Now, I am no expert on error encoding formats, but I think that bech32 is > under optimised for invoices (whose lengths are greater than 71). Related to > this, is there a reason why we use hex encoded pubkeys in lightning? Unless > I'm missing something, I think

[Lightning-dev] [PATCH] First draft of option_simplfied_commitment

2018-11-20 Thread Rusty Russell
I'm also starting to implement this, to see what I missed! Original at https://github.com/lightningnetwork/lightning-rfc/pull/513 Pasted here for your reading convenience: - Option is sticky; it set at open time, it stays with channel - I didn't want to have to handle penalty txs on channels

Re: [Lightning-dev] Base AMP

2018-11-20 Thread René Pickhardt via Lightning-dev
Hey List, as this base AMP proposal seems pretty small I just started to write this up to make a PR for BOLT04 and BOLT11. While doing my write up I realize that there are smaller things that I would want to verify / double check and propose with you. ## Verifying: 1.) I understand the receiving

Re: [Lightning-dev] Base AMP

2018-11-20 Thread ZmnSCPxj via Lightning-dev
Good morning Rene, > Hey List, > > as this base AMP proposal seems pretty small I just started to write this up > to make a PR for BOLT04 and BOLT11. While doing my write up I realize that > there are smaller things that I would want to verify / double check and > propose with you. > > ##

[Lightning-dev] Invoice Address Format

2018-11-20 Thread Varunram Ganesh
Hello List, The reason why we use bech32 for invoice addresses and raw hex encoded pubkeys and has long puzzled me. Let's take a sample testnet invoice >>>