Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation
" 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 locktime, a decision can be enforced like "do not pay the full amount to D because of the response delay "? 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 able to unlock after the elapse of lock time. > > It is exactly the griefing attack scenario: it is the lock time at D that > is the problem. > As such, it is not "worse", it is ***exactly*** the griefing attack > scenario. > > 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. > > Regards, > ZmnSCPxj > > > > > On Mon, Apr 13, 2020, 08:21 ZmnSCPxj wrote: > > > > > Good morning Subhra, > > > > > > > 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, > claiming the money locked with D? > > > > > > That ***is*** the griefing attack. > > > > > > Regards, > > > ZmnSCPxj > > > > > > > > > > > On Wed, Apr 1, 2020, 11:49 ZmnSCPxj via Lightning-dev < > lightning-dev@lists.linuxfoundation.org> wrote: > > > > > > > > > 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. > > > > > This leads to very long timeouts for payment delivery, thus > multi-hop offchain payment attempts can be, deliberately or accidentally, > be in a "pending" state up to the very large timeouts involved. > > > > > > > > > > Deliberately setting up a multi-hop payment such that it will be > in a "pending" state for long periods of time is colloquially known as a > "griefing attack". > > > > > In this article, we assess various proposed solutions to mitigate > the effects of griefing attacks, and propose a particular solution, > proof-of-closure, as well, that requires significant changes to the update > state machine. > > > > > > > > > > Digression: Why Grief? > > > > > == > > > > > > > > > > Before embarking on our investigation for solutions to the > griefing problem, we should first wonder if griefing is, in fact, a problem. > > > > > > > > > > This brings up the question of: why would anybody grief at all? > > > > > > > > > > Humans, like cats and other less-sapient pieces of walking meat, > often find enjoyment in causing the suffering of others for no immediate > direct gain to themselves, as a public demonstration of dominance over > those they make suffer (aka "shits and giggles", which, if executed > correctly, can lead to eventual direct gains to themselves or their progeny > or relatives or allies, but such details are often outside the ken of the > very beings who execute such survival strategies: brains are pieces of meat > that have been hacked to act as action-reaction engines, but are not > sophisticated enough to execute as pure rationality engines at all times). > > > > > Fortunately, in the Bitcoin world, only purely rational beings of > pure selfishness can exist in the long run, thus we can neglect such > motivations as mere noise. > > > > > > > > > > First, let us investigate *how* griefing attacks can be performed. > > > > > > > > > > * An intermediate node in a multi-hop attempt can delay forwarding > or failing an incoming HTLC. > > > > > * A final node in a payment attempt can delay claiming an incoming > HTLC. > > > > > > > > > > Let us consider a purely rational intermediate node of pure > selfishness: > > > > > > > > > > * If it forwards as soon as possible, it can earn fees, and also > speed up the release of the HTLC-locked funds so that they can reuse those > funds as liquidity for further payment attempts. > > > > > * Thus, delaying an HTLC is not selfishly-rational for an > intermediate node. > > > > > > > > > > Thus, for an intermediate node, it seems there is no > selfishly-rational motivation to execute a griefing attack on an arbitrary > payment attempt. > > > > > We can then conclude that an intermediate that delays a payment > would do so, not of its own rational self-interest, but as an accident, > such as an unforeseen connectivity or power failure. > > > > > > > > > > However, things are different when we
Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation
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 chain just before elapse of the > locktime, a decision can be enforced like "do not pay the full amount to D > because of the response delay "? > No, not without breaking certain principles of Bitcoin. In particular, one possible solution would be to have multiple staggered transactions that are timelocked at particular times, so for example if it responds at +1 it gets more money than if it responds at +2, +3, +4 etc. However, because of the way timelock works, the transaction that is valid at +1 remains valid at any future time. This is the principle "a transaction that becomes valid is always valid in the future unless double-spent". Bitcoin Core uses this to reduce validation overhead: it only needs to validate a transaction (i.e. execute the SCRIPT, which is one of the slower operations) on entry to the mempool. Then, once the transaction is in the mempool, it is known to be valid forever unless double-spent, so Bitcoin does not need to re-evaluate its SCRIPT. Any mechanism that requires invalidating previous transactions requires double-spending those transactions and using some other mechanism to ensure that the invalidated transaction is not useable again. This involves significant amounts of transactions that will need to be presented onchain in this case (because D is expected to lose money in this mechanism, it will definitely not participate in consensus that will advance the channel state such that it loses money, so the channel has to be dropped onchain anyway to perform this enforcement). Another principle is "SCRIPT can only check the transaction it is executing for". Thus, a `redeemScript` will only be able to execute on the transaction that presents it, and a `scriptPubKey` can only be executed on the transaction spending that output. This means that SCRIPT can only inspect the transaction that it is executing on, and cannot look at anything else in the universe. This principle simplifies initial block download --- in order to validate a SCRIPT, you only need to look at each individual transaction in a block without having to know any data other than that specific transaction. For example, `OP_CHECKLOCKTIMEVERIFY` does ***not*** work by checking the blockheight or claimed sidereal time that the block that contains it has. Instead, it works by checking the `nLockTime` field of the *transaction* it is executing under. By this, the SCRIPT interpreter only needs to input the transaction that is triggering the execution of the SCRIPT, and does not need access to external state, time, etc. etc. These two principles in combination make it difficult-to-impossible to create a mechanism to deduct funds from D because of response delay. Regards, ZmnSCPxj > 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 able to unlock after the elapse of lock time. > > > > It is exactly the griefing attack scenario: it is the lock time at D that > > is the problem. > > As such, it is not "worse", it is ***exactly*** the griefing attack > > scenario. > > > > 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. > > > > Regards, > > ZmnSCPxj > > > > > > > > On Mon, Apr 13, 2020, 08:21 ZmnSCPxj wrote: > > > > > > > Good morning Subhra, > > > > > > > > > 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, claiming the money locked with D? > > > > > > > > That ***is*** the griefing attack. > > > > > > > > Regards, > > > > ZmnSCPxj > > > > > > > > > > > > > > On Wed, Apr 1, 2020, 11:49 ZmnSCPxj via Lightning-dev > > > > > wrote: > > > > > > > > > > > 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. > > > > > > This leads to very long timeouts for payment delivery, thus > > > > > > multi-hop offchain payment attempts can be, deliberately or > > > > > >
