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 initiat
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 initiate
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 happens(nonce
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
> thou
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 or
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
> 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 i
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). B
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
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 f
> 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 unit
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 dr
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
13 matches
Mail list logo
