Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation
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 height or block time has been reached or not. So in > a way it is definitely checking against the current block height right? Why > can't it be the something like just check the block count reported is latest > one or not without putting any restriction on when the transaction can be > spend? Because if you can check the block height matches a particular number, then you can change which branch a SCRIPT goes to, and change its result. This means it is possible for your transaction to then become invalid by using such an operation and then using an `OP_IF` to return `OP_FALSE` at a later time. This violates the principle "a transaction that is valid now is always valid later unless double-spent". There is no way to provide this information without violating this principle. Always be afraid of additional power in SCRIPT. Regards, ZmnSCPxj > > On Thu, Apr 16, 2020 at 10:39 AM ZmnSCPxj wrote: > > > 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*** t
Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation
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 reached or not. So in a way it is definitely checking against the current block height right? Why can't it be the something like just check the block count reported is latest one or not without putting any restriction on when the transaction can be spend? On Thu, Apr 16, 2020 at 10:39 AM ZmnSCPxj wrote: > 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, > > > > > ZmnSCP
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 > > > > > > accidentall
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 cons
Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation
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 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 consider a non-arbitrary > payment. > > > > > Suppose a node were to make a payment attempt to itself, and > deliberately delay claiming this self-payment. > > > > > This lets any single node, *who happens to own large liquidity*, > to lock up the liquidity of other nodes. > > > > > > > > > > The motivation to lock up the liquidity of other nodes is t
Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation
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 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 consider a non-arbitrary payment. > > > > Suppose a node were to make a payment attempt to itself, and > > > > deliberately delay claiming this self-payment. > > > > This lets any single node, *who happens to own large liquidity*, to > > > > lock up the liquidity of other nodes. > > > > > > > > The motivation to lock up the liquidity of other nodes is to *eliminate > > > > competition*. > > > >
Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation
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. 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 consider a non-arbitrary payment. > > > Suppose a node were to make a payment attempt to itself, and > deliberately delay claiming this self-payment. > > > This lets any single node, *who happens to own large liquidity*, to > lock up the liquidity of other nodes. > > > > > > The motivation to lock up the liquidity of other nodes is to > *eliminate competition*. > > > Suppose we have a network as below: > > > > > > A -- B -- C > > > \ / > > >\ / > > > \ / > > > E > > > > > > When A and C want to transact with one another, they may choose to > route via either B or E. > > > B and E are therefore competitors in the business of forwarding > payments. > > > > > > But suppose E has much larger channels AE and CE than the channels of > AB and CB. > > > For example, suppose E has 100mBTC perfectly-balanced channels while B > has only 10mBTC perfectly-balanced channels, as all things should be in > simplified models of reality. > > > E can then "take out the competition" by making a 5mBTC self-payment > along E->A->
Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation
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 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 consider a non-arbitrary payment. > > Suppose a node were to make a payment attempt to itself, and deliberately > > delay claiming this self-payment. > > This lets any single node, *who happens to own large liquidity*, to lock up > > the liquidity of other nodes. > > > > The motivation to lock up the liquidity of other nodes is to *eliminate > > competition*. > > Suppose we have a network as below: > > > > A -- B -- C > > \ / > > \ / > > \ / > > E > > > > When A and C want to transact with one another, they may choose to route > > via either B or E. > > B and E are therefore competitors in the business of forwarding payments. > > > > But suppose E has much larger channels AE and CE than the channels of AB > > and CB. > > For example, suppose E has 100mBTC perfectly-balanced channels while B has > > only 10mBTC perfectly-balanced channels, as all things should be in > > simplified models of reality. > > E can then "take out the competition" by making a 5mBTC self-payment along > > E->A->B->C->E and a 5mBTC self-payment along E->C->B->A->E, then refusing > > to claim the payment, tying up all the liquidity of the channels of B. > > By doing so, it can ensure that A and C will always fail to pay via B, even > > if they wish to transact in amounts less than 5mBTC. > > E thereby eliminates B as a co
Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation
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? 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 consider a non-arbitrary payment. > Suppose a node were to make a payment attempt to itself, and deliberately > delay claiming this self-payment. > This lets any single node, *who happens to own large liquidity*, to lock > up the liquidity of other nodes. > > The motivation to lock up the liquidity of other nodes is to *eliminate > competition*. > Suppose we have a network as below: > > A -- B -- C > \ / >\ / > \ / > E > > When A and C want to transact with one another, they may choose to route > via either B or E. > B and E are therefore competitors in the business of forwarding payments. > > But suppose E has much larger channels AE and CE than the channels of AB > and CB. > For example, suppose E has 100mBTC perfectly-balanced channels while B has > only 10mBTC perfectly-balanced channels, as all things should be in > simplified models of reality. > E can then "take out the competition" by making a 5mBTC self-payment along > E->A->B->C->E and a 5mBTC self-payment along E->C->B->A->E, then refusing > to claim the payment, tying up all the liquidity of the channels of B. > By doing so, it can ensure that A and C will always fail to pay via B, > even if they wish to transact in amounts less than 5mBTC. > E thereby eliminates B as a competitor. > > This demonstrates that griefing attacks will be motivated, such that such > attacks will be performed by payers and payees *against intermediate nodes*. > Intermediate nodes have no motivation to attack payers and payees (those > are their potential customers in
Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation
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. So I am not certain that this attack is solvable at all via inter-node interactions, since we must also consider the possibility of some throwaway node being created for the purpose of executing this attack. Perhaps the remaining possible solution is to require that nodes also lock up some funds (in a UTXO that is *separate* from any channels, and from other fidelity bonds, like what belcher suggests for JoinMarket makers, and what is intended for defiads). This creates an economically-barred identity, which we might ascribe blame to, and perhaps with sufficient amount of proofs, allow someone to create a "proof-of-bad-behavior" that can be believed by other nodes on the network. The locked up fidelity bonds are an additional cost that an attacker must bear which their possible victims will not bear. Perhaps the "superbolt network" idea might consider adding such a mitigation, as it also requires some form of persistent identity anyway. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation
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 own soft timeout. > Since the unilateral close transaction *is* the proof-of-closure, B (and A) > can inspect the transaction outputs and see (with some additional data from > C) that one of the outputs is to an HTLC that matches the payment hash. > > Thus, B (and A) can believe that the proof-of-closure proves that whoever is > presenting it is free of wrongdoing, as whoever is actually causing the delay > has been punished (by someone being willing to close a channel with the > culprit), and that the proof-of-closure commits to this particular payment > attempt and no other (because it commits to a particular payment hash). As you note below, the payment might be considered dust, or an unresponsive peer has not yet acked the HTLC. My previous proposal was to limit the damage somewhat by requiring that C offer a signed list of some limited number of HTLCs it is claiming were caught, alongside the closure proof (you can merkle this, but that's a detail). That closure claim gets socialized, and if there are multiple different claim lists for the tx then C is a bad actor and we no longer respect its closure proof. You also missed how the timeout would work, which is important. How long does node N wait for a proof? In my construction, it's 30 seconds, plus get another 30 seconds for each decryption of the onion it receives. Otherwise, you can't know how long you've got to provide this closure proof, or how long to wait for it. In addition, for closure proofs to work, nodes need to agree on what is a valid, standard, high-enough-fee commitment transaction. Cheers, Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation
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 close > transaction with a minimally-sized 1-input, 1-output transaction. > > In addition, if typical mempools are full and the closing transaction > feerate is very low (i.e. because anchor outputs are meant to be used) > E may also be able to create a close transaction that will be > dropped from typical mempools in the near future and may never > confirm, allowing E to continue using the channel in attacks against its > other peers. Most nodes are programmed to presume that once a possible close of a channel is seen on a mempool, the channel is closed and the node will no longer sign any updates on it, so this is only possible if E controls the other end of the channel, i.e. this is just another variant of the EE channel. In particular, once E has released any closing transaction as proof-of-closure, C, B, A etc. can keep posting it to the mempool even if it drops out, so E would probably not want to revoke that closing transaction as its counterparty can then revoke it and take the funds in the channel. So this is safe only if the counterparty cooperates, or in other words, if E and its counterparty are the same entity. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation
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 self channel, E can also just RBF replace the close transaction with a minimally-sized 1-input, 1-output transaction. In addition, if typical mempools are full and the closing transaction feerate is very low (i.e. because anchor outputs are meant to be used) E may also be able to create a close transaction that will be dropped from typical mempools in the near future and may never confirm, allowing E to continue using the channel in attacks against its other peers. -Dave signature.asc Description: PGP signature ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation
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 pieces to the revocation priv key), but > still allows very long lock-ups of other's funds (with a 10x multiplier if > they choose a long route). I do think that this is certainly an improvement > on what we have now but I'm not sure it properly punishes the attacker in its > current form. 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. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation
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 reestablishing it again. > Further, any amount it places in the EE channel would be an amount it could have been using as liquidity on Lightning, but which it cannot use for forwarding (because it is a channel to nowhere). > Ultimately, proof-of-closure is an economic mechanism, not an information-theoretic one. Okay, I see what you mean now but I'm still a bit worried due to the following: although it is true that the same nominal penalty is incurred, the real economic value for the attacker in channel E-E' is significantly less than that in A-E, which can be used for routing. As such, a rich attacker who wishes to crowd out their competition might occasionally open channels with themselves equal to the value needed to lock up a competitor's channels, then do such a payment to themselves (with a high "hard" locktime) and close their temporary channel, but still hold their competitor's funds hostage, and still have enough liquidity in the channels they didn't have to close in order to facilitate all routing that was done by their competitor. Furthermore this route (for self-payment) could attack multiple competitors at the same time (likely leaving some funds to all but the least liquid competitor). 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 pieces to the revocation priv key), but still allows very long lock-ups of other's funds (with a 10x multiplier if they choose a long route). I do think that this is certainly an improvement on what we have now but I'm not sure it properly punishes the attacker in its current form. > Since this is a proof-of-***closure***, this is indeed an actual closing of the channel. Ah I see, I was misunderstanding a couple things, but I get it now, makes sense :) Best, Nadav On Wed, Apr 1, 2020 at 7:43 PM ZmnSCPxj wrote: > 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 - > E'. Now if the attacker sets up a payment from E to E' using the route E - > C - B - A - E - E', then the attacker can successfully lock up all of B's > channels (as is desirable to get rid of competition) and also generate a > false proof of closure for the E - E' channel. Even if this false proof > (which is a commitment tx) ends up being published on chain, E has lost no > ability to route and has successfully made B unable to route between A and > C. If my understanding of the proposal is correct, and it may not be, then > the punishment for grieving payments is the threat of closing channels that > would benefit from the grieving attack. But adding a new channel on the end > to be closed seems to invalidate this punishment? > > 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 reestablishing it again. > Further, any amount it places in the EE channel would be an amount it > could have been using as liquidity on Lightning, but which it cannot use > for forwarding (because it is a channel to nowhere). > Ultimately, proof-of-closure is an economic mechanism, not an > information-theoretic one. > > So the mere existence of EE, to be later sacrificed, is enough punishment > on E. > I think. > > > > > A second question I have is if you think that it would be advisable to > use up-front payments (pay for attempt, not just success) on payments with > abnormally high soft timeouts? If all this works, this combination seems to > be a way to enable hodl invoices under the proof of closure proposal. > > Possibly, though this increases the complexity of the proposal even more. > > >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 other parties now have the ability to publish an old state? I > might be missing something but this seems like a big problem. > > Since this is a proof-of-***closure***, this is indeed an actual closing > of the channel. > It would not be proof-of-closure if the channel wa
Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation
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 - E'. Now if the > attacker sets up a payment from E to E' using the route E - C - B - A - E - > E', then the attacker can successfully lock up all of B's channels (as is > desirable to get rid of competition) and also generate a false proof of > closure for the E - E' channel. Even if this false proof (which is a > commitment tx) ends up being published on chain, E has lost no ability to > route and has successfully made B unable to route between A and C. If my > understanding of the proposal is correct, and it may not be, then the > punishment for grieving payments is the threat of closing channels that would > benefit from the grieving attack. But adding a new channel on the end to be > closed seems to invalidate this punishment? 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 reestablishing it again. Further, any amount it places in the EE channel would be an amount it could have been using as liquidity on Lightning, but which it cannot use for forwarding (because it is a channel to nowhere). Ultimately, proof-of-closure is an economic mechanism, not an information-theoretic one. So the mere existence of EE, to be later sacrificed, is enough punishment on E. I think. > > A second question I have is if you think that it would be advisable to use > up-front payments (pay for attempt, not just success) on payments with > abnormally high soft timeouts? If all this works, this combination seems to > be a way to enable hodl invoices under the proof of closure proposal. Possibly, though this increases the complexity of the proposal even more. >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 other parties >now have the ability to publish an old state? I might be missing something but >this seems like a big problem. Since this is a proof-of-***closure***, this is indeed an actual closing of the channel. It would not be proof-of-closure if the channel was not being closed, but proof-of-something-else. What is desired is simply that C can plausibly say "I punished somebody else by closing on them, please do not punish me for punishing them". Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation
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 other parties now have the ability to publish an old state? I might be missing something but this seems like a big problem. Best, Nadav On Wed, Apr 1, 2020 at 1:07 PM Nadav Kohen wrote: > Hi ZmnSCPxj and list, > > 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 - > E'. Now if the attacker sets up a payment from E to E' using the route E - > C - B - A - E - E', then the attacker can successfully lock up all of B's > channels (as is desirable to get rid of competition) and also generate a > false proof of closure for the E - E' channel. Even if this false proof > (which is a commitment tx) ends up being published on chain, E has lost no > ability to route and has successfully made B unable to route between A and > C. If my understanding of the proposal is correct, and it may not be, then > the punishment for grieving payments is the threat of closing channels that > would benefit from the grieving attack. But adding a new channel on the end > to be closed seems to invalidate this punishment? > > A second question I have is if you think that it would be advisable to use > up-front payments (pay for attempt, not just success) on payments with > abnormally high soft timeouts? If all this works, this combination seems to > be a way to enable hodl invoices under the proof of closure proposal. > > Best, > Nadav > > On Wed, Apr 1, 2020 at 1:19 AM 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 ar
Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation
Hi ZmnSCPxj and list, 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 - E'. Now if the attacker sets up a payment from E to E' using the route E - C - B - A - E - E', then the attacker can successfully lock up all of B's channels (as is desirable to get rid of competition) and also generate a false proof of closure for the E - E' channel. Even if this false proof (which is a commitment tx) ends up being published on chain, E has lost no ability to route and has successfully made B unable to route between A and C. If my understanding of the proposal is correct, and it may not be, then the punishment for grieving payments is the threat of closing channels that would benefit from the grieving attack. But adding a new channel on the end to be closed seems to invalidate this punishment? A second question I have is if you think that it would be advisable to use up-front payments (pay for attempt, not just success) on payments with abnormally high soft timeouts? If all this works, this combination seems to be a way to enable hodl invoices under the proof of closure proposal. Best, Nadav On Wed, Apr 1, 2020 at 1:19 AM 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 consider a non-arbitrary payment. > Suppose a node were to make a payment attempt to itself, and deliberately > delay claiming this self-payment. > This lets any single node, *who happens to own large liquidity*, to lock > up the liquidity of other nodes. > > The motivation to lock up the liquidity of other nodes is to *eliminate > competition*. > Suppose we have a network as below: > > A -- B -- C > \ / >\ / > \ / > E > > When A and C want to transact with one another, they may choose to route > via either B or E. > B and E are th
[Lightning-dev] Proof-of-closure as griefing attack mitigation
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 consider a non-arbitrary payment.
Suppose a node were to make a payment attempt to itself, and deliberately delay
claiming this self-payment.
This lets any single node, *who happens to own large liquidity*, to lock up the
liquidity of other nodes.
The motivation to lock up the liquidity of other nodes is to *eliminate
competition*.
Suppose we have a network as below:
A -- B -- C
\ /
\ /
\ /
E
When A and C want to transact with one another, they may choose to route via
either B or E.
B and E are therefore competitors in the business of forwarding payments.
But suppose E has much larger channels AE and CE than the channels of AB and CB.
For example, suppose E has 100mBTC perfectly-balanced channels while B has only
10mBTC perfectly-balanced channels, as all things should be in simplified
models of reality.
E can then "take out the competition" by making a 5mBTC self-payment along
E->A->B->C->E and a 5mBTC self-payment along E->C->B->A->E, then refusing to
claim the payment, tying up all the liquidity of the channels of B.
By doing so, it can ensure that A and C will always fail to pay via B, even if
they wish to transact in amounts less than 5mBTC.
E thereby eliminates B as a competitor.
This demonstrates that griefing attacks will be motivated, such that such
attacks will be performed by payers and payees *against intermediate nodes*.
Intermediate nodes have no motivation to attack payers and payees (those are
their potential customers in the business of forwarding payments, and attacking
potential customers is bad business: such attacking intermediate nodes will be
removed economically in the long run).
However, payers and payees can become motivated to attack intermediate nodes,
if the "payer" and "payee" are actually competitor intermediate nodes.
(We can observe that this is always a possibility even outside of Lightning: a
service or product provider has no incentive to attack its customers ("the
customer is always right"), but have an incentive to *pretend* to be a customer
of a competi
