Thanks for proposing this! I think it is absolutely one of the biggest
onboarding/usability challenges for many use cases.
My first thought is that like ZmnSCPxj mentioned, the person offering
liquidity can simply close the channel. So if I'm charging for liquidity,
I'd actually want to charge
Instead of leaving an extra output for CPFP, is it not sufficient to just
sign all inputs with ANYONECANPAY and expect the sender to make an exact
output for the fees input? It would require an extra tx assuming they don't
already have a properly sized UTXO handy (which they may!), but I believe
Hmm, I'm not quite following the situation. What do you mean by "directs
normal traffic"? Since the sender constructs the entire circuit, routing
nodes do not get any discretion over which nodes to forward a payment to,
only whether to forward or fail. What an attacker could do is perform a
loop
why I say it's kind of symmetric to the CLTV value: if the delta is
too low, there's risk of loss of funds, if the delta is too high, someone
might decide to fail the payment instead of taking the delay risk.
On Wed, May 9, 2018 at 10:23 AM, Jim Posen <jim.po...@gmail.com> wrote:
> Thanks
Thanks for the thoughtful responses.
> You missed the vital detail: that you must prove channel closure if you
> can't unpeel the onion further. That *will* hit an unresponsive party
> with a penalty.
Ah, that is a good point. I still find the proposal overall worryingly
complex in terms of
>
> It seems to me that adding an entire new attack vector in order to only
> *mitigate* (not eliminate!) another attack vector is not a good enough
> trade-off. In particular the new attack seems *easier* to perform. The
> current attack where I annoy the other side until it closes has the risk
I believe that anyone attempting a DOS by forcing on-chain settlement can
do it just as easily with asymmetric delays than with symmetric delays.
If my goal is to waste the time-value of your money in a channel, in a
world with symmetric delays, I could just publish the commitment
transaction and
> By extension, perhaps both sides should use the maximum delay either one
> asks for?
>
I'm not sure that is necessary. As long as both parties have to wait the
same amount of time regardless of whether they publish the commitment or
the other side does, that would resolve the issue.
> I don't
for
everyone.
On Thu, Mar 1, 2018 at 4:16 PM, gb <kiw...@yahoo.com> wrote:
> and any thoughts on protections against flood pinging?
>
> On Thu, 2018-03-01 at 09:45 -0500, Jim Posen wrote:
>
>
> > The main benefit is that this should make it quicker to send a
>
I like Christian's proposal of adding a simple announcement cutoff
timestamp with the intention of designing something more sophisticated
given more time.
I prefer the approach of having an optional feature bit signalling that a
`set_gossip_timestamp` message must be sent immediately after
Nice work!
I reread the relevant section in BOLT 4 and it is written in a way to
suggest the quadratic time algorithm. I have opened a PR to update the
recommendation and reference code:
https://github.com/lightningnetwork/lightning-rfc/pull/374.
On Fri, Feb 2, 2018 at 6:20 PM, Conner Fromknecht
11 matches
Mail list logo
