Good morning Subhra,
> Hello ZmnSCPxj,
> Thanks for the clarification. So is there any way to check in the
> script whether block height reported is same as the current block height?
> Like OP_CHECKLOCKTIMEVERIFY against the nLockTime field indirectly verifies
> whether the desired block
Hello ZmnSCPxj,
Thanks for the clarification. So is there any way to check in the
script whether block height reported is same as the current block height?
Like OP_CHECKLOCKTIMEVERIFY against the nLockTime field indirectly verifies
whether the desired block height or block time has been
Good morning Subhra,
> " C cannot unlock until 144 blocks, so D can delay its response for up to 143
> blocks without any effect on its channels, this is *exactly* the griefing
> attack."- Is there any way to account for the amount of time elapsed in the
> redeem script so that when D goes on
" C cannot unlock until 144 blocks, so D can delay its response for up to
143 blocks without any effect on its channels, this is *exactly* the
griefing attack."- Is there any way to account for the amount of time
elapsed in the redeem script so that when D goes on chain just before
elapse of the
Ok got it. Sorry I missed out the points stated by you.
On Mon, Apr 13, 2020 at 9:13 AM ZmnSCPxj wrote:
> Good morning Subhra,
>
>
> > Ok. But this is a worse situation where C pays money to D but bound to
> keep its resource locked for a longer duration, unlike D not responding and
> C being
Good morning Subhra,
> Ok. But this is a worse situation where C pays money to D but bound to keep
> its resource locked for a longer duration, unlike D not responding and C
> being able to unlock after the elapse of lock time.
It is exactly the griefing attack scenario: it is the lock time
Hello,
So based on what you have stated as possible scenario of griefing
attack, does delay in providing the preimage also counted as a form of
griefing in htlc? Like given the path A->B->C->D, what if C and D has a
lock time of 144 blocks and D responds after 142 block time elapses,
Good morning Nadav, and list,
Thinking even further:
* It is trivially cheap for E to start up new nodes F and G and start up
channels FA and GC.
* It then becomes possible for E to lock up funds of B via F->A->B->C->G and
G->C->B->A->F.
* Even closure of FA and GC does not affect EA and EB.
Hi ZmnSCPxj,
This is a rework of the old unwrap-the-onion proposal, with
some important bits missing.
> Secondly, C needs to prove that the channel it is willing to close involves
> the payment attempt, and is not some other channel closure that it is
> attempting to use to fulfill its
Good morning Dave,
> > Ah, right, E knows the revocation for the unilateral close of EE,
> > because it is a self-channel, sigh. And by this revocation clause it
> > can claim the money immediately and put it into a channel as well.
>
> If it's a self channel, E can also just RBF replace the
On Fri, Apr 03, 2020 at 02:51:15AM +, ZmnSCPxj via Lightning-dev wrote:
> Ah, right, E knows the revocation for the unilateral close of EE,
> because it is a self-channel, sigh. And by this revocation clause it
> can claim the money immediately and put it into a channel as well.
If it's a
Good morning Nadav,
> I could be missing something, but it seems to me like the proposal to close
> channels after a soft timeout unless non-cooperation can be proven upstream
> adds a cost to the attacker of two on-chain transactions, which they can
> immediately revoke (as they know both
Good morning ZmnSCPxj,
> The consideration is that much of the cost of a channel is with the setup
and teardown --- E could always just reopen the CE channel again later.
> Thus, the cost that E bears in setting up EE and tearing down EE would be
still similar to the cost of losing CE and
Good morning Nadav,
> Love the idea! I have a couple questions though:
>
> I'm not convinced that "Purely Falsified Proof-Of-Closure" aren't effective.
> Consider a similar network to the one you described where we have channels A
> - B - C and A - E - C but where we add a "fake" channel E -
I just thought of a potentially more serious problem, at least for
Poon-Dryja channels, isn't it true that giving a proof of closure is
equivalent to actually closing the channel since once other parties have
copies of the fully signed commitment transaction, it cannot be safely
revoked since
Introduction
Given the fact that contracts on offchain protocols need to be enforceable
onchain as well, timelocks involved in multi-hop payments are measured in
blocks.
This is because the blockchain can only (third-party-verifiably) enforce
timeouts in units of entire blocks.
16 matches
Mail list logo
