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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 > > > > > > > <[email protected]> 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 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 competitor and > > > > > > > > attack them.) > > > > > > > > > > > > > > > > We will keep this fact in mind: active griefing attacks are > > > > > > > > attacks *on* intermediate nodes, not *by* intermediate nodes, > > > > > > > > because there is no economic incentive for intermediate nodes > > > > > > > > to attack their customers. > > > > > > > > > > > > > > > > Previous Proposed Solutions > > > > > > > > =========================== > > > > > > > > > > > > > > > > Time-Spent Reporting > > > > > > > > -------------------- > > > > > > > > > > > > > > > > At each channel along the route, the time spent by a node to > > > > > > > > handle its forwarding is recorded, and reported upstream in the > > > > > > > > route. > > > > > > > > > > > > > > > > Unfortunately, this solution protects payers from intermediate > > > > > > > > nodes and payees: it does not protect intermediate nodes from > > > > > > > > colluding payers and payees. > > > > > > > > Even if an intermediate node knows that a particular node is > > > > > > > > consistently slow via a previous time-spent report, it will not > > > > > > > > be able, with our current onion routing, determine if an onion > > > > > > > > packet it just received will or will not go through the > > > > > > > > known-slow node. > > > > > > > > Thus, an intermediate node would not be able to defend against > > > > > > > > distant payees that, with a colluding payer, will not claim a > > > > > > > > particular payment. > > > > > > > > > > > > > > > > As we have established, an active griefing atttack will never > > > > > > > > be deliberately performed by a selfishly-rational intermediate > > > > > > > > node. > > > > > > > > Thus, this solution protects against the wrong thing: it > > > > > > > > protects payers against slow/unreliable intermediate nodes, it > > > > > > > > does not protect intermediate nodes against malicious > > > > > > > > payer/payee collusions. > > > > > > > > It protects only against intermediate nodes that inadvertently > > > > > > > > go offline during forwarding, but such nodes will inevitably > > > > > > > > lose out on the forwarding market anyway, and will disappear in > > > > > > > > the long run. > > > > > > > > > > > > > > > > Up-Front Payment > > > > > > > > ---------------- > > > > > > > > > > > > > > > > Payers pay for an attempt, not just the successful completion > > > > > > > > of an attempt. > > > > > > > > > > > > > > > > A variation on this is that the payer (or payee) continuously > > > > > > > > pays as long as the payment is pending. > > > > > > > > Further variations include paying by other means, such as just > > > > > > > > locking funds or paying with proof-of-work. > > > > > > > > > > > > > > > > While it certainly erects economic barriers against payer/payee > > > > > > > > collusions attacking intermediate nodes, it *also* erects > > > > > > > > economic barriers against normal, non-malicious payments. > > > > > > > > > > > > > > > > We can consider that economic barriers against non-malicious, > > > > > > > > low-value, high-frequency payments ("micropayments") may be > > > > > > > > enough that such payments become infeasible if we impose > > > > > > > > up-front payment for mere attempts. > > > > > > > > Thus, while this solution is certainly something we can > > > > > > > > consider, we must be reluctant to use it due to its up-front, > > > > > > > > strict-evaluation behavior. > > > > > > > > > > > > > > > > Proof-Of-Closure > > > > > > > > ================ > > > > > > > > > > > > > > > > Observing the above, we want the properties for a "good" > > > > > > > > solution to griefing attacks to be: > > > > > > > > > > > > > > > > * It should protect intermediate nodes against payer/payee > > > > > > > > collusions. > > > > > > > > * It should only come into play upon detection of an attack. > > > > > > > > > > > > > > > > We now present proof-of-closure, which (we hope) has the above > > > > > > > > properties. > > > > > > > > > > > > > > > > We can consider instead a softer timeout, distinct from the > > > > > > > > HTLC block-based timeout. > > > > > > > > This softer timeout is measurable in fractions of a second, > > > > > > > > e.g. units of 0.1 seconds. > > > > > > > > > > > > > > > > Each node on the network advertises, in addition to a > > > > > > > > block-based `cltv_delta`, a `timeout_delta` in units of 0.1 > > > > > > > > seconds. > > > > > > > > Further, each invoice contains, in addition to a block-based > > > > > > > > `final_cltv`, a `final_timeout` in units of 0.1 seconds. > > > > > > > > > > > > > > > > Thus, there are two timeouts: > > > > > > > > > > > > > > > > * The current "hard" block-based timeout that is enforceable > > > > > > > > onchain. > > > > > > > > * A new "soft" sidereal-time-based timeout that is not onchain > > > > > > > > enforceable. > > > > > > > > > > > > > > > > The soft timeout, as mentioned, is not enforceable onchain. > > > > > > > > Instead, enforcement of the soft timeout *is* the act of > > > > > > > > putting the channel state onchain. > > > > > > > > > > > > > > > > Now, for the current "hard" block-based timeout, we already > > > > > > > > have a reaction. > > > > > > > > If the HTLC "hard" timeout is approaching: > > > > > > > > > > > > > > > > * Drop the channel onchain and enforce the hard timeout onchain > > > > > > > > to reclaim the funds in the HTLCs. > > > > > > > > * Wait for the onchain action to be deeply resolved (either > > > > > > > > timelock or hashlock branch is confirmed deeply) and report the > > > > > > > > result (success or fail) upstream. > > > > > > > > > > > > > > > > What happens if the "soft" timeout is violated? > > > > > > > > > > > > > > > > * Drop the channel onchain. > > > > > > > > * Report the channel closure upstream. > > > > > > > > > > > > > > > > The "hard" timeout is cancelled in any of these two conditions: > > > > > > > > > > > > > > > > * A success is reported via `update_fulfill_htlc`, OR, > > > > > > > > * A failure is reported via `update_fail_htlc` AND the HTLC is > > > > > > > > irrevocably removed from the latest commitments/state(s) of the > > > > > > > > channel. > > > > > > > > > > > > > > > > The "soft" timeout is cancelled in any of these three > > > > > > > > conditions, the first two of which are the same as above: > > > > > > > > > > > > > > > > * A success is reported via `update_fulfill_htlc`, OR, > > > > > > > > * A failure is reported via `update_fail_htlc` AND the HTLC is > > > > > > > > irrevocably removed from the latest commitments/state(s) of the > > > > > > > > channel, OR > > > > > > > > * A channel closure is reported. > > > > > > > > > > > > > > > > Let us fill this in more detail. > > > > > > > > > > > > > > > > Suppose we have a payment route A->B->C->E. > > > > > > > > > > > > > > > > Both the "hard" block timeouts and the "soft" second timeouts > > > > > > > > decrement monotonically at each hop. > > > > > > > > Thus, the payee E has the shortest "hard" and "soft" timeouts > > > > > > > > (as normal). > > > > > > > > > > > > > > > > * Suppose E then delays claiming the payment and violates the > > > > > > > > "soft" timeout. > > > > > > > > * C then drops the CE channel onchain. > > > > > > > > * C reports, before its own timeout (slightly larger than the > > > > > > > > timeout imposed on E), the closing of the channel CE, to B. > > > > > > > > * B validates this report, and if valid, propagates the report > > > > > > > > to A. > > > > > > > > * A validates this report, and if valid, accepts that the > > > > > > > > payment will be "stuck" for up to the hard timeout it imposed > > > > > > > > on B. > > > > > > > > > > > > > > > > C has to report back to B in order to prevent B from closing > > > > > > > > the BC channel, and B has to report back to A in order to > > > > > > > > prevent A from closing the AB channel. > > > > > > > > The decrementing seconds-unit timeouts are needed for each hop, > > > > > > > > for the same reason that decrementing block-unit timeouts are > > > > > > > > needed. > > > > > > > > > > > > > > > > Since E is motivated to attack intermediate nodes because it > > > > > > > > wants to redirect payment forwards through itself rather than > > > > > > > > its competitotrs, having one of its channels closed (which > > > > > > > > prevents it from being used for forwarding) is directly opposed > > > > > > > > to its end goal of getting more money, thus, we can believe the > > > > > > > > action of closing a channel involved in a griefing attack is > > > > > > > > sufficient disincentive. > > > > > > > > > > > > > > > > The major drawback is that enforcement of the soft timeout *is* > > > > > > > > a channel closure, which is generally a negative for the > > > > > > > > network. > > > > > > > > This is not a remote attack vector, since a node can only > > > > > > > > trigger this closure if it is able to stall the fulfillment or > > > > > > > > failure of an HTLC on a channel, which generally means the node > > > > > > > > triggering this closure can only do so for its own channels (or > > > > > > > > it is able to, via a separate mechanism, remotely crash a > > > > > > > > different node). > > > > > > > > > > > > > > > > Proving Channel Closes > > > > > > > > ---------------------- > > > > > > > > > > > > > > > > What C *really* needs to prove is that: > > > > > > > > > > > > > > > > * It is *willing* to close a channel due to a violation of the > > > > > > > > soft timeout. > > > > > > > > * The channel it is willing to close was, in fact, involved in > > > > > > > > the same payment attempt. > > > > > > > > > > > > > > > > With the above, B can believe that C was innocent of > > > > > > > > wrongdoing, because: > > > > > > > > > > > > > > > > * C would only be wiling to close a channel in case of a > > > > > > > > protocol violation, in this case, a violation of the soft > > > > > > > > timeout. > > > > > > > > * The channel it closed was closed because of this payment > > > > > > > > attempt, and not because of another payment attempt, or some > > > > > > > > other unrelated channel being unilaterally closed. > > > > > > > > > > > > > > > > First, what C needs to prove is *NOT*, in fact, actual channel > > > > > > > > closure: it needs to prove a *willingness* to close a channel. > > > > > > > > Thus, it does not require the channel to actually be *closed* > > > > > > > > yet, i.e. it does not have to wait for onchain activity that > > > > > > > > the channel closure is in a mempool and is confirmed deeply > > > > > > > > onchain etc etc. > > > > > > > > > > > > > > > > Thus, to prove a *willingness to close* rather than an actual > > > > > > > > close, C can provide the unilateral close of the channel CE. > > > > > > > > The act of unilaterally closing a channel is the publication of > > > > > > > > the transaction(s) making up the unilateral close. > > > > > > > > Thus, if C is *willing* to close the channel, it is willing to > > > > > > > > publish the transaction(s) involved, and thus, providing the > > > > > > > > unilateral close to B and further upstream, shows a willingness > > > > > > > > to close the channel. > > > > > > > > > > > > > > > > B then validates the provided proof-of-closure by checking that > > > > > > > > the unilateral close transaction is either onchain, in the > > > > > > > > mempool, or that it spends a TXO that is not currently spent by > > > > > > > > another transaction. > > > > > > > > In the case the unilateral close transaction is not confirmed > > > > > > > > and in the mempool, B can speed up its propagation on the > > > > > > > > Bitcoin layer by putting it in its own mempool as well --- > > > > > > > > after all, C is willing to close the channel to exonerate > > > > > > > > itself and punish the actual culprit, and B putting the > > > > > > > > unilateral close in its own mempool can only help C in what it > > > > > > > > is willing to do. > > > > > > > > > > > > > > > > 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). > > > > > > > > > > > > > > > > Further, if CE is closed by E dropping it onchain rather than > > > > > > > > C, C will still be able to fulfill its own soft timeout by > > > > > > > > taking the closing transaction from E, which should still > > > > > > > > contain the HTLC. > > > > > > > > Indeed, neither A nor B will particularly care (nor need to > > > > > > > > know) who dropped the channel onchain, or (for A) that the > > > > > > > > channel participants are C and E. > > > > > > > > > > > > > > > > Update State Shenanigans > > > > > > > > ------------------------ > > > > > > > > > > > > > > > > Bitcoin update mechanisms are complicated things, and it may be > > > > > > > > possible for an attacking payee E to fool around with the > > > > > > > > update state machine to make it difficult for C to report a > > > > > > > > willingness to close CE. > > > > > > > > > > > > > > > > In particular, I quote here the relevant passages from > > > > > > > > `lightning-rfc`, `02-peer-protocol.md`, which is an > > > > > > > > implementation of the Poon-Dryja update mechanism: > > > > > > > > > > > > > > > > > Thus each update traverses through the following states: > > > > > > > > > > > > > > > > > > 1. pending on the receiver > > > > > > > > > 2. in the receiver's latest commitment transaction > > > > > > > > > 3. ... and the receiver's previous commitment transaction has > > > > > > > > > been revoked, > > > > > > > > > and the update is pending on the sender > > > > > > > > > 4. ... and in the sender's latest commitment transaction > > > > > > > > > 5. ... and the sender's previous commitment transaction has > > > > > > > > > been revoked > > > > > > > > > > > > > > > > The payee E is the "receiver" in this context. > > > > > > > > > > > > > > > > In this case, once the update has reached step 2, then E has a > > > > > > > > commitment transaction that it can put onchain, that contains > > > > > > > > an HTLC it can claim. > > > > > > > > From this step onward, C cannot send a failure (i.e. it cannot > > > > > > > > send back an `update_fail_htlc`) back to B, because E could > > > > > > > > drop its latest commitment onchain and claim the HTLC onchain. > > > > > > > > > > > > > > > > However, until step 4, C does not have a unilateral close > > > > > > > > containing the HTLC, and thus cannot provide a proof-of-closure > > > > > > > > that contains an HTLC that refers to the payment. > > > > > > > > > > > > > > > > Thus, between steps 2 to 4, C cannot safely respond to its own > > > > > > > > soft timeout. > > > > > > > > C cannot respond with a failure, as E could then drop its > > > > > > > > latest commitment transaction onchain and claim the payment > > > > > > > > from C, and extract money from C that way. > > > > > > > > C also cannot respond with a proof-of-closure, as it does not > > > > > > > > have a transaction that it can use to provide this proof. > > > > > > > > > > > > > > > > The best that C can do would be to impose an even shorter > > > > > > > > timeout between steps 2 and 4 above, and to drop its current > > > > > > > > commitment transaction (which does not contain the HTLC yet and > > > > > > > > thus does not constitute a valid proof-of-closure) onchain. > > > > > > > > In between the time it drops the commitment transaction and its > > > > > > > > own incoming soft timeout, there is a chance, however small, > > > > > > > > that this transaction will be confirmed, and the channel will > > > > > > > > (with high probability) settle in a state where the HTLC is not > > > > > > > > instantiated, thus C can safely fail its incoming HTLC (not > > > > > > > > show a proof-of-closure, since that is not possible for C to > > > > > > > > do) without risk of loss, just prior to its own soft timeout. > > > > > > > > > > > > > > > > Of course, C is still at risk here: E could collude with miners > > > > > > > > via a side-channel fee offer to confirm its commitment > > > > > > > > transaction with the HTLC present, and ensure that C is liable > > > > > > > > for the HTLC value. > > > > > > > > > > > > > > > > With Decker-Russell-Osuntokun, we can remove this risk by > > > > > > > > requiring a ritual as follows: > > > > > > > > > > > > > > > > 1. C requests exclusive access to update their single shared > > > > > > > > state. > > > > > > > > * This can be done via a variety of sub-protocols, including > > > > > > > > a fair coin toss in case of near-simultaneous requests for > > > > > > > > exclusive locks on both sides. > > > > > > > > 2. C provides the details of the new HTLC to E. > > > > > > > > 3. C and E generate the new state transaction and exchange > > > > > > > > signatures for it. > > > > > > > > 4. C and E generate (without signing) the new update > > > > > > > > transaction. > > > > > > > > 5. E provides the signature (or share of signature, if MuSig) > > > > > > > > for the new update transaction to C. > > > > > > > > 6. C provides the signature for the new update transaction to > > > > > > > > E, which releases the exclusive lock on the shared state > > > > > > > > atomically with the finalization of the new update transaction. > > > > > > > > > > > > > > > > Prior to step 5, C can simply fail the incoming HTLC from B in > > > > > > > > case its own soft timeout is near. > > > > > > > > Even if E performs step 5 after C has already failed the > > > > > > > > incoming HTLC from B, C can simply not perform step 6 and drop > > > > > > > > the channel onchain with the previous update and state > > > > > > > > transactions. > > > > > > > > > > > > > > > > With Poon-Dryja, we will have to rearrange the order in which > > > > > > > > we perform things, effectively adding an extra communications > > > > > > > > turnaround between the participants. > > > > > > > > Specifically, the order would have to be revised to: > > > > > > > > > > > > > > > > > 1. pending on the sender > > > > > > > > > 2. in the sender's latest commitment transaction > > > > > > > > > 3. ... and the sender's previous commitment transaction has > > > > > > > > > been revoked, > > > > > > > > > and the update is pending on the receiver > > > > > > > > > 4. ... and in the receiver's latest commitment transaction > > > > > > > > > 5. ... and the receiver's previous commitment transaction has > > > > > > > > > been revoked > > > > > > > > > > > > > > > > This allows the sender (C in our context) to provide a > > > > > > > > proof-of-closure after step 2, and before step 2, C can safely > > > > > > > > return a failure with `update_fail_htlc` (and refuse to proceed > > > > > > > > beyond step 2, thus ensuring it can still use the previous > > > > > > > > commitment that still has no HTLC). > > > > > > > > > > > > > > > > Of course, this change will require redesigning the update > > > > > > > > state machine, increasing the number of communication > > > > > > > > turnarounds, and creating a subtle incompatbility when > > > > > > > > transitioning a payment from a hop that knows only the old > > > > > > > > update state machine to a hop that knows the new update state > > > > > > > > machine. > > > > > > > > > > > > > > > > Purely Falsified Proof-Of-Closure > > > > > > > > --------------------------------- > > > > > > > > > > > > > > > > Of course, the attacking node E might want to create a false > > > > > > > > proof-of-closure. > > > > > > > > E can do this by simulating a Lightning channel: lock an amount > > > > > > > > of funds in a 2-of-2 (where E controls both keys), then spend > > > > > > > > it in a set of transactions mimicking the unilateral close. > > > > > > > > > > > > > > > > We observe, however, that the overhead of simulating a > > > > > > > > Lightning channel is the same as the overhead of actually > > > > > > > > creating and closing a Lightning channel. > > > > > > > > Since the punishment of proof-of-closure is to force attackers > > > > > > > > to have their channels closed, we can consider that this > > > > > > > > simulation of a channel open and close is sufficient as well. > > > > > > > > > > > > > > > > Future-Proofing > > > > > > > > --------------- > > > > > > > > > > > > > > > > This sketch of proof-of-closure can be used for any update > > > > > > > > mechanism: > > > > > > > > > > > > > > > > * With Poon-Dryja, C can use its own commitment transaction as > > > > > > > > the proof-of-closure. > > > > > > > > * With Decker-Wattenhofer, C can give all the offchain > > > > > > > > transactions up to the last stage in the multi-stage > > > > > > > > decrementing-`nSequence` mechanism. > > > > > > > > * With Deckker-Russell-Osuntokun, C can give the latest update > > > > > > > > and state trnsaction. > > > > > > > > > > > > > > > > Basically, we expect that for now, and in the future, any > > > > > > > > update mechanism worth consideration will have a concept of > > > > > > > > "unilateral close" where a channel can be dropped onchain, > > > > > > > > using data that only one of the channel participants holds. > > > > > > > > > > > > > > > > Such a unilateral close will be a sequence of one or more valid > > > > > > > > transactions, terminating in a transaction containing an > > > > > > > > HTLC-like contract in one of its outputs. > > > > > > > > > > > > > > > > Thus, to validate the unilateral close, it is only required to > > > > > > > > validate all the transactions contained in the > > > > > > > > proof-of-closure, and see that the last transaction has an HTLC > > > > > > > > output. > > > > > > > > > > > > > > > > The limitations are thus: > > > > > > > > > > > > > > > > * The acceptable forms of HTLC would need to be agreed-upon by > > > > > > > > the entire network. > > > > > > > > * Implementations would need to be able to assess, in a > > > > > > > > Bitcoin-consensus-compatible way, whether a transaction is > > > > > > > > valid or not. > > > > > > > > > > > > > > > > Payment Decorrelation and Payment Points > > > > > > > > ---------------------------------------- > > > > > > > > > > > > > > > > Of course, having a single payment hash for the entire payment > > > > > > > > attempt is a privacy loss, which we intend to fix in the near > > > > > > > > future by using payment points, and adding a blinding scalar at > > > > > > > > each hop, aka. payment decorrelation. > > > > > > > > > > > > > > > > Thus, in the future, there will not be any HTLC, but instead a > > > > > > > > PTLC. > > > > > > > > Further, the payment point at each hop will be changed at each > > > > > > > > hop, in order to prevent decorrelation. > > > > > > > > > > > > > > > > Thus, C needs to provide proofs: > > > > > > > > > > > > > > > > * That an apparent singlesig on the unilateral close output is > > > > > > > > in fact a PTLC. > > > > > > > > C needs to provide: > > > > > > > > * A target point P. > > > > > > > > * A partial signature that would spend that singlesig for a > > > > > > > > particular sighash. > > > > > > > > * An adaptor signature which, with knowledge of the completed > > > > > > > > signature, adaptor signature, and sighash message, would have > > > > > > > > revealed the scalar behind P. > > > > > > > > * That the PTLC belongs to the same payment attempt as what B > > > > > > > > offered to C. > > > > > > > > C needs to provide: > > > > > > > > * The C-only blinding factor that is the difference between > > > > > > > > the payment point of the B-to-C PTLC and the C-to-E PTLC on the > > > > > > > > unilateral close. > > > > > > > > > > > > > > > > Then, when B needs to propagate the proof-of-closure back to A, > > > > > > > > B simply adds its own blinding factor to the reported blinding > > > > > > > > factor, in order to convince A that this is the same payment > > > > > > > > attempt. > > > > > > > > > > > > > > > > As we have brought up privacy, we observe that, when this > > > > > > > > mechanism triggers, there is a mild privacy loss, in that > > > > > > > > intermediate nodes now know some channel closure that is > > > > > > > > related to this payment, and can thus determine the exact path > > > > > > > > that the payment attempt went through, at least until the > > > > > > > > channel being closed. > > > > > > > > However, proof-of-closure is only propagated in case of > > > > > > > > violation of the soft timeout, so for normal non-malicious > > > > > > > > payments, proof-of-closure does not cause any privacy loss. > > > > > > > > _______________________________________________ > > > > > > > > Lightning-dev mailing list > > > > > > > > [email protected] > > > > > > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > > > > -- > > > Yours sincerely, > > > Subhra Mazumdar. > > -- > Yours sincerely, > Subhra Mazumdar. _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
