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
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
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
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
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
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
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.
>
> ##
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
>>>