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
>allowed seems unnecessary.
My initial thought is that it would be dangerous to allow the
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
For instance, when opening a channel, the node which
We implemented the latter scheme. lightning-dissector already supports key
FYI, here's the key log file format lightning-dissector currently
Whenever key rotation
> 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
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
Olaoluwa Osuntokun writes:
>> However personally I do not really see the need to create multiple
>> to a single peer, or increase the capacity with a specific peer (via
>> or dual-funding). As Christian says in the other mail, this
>> is that it becomes less
> 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
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).
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"
Not that smart: tools/extract-formats.py extracts descriptions from the
spec for each message. It currently requires constants in
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
> 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
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
I think HORNET would address this rather nicely!
During the set up phase (which uses Sphinx), the sender is able to get a
of if the route is actually "lively" or not, as the circuit can't be
if all the nodes aren't available. Additionally, during the set up phase,
Mail list logo