Re: [Lightning-dev] Wumbological local AND global features

2018-11-15 Thread Olaoluwa Osuntokun
I realized the other day that the wumbo bit should also likely encompass wumbo payments. What good is a wumbo channel that doesn't also allow wumbo payments? Naturally if the bit is signalled globally, then this should also signal the willingness of the node to forward larger payments up to their

Re: [Lightning-dev] Packet switching via intermediary rendezvous node

2018-11-15 Thread Olaoluwa Osuntokun
> If I'm not mistaken it'll not be possible for us to have spontaneous > ephemeral key switches while forwarding a payment If this _was_ possible, then it seems that it would allow nodes to create unbounded path lengths (looks to other nodes as a normal packet), possibly by controlling multiple

Re: [Lightning-dev] Strawman BOLT11 static "offer" format using probes.

2018-11-15 Thread ZmnSCPxj via Lightning-dev
Good morning Rusty, > > > I apologize that this wasn't fleshed out before the summit, but I > > > overestimated the power of Scriptless Scripts so had mentally deferred > > > this. > > > > My understanding is that SS is as powerful as we thought, at least for some > > of the applications we were

Re: [Lightning-dev] Base AMP

2018-11-15 Thread Christian Decker
I'm not sure this is an improvement at all over just allowing a single merge-point, i.e., the destination. You see as long as we don't attempt intermediate merges the routes are independent and failures of one HTLC do not impact any other parts. Take for example the network below: /

Re: [Lightning-dev] type,len,value standard

2018-11-15 Thread Rusty Russell
Conner Fromknecht writes: > Hi ZmnSCPxj, > > Thanks for writing this up! I had started an email, but you beat me to it :) > >> 1. For a sequence of `type,len,value`, each `type` must be unique. -- >> accepted. > > To add to this, it seemed that there was some agreement that repeated fields >

Re: [Lightning-dev] Strawman BOLT11 static "offer" format using probes.

2018-11-15 Thread Rusty Russell
ZmnSCPxj writes: >> I apologize that this wasn't fleshed out before the summit, but I >> overestimated the power of Scriptless Scripts so had mentally deferred >> this. > > My understanding is that SS *is* as powerful as we thought, at least for some > of the applications we were hoping to use

Re: [Lightning-dev] type,len,value standard

2018-11-15 Thread Conner Fromknecht
Hi ZmnSCPxj, Precisely, something like that is what I had in mind. Since the max message size is 65KB, one option could be to only allow the varint to be max 2 bytes where: - if the 8th bit is not set, the lowest 7 bits of the first bytes translate to 0 - 127 - if the 8th bit is set, this

Re: [Lightning-dev] Base AMP

2018-11-15 Thread ZmnSCPxj via Lightning-dev
Good morning Christian, The improvement is in a reduction in `fee_base_msat` in the C->D path. If C is the merge point, then the C->D `fee_base_msat` is only paid once, not twice. In effect, A is rationally choosing between a lower fee and better payment reliability. Granted, current

Re: [Lightning-dev] Strawman BOLT11 static "offer" format using probes.

2018-11-15 Thread ZmnSCPxj via Lightning-dev
Good morning Rusty, > I want to propose a method of having reusable BOLT11 "offers" which > provide almost-spontaneous payments as well as not requiring generating > a BOLT11 invoice for each potential sale. Suggest making a new BOLT document. This would be basically a new BOLT for how to

Re: [Lightning-dev] Forwarding hints in channel update messages

2018-11-15 Thread Joost Jager
On Thu, Nov 15, 2018 at 1:53 AM Rusty Russell wrote: > The decision was made to allow additional channel_update in the error > reply: > > DECISION: document that scid is not binding, allow extra > channel_updates in errors for “upselling”. > Yes, I read this. What exactly is

Re: [Lightning-dev] type,len,value standard

2018-11-15 Thread ZmnSCPxj via Lightning-dev
Good morning Conner et al, > > > 5. `len` - one byte or two? I believe we tend to use two bytes for > > > various > > > lengths. > > > > > > > Maybe varint? One byte is not enough for all lengths, but two seems > > excessive > > for uint8 or even uint32. > > Given that messages are

Re: [Lightning-dev] Trustless Watchtowers

2018-11-15 Thread ZmnSCPxj via Lightning-dev
Good morning Conner, > > > > > From my bare knowledge of go, it seems data structures and messages so > > > far, > > > without actual logic, but please inform me if I am incorrect. > > > > Much of the server side has been implemented, which accepts encrypted blobs > > from > > watchtower