nel opening.
> Any idea about the rationale for one-sided channel funding?
It is just simpler for v1.0, but there already is a PR [1] for dual
funding in the works.
Cheers
Pierre
[1] https://github.com/lightningnetwork/lightning-rfc/pull/184
___
Lig
to
do it trustlessly would be for the funder to attach the actual
deprecated funding tx (not necessarily signed, but still could be big)
to the `funding_cancelled` message, then the fundee would be able to
verify that its inputs have indeed been spent by the overriding tx.
Cheers,
(at this
point its main output is zero anyway).
An appropriate choice of channel parameters (`mainly
max_htlc_value_in_flight_msat`, `channel_reserve_satoshis`,
`max_accepted_htlcs`) could probably reduce the probability of this
happening.
Hope that helps,
Pierre
[1]
https://github.com
h less
accurate/partial/out of date information.
At least this is what we are seeing on the current mainnet. Routing
table sync is hard on mobile clients, and I think that it makes sense
that receivers "help" senders, after all incentives are aligned.
:-/ Will eat my own dog
food asap!
Cheers,
Pierre
[1] https://github.com/lightningnetwork/lnd/issues/2045#issuecomment-429561637
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
larly if we use things like
option_anyone_can_wumbo (again referring to ZmnSCPxj's post).
Cheers,
Pierre
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
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
>
Ha! I actually came up with the idea two months ago (but you beat me
to it on the implementation so we're even :-)
https://github.com/ACINQ/eclair-wallet/issues/101#issuecomment-408619207
Le jeu. 20 sept. 2018 à 04:12, Rusty Russell a écrit :
>
> Hi all,
>
> I'm considering a change to
d only need to know a smallish
neighborhood) and on the cpu side (intermediate nodes would run the
actual route computation).
As Christian pointed out, one downside is that fee computation would
have to be pessimistic (he also came up with the name trampoline!).
Cheers,
Pierre-Marie
[1]
htt
aly create overlapping routes. So we can't simply use the
payment_hash as we currently do, we would have to use something a bit
more elaborate. (maybe private keys?)
Cheers,
Pierre
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
ht
Hello Ugam,
The HTLC-Timeout transaction
<https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactions.md#htlc-timeout-and-htlc-success-transactions>
is timelocked (with locktime=cltv_expiry).
Cheers,
Pierre
___
Lightning-dev m
Hi Rusty,
How would bruteforcing on the CSV delay be different from a BIP32
wallet with look ahead keys? Especially given that we could try with
most probable values first.
Cheers,
Pierre
___
Lightning-dev mailing list
Lightning-dev
> > How would bruteforcing on the CSV delay be different from a BIP32
> > wallet with look ahead keys? Especially given that we could try with
> > most probable values first.
>
> It's a big multiplier, given that CSV can be specified by the
> counterparty. If you accept up to 1024 and offer 144,
> Well one of 6, 36, 144, 432 or 1008 is probably more than enough choice.
Indeed, that seems entirely reasonable.
> Most of the time, local commitments are not in play. But if your node
> drops out, remote commitments definitely will be.
That's true, although in my experience, the refund
> The high-level idea would be that the sender must solve a small PoW puzzle
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Hi Rusty,
That seems reasonable.
Cheers,
Pierre
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
mes our node is behind eclair master branch, but it's always
up-to-date for critical commits and releases. So we eat our own dog food
and will experience force closes before our users do.
Pierre
___
Lightning-dev mailing list
Lightning-
that helps,
Pierre
[1] https://github.com/ACINQ/eclair/blob/master/docs/Cluster.md
[2] https://github.com/ACINQ/eclair/pull/1584
Le jeu. 1 sept. 2022 à 19:56, Alex Akselrod via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> a écrit :
> At NYDIG, we're considering ways to harden la
that helps,
Pierre
[1] https://github.com/ACINQ/eclair/blob/master/docs/Cluster.md
[2] https://github.com/ACINQ/eclair/pull/1584
Le jeu. 1 sept. 2022 à 19:56, Alex Akselrod via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> a écrit :
> At NYDIG, we're considering ways to harden la
19 matches
Mail list logo
