Re: [Lightning-dev] Proposal for Advertising Channel Liquidity

2018-11-06 Thread ZmnSCPxj via Lightning-dev
Good morning Lisa, >Should a node be able to request more liquidity than they put into the channel >on their half? In the case of a vendor who wants inbound capacity, capping the >liquidity request >allowed seems unnecessary. My initial thought is that it would be dangerous to allow the

Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-11-06 Thread ZmnSCPxj via Lightning-dev
Good morning Laolu, >> I worry about doing away with initiator distinction > > Can you re-phrase this sentence? I'm having trouble parsing it, thanks. The initiator of an action is the node which performs the first step in an action. For instance, when opening a channel, the node which

Re: [Lightning-dev] Wireshark plug-in for Lightning Network(BOLT) protocol

2018-11-06 Thread tock203
We implemented the latter scheme. lightning-dissector already supports key rotation. FYI, here's the key log file format lightning-dissector currently implements. https://github.com/nayutaco/lightning-dissector/blob/master/CONTRIBUTING.md#by-dumping-key-log-file Whenever key rotation

Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.

2018-11-06 Thread Pierre
Hi Rusty, > funding_satoshis > > > c-lightning: must be >= 1000 (after reserve subtracted) > Eclair: must be >= 10 > lnd: any > > SUGGESTION: At 253 satoshi/kSipa, and dust at 546, 1000 is too low to be > sane (one output would always be dust). Eclair seems pessimistic >

[Lightning-dev] Proposal for Advertising Channel Liquidity

2018-11-06 Thread lisa neigut
Problem Currently it’s difficult to reliably source inbound capacity for your node. This is incredibly problematic for vendors and nodes hoping to setup shop as a route facilitator. Most solutions at the moment require an element of out of band negotiation in

Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-11-06 Thread Christian Decker
Olaoluwa Osuntokun writes: >> However personally I do not really see the need to create multiple > channels >> to a single peer, or increase the capacity with a specific peer (via > splice >> or dual-funding). As Christian says in the other mail, this > consideration, >> is that it becomes less

Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.

2018-11-06 Thread Gert-Jaap Glasbergen
> On 7 Nov 2018, at 12:01, Anthony Towns wrote: > > I don't think it quite makes sense either fwiw. Glad it’s not just me :) > What's enforcable on chain will vary though -- as fees rise, even if the > network will still relay your 546 satoshi output, it may no longer be > economical to claim

Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.

2018-11-06 Thread Anthony Towns
On Tue, Nov 06, 2018 at 10:22:56PM +, Gert-Jaap Glasbergen wrote: > > On 6 Nov 2018, at 14:10, Christian Decker > > wrote: > > It should be pointed out here that the dust rules actually prevent us > > from creating an output that is smaller than the dust limit (546 > > satoshis on Bitcoin).

Re: [Lightning-dev] Splicing Proposal: Feedback please!

2018-11-06 Thread Rusty Russell
Olaoluwa Osuntokun writes: >> Mainly limitations of our descriptor language, TBH. > > I don't follow...so it's a size issue? Or wanting to avoid "repeated" > fields? Not that smart: tools/extract-formats.py extracts descriptions from the spec for each message. It currently requires constants in

Re: [Lightning-dev] Improving payment UX with low-latency route probing

2018-11-06 Thread Pierre
Hi Laolu and Fabrice, > I think HORNET would address this rather nicely! HORNET sounds awesome, but does it really address the specific issue Fabrice is describing though? IIUC, HORNET would operate at a lower layer and it could be possible to have a valid circuit and still indefinitely waiting

Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.

2018-11-06 Thread Gert-Jaap Glasbergen
> On 6 Nov 2018, at 14:10, Christian Decker wrote: > > It should be pointed out here that the dust rules actually prevent us > from creating an output that is smaller than the dust limit (546 > satoshis on Bitcoin). By the same logic we would be forced to treat the > dust limit as our atomic

Re: [Lightning-dev] RFC: simplifications and suggestions on open/accept limits.

2018-11-06 Thread Christian Decker
Gert-Jaap Glasbergen writes: > Op 1 nov. 2018 om 03:38 heeft Rusty Russell > mailto:ru...@rustcorp.com.au>> het volgende geschreven: >> I believe this would render you inoperable in practice; fees are >> frequently sub-satoshi, so you would fail everything. The entire >> network would have to

Re: [Lightning-dev] Improving payment UX with low-latency route probing

2018-11-06 Thread Olaoluwa Osuntokun
Hi Fabrice, I think HORNET would address this rather nicely! During the set up phase (which uses Sphinx), the sender is able to get a sense of if the route is actually "lively" or not, as the circuit can't be finalized if all the nodes aren't available. Additionally, during the set up phase, the