OK, I see what you are saying. You are effectively suggesting pipelining
the broadcasts of the update transactions. I think this introduces a
problem that a node in the circuit that withholds the preimage for too long
can force all upstream channels to be closed, at only the expense of their
one up
I'm still not following why this doesn't accumulate.
In the example route, let's look at it from the point of view of C. C sees
the following regardless of whether D or E or someone behind E is the last
hop in the route:
B -> HTLC(expire = X + delta) -> C -> HTLC(expire = X) -> D
So D is not req
Russell O'Connor writes:
> At the risk of bikeshedding, shouldn't NOINPUT also zero out the
> hashSequence so that its behaviour is consistent with ANYONECANPAY?
Good catch, must've missed that somehow. I'll amend the BIP accordingly.
___
bitcoin-dev ma
Jim Posen writes:
> I'm still not following why this doesn't accumulate.
>
> In the example route, let's look at it from the point of view of C. C sees
> the following regardless of whether D or E or someone behind E is the last
> hop in the route:
>
> B -> HTLC(expire = X + delta) -> C -> HTLC(ex
At the risk of bikeshedding, shouldn't NOINPUT also zero out the
hashSequence so that its behaviour is consistent with ANYONECANPAY?
On Mon, Apr 30, 2018 at 12:29 PM, Christian Decker via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi all,
>
> I'd like to pick up the discussion
Jim Posen writes:
> Can you explain why a fixed offset along the whole circuit is enough to
> ensure safely as opposed to an increased delta at each hop?
Sure. Let's assume we have chosen a path `A->B->C->D->E`. For simplicity
let's assume they all have a CLTV delta of 144 blocks (lnd's default
s
Can you explain why a fixed offset along the whole circuit is enough to
ensure safely as opposed to an increased delta at each hop?
On Tue, May 1, 2018, 5:05 AM Christian Decker
wrote:
> Jim Posen writes:
> > If my understanding is correct though, this construction would
> > significantly incre
ZmnSCPxj writes:
> Good morning Christian,
>
> This is very interesting indeed!
>
> I have started skimming through the paper.
>
> I am uncertain if the below text is correct?
>
>> Throughout this paper we will use the terms *input script* to refer to
>> `witnessProgram` and `scriptPubKey`, and *
Jim Posen writes:
> If my understanding is correct though, this construction would
> significantly increase the safe CLTV delta requirements because HTLCs
> cannot be timed out immediately on the settlement transaction. Consider a
> case where node B receives an HTLC from A and forwards to C. If t
Good morning Christian,
This is very interesting indeed!
I have started skimming through the paper.
I am uncertain if the below text is correct?
> Throughout this paper we will use the terms *input script* to refer to
> `witnessProgram` and `scriptPubKey`, and *output script* to refer to the
Good morning Jim,
> If my understanding is correct though, this construction would significantly
> increase the safe CLTV delta requirements because HTLCs cannot be timed out
> immediately on the settlement transaction. Consider a case where node B
> receives an HTLC from A and forwards to C. I
11 matches
Mail list logo
