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
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 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).
> 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
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
We implemented the latter scheme. lightning-dissector already supports key
FYI, here's the key log file format lightning-dissector currently
Whenever key rotation
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
> 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
> 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
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,
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
Mail list logo