{"type":"rich","version":"1.0","title":"Nadav Kohen [ARCHIVE] wrote","author_name":"Nadav Kohen [ARCHIVE] (npub1ge…rtua0)","author_url":"https://yabu.me/npub1geqdlge6ysz9qlq3w758422flnkgqklpu9veu80ehjprcd04ugyqkrtua0","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2020-04-01\n📝 Original message:\nHi ZmnSCPxj and list,\n\nLove the idea! I have a couple questions though:\n\nI'm not convinced that \"Purely Falsified Proof-Of-Closure\" aren't\neffective. Consider a similar network to the one you described where we\nhave channels A - B - C and A - E - C but where we add a \"fake\" channel E -\nE'. Now if the attacker sets up a payment from E to E' using the route E -\nC - B - A - E - E', then the attacker can successfully lock up all of B's\nchannels (as is desirable to get rid of competition) and also generate a\nfalse proof of closure for the E - E' channel. Even if this false proof\n(which is a commitment tx) ends up being published on chain, E has lost no\nability to route and has successfully made B unable to route between A and\nC. If my understanding of the proposal is correct, and it may not be, then\nthe punishment for grieving payments is the threat of closing channels that\nwould benefit from the grieving attack. But adding a new channel on the end\nto be closed seems to invalidate this punishment?\n\nA second question I have is if you think that it would be advisable to use\nup-front payments (pay for attempt, not just success) on payments with\nabnormally high soft timeouts? If all this works, this combination seems to\nbe a way to enable hodl invoices under the proof of closure proposal.\n\nBest,\nNadav\n\nOn Wed, Apr 1, 2020 at 1:19 AM ZmnSCPxj via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Introduction\n\u003e ============\n\u003e\n\u003e Given the fact that contracts on offchain protocols need to be enforceable\n\u003e onchain as well, timelocks involved in multi-hop payments are measured in\n\u003e blocks.\n\u003e This is because the blockchain can only (third-party-verifiably) enforce\n\u003e timeouts in units of entire blocks.\n\u003e This leads to very long timeouts for payment delivery, thus multi-hop\n\u003e offchain payment attempts can be, deliberately or accidentally, be in a\n\u003e \"pending\" state up to the very large timeouts involved.\n\u003e\n\u003e Deliberately setting up a multi-hop payment such that it will be in a\n\u003e \"pending\" state for long periods of time is colloquially known as a\n\u003e \"griefing attack\".\n\u003e In this article, we assess various proposed solutions to mitigate the\n\u003e effects of griefing attacks, and propose a particular solution,\n\u003e proof-of-closure, as well, that requires significant changes to the update\n\u003e state machine.\n\u003e\n\u003e Digression: Why Grief?\n\u003e ======================\n\u003e\n\u003e Before embarking on our investigation for solutions to the griefing\n\u003e problem, we should first wonder if griefing is, in fact, a problem.\n\u003e\n\u003e This brings up the question of: why would anybody grief at all?\n\u003e\n\u003e Humans, like cats and other less-sapient pieces of walking meat, often\n\u003e find enjoyment in causing the suffering of others for no immediate direct\n\u003e gain to themselves, as a public demonstration of dominance over those they\n\u003e make suffer (aka \"shits and giggles\", which, if executed correctly, can\n\u003e lead to eventual direct gains to themselves or their progeny or relatives\n\u003e or allies, but such details are often outside the ken of the very beings\n\u003e who execute such survival strategies: brains are pieces of meat that have\n\u003e been hacked to act as action-reaction engines, but are not sophisticated\n\u003e enough to execute as pure rationality engines at all times).\n\u003e Fortunately, in the Bitcoin world, only purely rational beings of pure\n\u003e selfishness can exist in the long run, thus we can neglect such motivations\n\u003e as mere noise.\n\u003e\n\u003e First, let us investigate *how* griefing attacks can be performed.\n\u003e\n\u003e * An intermediate node in a multi-hop attempt can delay forwarding or\n\u003e failing an incoming HTLC.\n\u003e * A final node in a payment attempt can delay claiming an incoming HTLC.\n\u003e\n\u003e Let us consider a purely rational intermediate node of pure selfishness:\n\u003e\n\u003e * If it forwards as soon as possible, it can earn fees, and also speed up\n\u003e the release of the HTLC-locked funds so that they can reuse those funds as\n\u003e liquidity for further payment attempts.\n\u003e * Thus, delaying an HTLC is not selfishly-rational for an intermediate\n\u003e node.\n\u003e\n\u003e Thus, for an intermediate node, it seems there is no selfishly-rational\n\u003e motivation to execute a griefing attack on an arbitrary payment attempt.\n\u003e We can then conclude that an intermediate that delays a payment would do\n\u003e so, not of its own rational self-interest, but as an accident, such as an\n\u003e unforeseen connectivity or power failure.\n\u003e\n\u003e However, things are different when we consider a non-arbitrary payment.\n\u003e Suppose a node were to make a payment attempt to itself, and deliberately\n\u003e delay claiming this self-payment.\n\u003e This lets any single node, *who happens to own large liquidity*, to lock\n\u003e up the liquidity of other nodes.\n\u003e\n\u003e The motivation to lock up the liquidity of other nodes is to *eliminate\n\u003e competition*.\n\u003e Suppose we have a network as below:\n\u003e\n\u003e     A -- B -- C\n\u003e       \\     /\n\u003e        \\   /\n\u003e         \\ /\n\u003e          E\n\u003e\n\u003e When A and C want to transact with one another, they may choose to route\n\u003e via either B or E.\n\u003e B and E are therefore competitors in the business of forwarding payments.\n\u003e\n\u003e But suppose E has much larger channels AE and CE than the channels of AB\n\u003e and CB.\n\u003e For example, suppose E has 100mBTC perfectly-balanced channels while B has\n\u003e only 10mBTC perfectly-balanced channels, as all things should be in\n\u003e simplified models of reality.\n\u003e E can then \"take out the competition\" by making a 5mBTC self-payment along\n\u003e E-\u003eA-\u003eB-\u003eC-\u003eE and a 5mBTC self-payment along E-\u003eC-\u003eB-\u003eA-\u003eE, then refusing\n\u003e to claim the payment, tying up all the liquidity of the channels of B.\n\u003e By doing so, it can ensure that A and C will always fail to pay via B,\n\u003e even if they wish to transact in amounts less than 5mBTC.\n\u003e E thereby eliminates B as a competitor.\n\u003e\n\u003e This demonstrates that griefing attacks will be motivated, such that such\n\u003e attacks will be performed by payers and payees *against intermediate nodes*.\n\u003e Intermediate nodes have no motivation to attack payers and payees (those\n\u003e are their potential customers in the business of forwarding payments, and\n\u003e attacking potential customers is bad business: such attacking intermediate\n\u003e nodes will be removed economically in the long run).\n\u003e However, payers and payees can become motivated to attack intermediate\n\u003e nodes, if the \"payer\" and \"payee\" are actually competitor intermediate\n\u003e nodes.\n\u003e\n\u003e (We can observe that this is always a possibility even outside of\n\u003e Lightning: a service or product provider has no incentive to attack its\n\u003e customers (\"the customer is always right\"), but have an incentive to\n\u003e *pretend* to be a customer of a competitor and attack them.)\n\u003e\n\u003e We will keep this fact in mind: active griefing attacks are attacks *on*\n\u003e intermediate nodes, not *by* intermediate nodes, because there is no\n\u003e economic incentive for intermediate nodes to attack their customers.\n\u003e\n\u003e Previous Proposed Solutions\n\u003e ===========================\n\u003e\n\u003e Time-Spent Reporting\n\u003e --------------------\n\u003e\n\u003e At each channel along the route, the time spent by a node to handle its\n\u003e forwarding is recorded, and reported upstream in the route.\n\u003e\n\u003e Unfortunately, this solution protects payers from intermediate nodes and\n\u003e payees: it does not protect intermediate nodes from colluding payers and\n\u003e payees.\n\u003e Even if an intermediate node knows that a particular node is consistently\n\u003e slow via a previous time-spent report, it will not be able, with our\n\u003e current onion routing, determine if an onion packet it just received will\n\u003e or will not go through the known-slow node.\n\u003e Thus, an intermediate node would not be able to defend against distant\n\u003e payees that, with a colluding payer, will not claim a particular payment.\n\u003e\n\u003e As we have established, an active griefing atttack will never be\n\u003e deliberately performed by a selfishly-rational intermediate node.\n\u003e Thus, this solution protects against the wrong thing: it protects payers\n\u003e against slow/unreliable intermediate nodes, it does not protect\n\u003e intermediate nodes against malicious payer/payee collusions.\n\u003e It protects only against intermediate nodes that inadvertently go offline\n\u003e during forwarding, but such nodes will inevitably lose out on the\n\u003e forwarding market anyway, and will disappear in the long run.\n\u003e\n\u003e Up-Front Payment\n\u003e ----------------\n\u003e\n\u003e Payers pay for an attempt, not just the successful completion of an\n\u003e attempt.\n\u003e\n\u003e A variation on this is that the payer (or payee) continuously pays as long\n\u003e as the payment is pending.\n\u003e Further variations include paying by other means, such as just locking\n\u003e funds or paying with proof-of-work.\n\u003e\n\u003e While it certainly erects economic barriers against payer/payee collusions\n\u003e attacking intermediate nodes, it *also* erects economic barriers against\n\u003e normal, non-malicious payments.\n\u003e\n\u003e We can consider that economic barriers against non-malicious, low-value,\n\u003e high-frequency payments (\"micropayments\") may be enough that such payments\n\u003e become infeasible if we impose up-front payment for mere attempts.\n\u003e Thus, while this solution is certainly something we can consider, we must\n\u003e be reluctant to use it due to its up-front, strict-evaluation behavior.\n\u003e\n\u003e Proof-Of-Closure\n\u003e ================\n\u003e\n\u003e Observing the above, we want the properties for a \"good\" solution to\n\u003e griefing attacks to be:\n\u003e\n\u003e * It should protect intermediate nodes against payer/payee collusions.\n\u003e * It should only come into play upon detection of an attack.\n\u003e\n\u003e We now present proof-of-closure, which (we hope) has the above properties.\n\u003e\n\u003e We can consider instead a softer timeout, distinct from the HTLC\n\u003e block-based timeout.\n\u003e This softer timeout is measurable in fractions of a second, e.g. units of\n\u003e 0.1 seconds.\n\u003e\n\u003e Each node on the network advertises, in addition to a block-based\n\u003e `cltv_delta`, a `timeout_delta` in units of 0.1 seconds.\n\u003e Further, each invoice contains, in addition to a block-based `final_cltv`,\n\u003e a `final_timeout` in units of 0.1 seconds.\n\u003e\n\u003e Thus, there are two timeouts:\n\u003e\n\u003e * The current \"hard\" block-based timeout that is enforceable onchain.\n\u003e * A new \"soft\" sidereal-time-based timeout that is not onchain enforceable.\n\u003e\n\u003e The soft timeout, as mentioned, is not enforceable onchain.\n\u003e Instead, enforcement of the soft timeout *is* the act of putting the\n\u003e channel state onchain.\n\u003e\n\u003e Now, for the current \"hard\" block-based timeout, we already have a\n\u003e reaction.\n\u003e If the HTLC \"hard\" timeout is approaching:\n\u003e\n\u003e * Drop the channel onchain and enforce the hard timeout onchain to reclaim\n\u003e the funds in the HTLCs.\n\u003e * Wait for the onchain action to be deeply resolved (either timelock or\n\u003e hashlock branch is confirmed deeply) and report the result (success or\n\u003e fail) upstream.\n\u003e\n\u003e What happens if the \"soft\" timeout is violated?\n\u003e\n\u003e * Drop the channel onchain.\n\u003e * Report the channel closure upstream.\n\u003e\n\u003e The \"hard\" timeout is cancelled in any of these two conditions:\n\u003e\n\u003e * A success is reported via `update_fulfill_htlc`, OR,\n\u003e * A failure is reported via `update_fail_htlc` AND the HTLC is irrevocably\n\u003e removed from the latest commitments/state(s) of the channel.\n\u003e\n\u003e The \"soft\" timeout is cancelled in any of these three conditions, the\n\u003e first two of which are the same as above:\n\u003e\n\u003e * A success is reported via `update_fulfill_htlc`, OR,\n\u003e * A failure is reported via `update_fail_htlc` AND the HTLC is irrevocably\n\u003e removed from the latest commitments/state(s) of the channel, OR\n\u003e * A channel closure is reported.\n\u003e\n\u003e Let us fill this in more detail.\n\u003e\n\u003e Suppose we have a payment route A-\u003eB-\u003eC-\u003eE.\n\u003e\n\u003e Both the \"hard\" block timeouts and the \"soft\" second timeouts decrement\n\u003e monotonically at each hop.\n\u003e Thus, the payee E has the shortest \"hard\" and \"soft\" timeouts (as normal).\n\u003e\n\u003e * Suppose E then delays claiming the payment and violates the \"soft\"\n\u003e timeout.\n\u003e * C then drops the CE channel onchain.\n\u003e * C reports, before its own timeout (slightly larger than the timeout\n\u003e imposed on E), the closing of the channel CE, to B.\n\u003e * B validates this report, and if valid, propagates the report to A.\n\u003e * A validates this report, and if valid, accepts that the payment will be\n\u003e \"stuck\" for up to the hard timeout it imposed on B.\n\u003e\n\u003e C has to report back to B in order to prevent B from closing the BC\n\u003e channel, and B has to report back to A in order to prevent A from closing\n\u003e the AB channel.\n\u003e The decrementing seconds-unit timeouts are needed for each hop, for the\n\u003e same reason that decrementing block-unit timeouts are needed.\n\u003e\n\u003e Since E is motivated to attack intermediate nodes because it wants to\n\u003e redirect payment forwards through itself rather than its competitotrs,\n\u003e having one of its channels closed (which prevents it from being used for\n\u003e forwarding) is directly opposed to its end goal of getting more money,\n\u003e thus, we can believe the action of closing a channel involved in a griefing\n\u003e attack is sufficient disincentive.\n\u003e\n\u003e The major drawback is that enforcement of the soft timeout *is* a channel\n\u003e closure, which is generally a negative for the network.\n\u003e This is not a remote attack vector, since a node can only trigger this\n\u003e closure if it is able to stall the fulfillment or failure of an HTLC on a\n\u003e channel, which generally means the node triggering this closure can only do\n\u003e so for its own channels (or it is able to, via a separate mechanism,\n\u003e remotely crash a different node).\n\u003e\n\u003e Proving Channel Closes\n\u003e ----------------------\n\u003e\n\u003e What C *really* needs to prove is that:\n\u003e\n\u003e * It is *willing* to close a channel due to a violation of the soft\n\u003e timeout.\n\u003e * The channel it is willing to close was, in fact, involved in the same\n\u003e payment attempt.\n\u003e\n\u003e With the above, B can believe that C was innocent of wrongdoing, because:\n\u003e\n\u003e * C would only be wiling to close a channel in case of a protocol\n\u003e violation, in this case, a violation of the soft timeout.\n\u003e * The channel it closed was closed because of this payment attempt, and\n\u003e not because of another payment attempt, or some other unrelated channel\n\u003e being unilaterally closed.\n\u003e\n\u003e First, what C needs to prove is *NOT*, in fact, actual channel closure: it\n\u003e needs to prove a *willingness* to close a channel.\n\u003e Thus, it does not require the channel to actually be *closed* yet, i.e. it\n\u003e does not have to wait for onchain activity that the channel closure is in a\n\u003e mempool and is confirmed deeply onchain etc etc.\n\u003e\n\u003e Thus, to prove a *willingness to close* rather than an actual close, C can\n\u003e provide the unilateral close of the channel CE.\n\u003e The act of unilaterally closing a channel is the publication of the\n\u003e transaction(s) making up the unilateral close.\n\u003e Thus, if C is *willing* to close the channel, it is willing to publish the\n\u003e transaction(s) involved, and thus, providing the unilateral close to B and\n\u003e further upstream, shows a willingness to close the channel.\n\u003e\n\u003e B then validates the provided proof-of-closure by checking that the\n\u003e unilateral close transaction is either onchain, in the mempool, or that it\n\u003e spends a TXO that is not currently spent by another transaction.\n\u003e In the case the unilateral close transaction is not confirmed and in the\n\u003e mempool, B can speed up its propagation on the Bitcoin layer by putting it\n\u003e in its own mempool as well --- after all, C is willing to close the channel\n\u003e to exonerate itself and punish the actual culprit, and B putting the\n\u003e unilateral close in its own mempool can only help C in what it is willing\n\u003e to do.\n\u003e\n\u003e Secondly, C needs to prove that the channel it is willing to close\n\u003e involves the payment attempt, and is not some other channel closure that it\n\u003e is attempting to use to fulfill its own soft timeout.\n\u003e Since the unilateral close transaction *is* the proof-of-closure, B (and\n\u003e A) can inspect the transaction outputs and see (with some additional data\n\u003e from C) that one of the outputs is to an HTLC that matches the payment hash.\n\u003e\n\u003e Thus, B (and A) can believe that the proof-of-closure proves that whoever\n\u003e is presenting it is free of wrongdoing, as whoever is actually causing the\n\u003e delay has been punished (by someone being willing to close a channel with\n\u003e the culprit), and that the proof-of-closure commits to this particular\n\u003e payment attempt and no other (because it commits to a particular payment\n\u003e hash).\n\u003e\n\u003e Further, if CE is closed by E dropping it onchain rather than C, C will\n\u003e still be able to fulfill its own soft timeout by taking the closing\n\u003e transaction from E, which should still contain the HTLC.\n\u003e Indeed, neither A nor B will particularly care (nor need to know) who\n\u003e dropped the channel onchain, or (for A) that the channel participants are C\n\u003e and E.\n\u003e\n\u003e Update State Shenanigans\n\u003e ------------------------\n\u003e\n\u003e Bitcoin update mechanisms are complicated things, and it may be possible\n\u003e for an attacking payee E to fool around with the update state machine to\n\u003e make it difficult for C to report a willingness to close CE.\n\u003e\n\u003e In particular, I quote here the relevant passages from `lightning-rfc`,\n\u003e `02-peer-protocol.md`, which is an implementation of the Poon-Dryja update\n\u003e mechanism:\n\u003e\n\u003e \u003e Thus each update traverses through the following states:\n\u003e \u003e\n\u003e \u003e 1. pending on the receiver\n\u003e \u003e 2. in the receiver's latest commitment transaction\n\u003e \u003e 3. ... and the receiver's previous commitment transaction has been\n\u003e revoked,\n\u003e \u003e    and the update is pending on the sender\n\u003e \u003e 4. ... and in the sender's latest commitment transaction\n\u003e \u003e 5. ... and the sender's previous commitment transaction has been revoked\n\u003e\n\u003e The payee E is the \"receiver\" in this context.\n\u003e\n\u003e In this case, once the update has reached step 2, then E has a commitment\n\u003e transaction that it can put onchain, that contains an HTLC it can claim.\n\u003e From this step onward, C cannot send a failure (i.e. it cannot send back\n\u003e an `update_fail_htlc`) back to B, because E could drop its latest\n\u003e commitment onchain and claim the HTLC onchain.\n\u003e\n\u003e However, until step 4, C does not have a unilateral close containing the\n\u003e HTLC, and thus cannot provide a proof-of-closure that contains an HTLC that\n\u003e refers to the payment.\n\u003e\n\u003e Thus, between steps 2 to 4, C cannot safely respond to its own soft\n\u003e timeout.\n\u003e C cannot respond with a failure, as E could then drop its latest\n\u003e commitment transaction onchain and claim the payment from C, and extract\n\u003e money from C that way.\n\u003e C also cannot respond with a proof-of-closure, as it does not have a\n\u003e transaction that it can use to provide this proof.\n\u003e\n\u003e The best that C can do would be to impose an even shorter timeout between\n\u003e steps 2 and 4 above, and to drop its current commitment transaction (which\n\u003e does not contain the HTLC yet and thus does not constitute a valid\n\u003e proof-of-closure) onchain.\n\u003e In between the time it drops the commitment transaction and its own\n\u003e incoming soft timeout, there is a chance, however small, that this\n\u003e transaction will be confirmed, and the channel will (with high probability)\n\u003e settle in a state where the HTLC is not instantiated, thus C can safely\n\u003e fail its incoming HTLC (not show a proof-of-closure, since that is not\n\u003e possible for C to do) without risk of loss, just prior to its own soft\n\u003e timeout.\n\u003e\n\u003e Of course, C is still at risk here: E could collude with miners via a\n\u003e side-channel fee offer to confirm its commitment transaction with the HTLC\n\u003e present, and ensure that C is liable for the HTLC value.\n\u003e\n\u003e With Decker-Russell-Osuntokun, we can remove this risk by requiring a\n\u003e ritual as follows:\n\u003e\n\u003e 1.  C requests exclusive access to update their single shared state.\n\u003e   * This can be done via a variety of sub-protocols, including a fair coin\n\u003e toss in case of near-simultaneous requests for exclusive locks on both\n\u003e sides.\n\u003e 2.  C provides the details of the new HTLC to E.\n\u003e 3.  C and E generate the new state transaction and exchange signatures for\n\u003e it.\n\u003e 4.  C and E generate (without signing) the new update transaction.\n\u003e 5.  E provides the signature (or share of signature, if MuSig) for the new\n\u003e update transaction to C.\n\u003e 6.  C provides the signature for the new update transaction to E, which\n\u003e releases the exclusive lock on the shared state atomically with the\n\u003e finalization of the new update transaction.\n\u003e\n\u003e Prior to step 5, C can simply fail the incoming HTLC from B in case its\n\u003e own soft timeout is near.\n\u003e Even if E performs step 5 after C has already failed the incoming HTLC\n\u003e from B, C can simply not perform step 6 and drop the channel onchain with\n\u003e the previous update and state transactions.\n\u003e\n\u003e With Poon-Dryja, we will have to rearrange the order in which we perform\n\u003e things, effectively adding an extra communications turnaround between the\n\u003e participants.\n\u003e Specifically, the order would have to be revised to:\n\u003e\n\u003e \u003e 1. pending on the sender\n\u003e \u003e 2. in the sender's latest commitment transaction\n\u003e \u003e 3. ... and the sender's previous commitment transaction has been revoked,\n\u003e \u003e    and the update is pending on the receiver\n\u003e \u003e 4. ... and in the receiver's latest commitment transaction\n\u003e \u003e 5. ... and the receiver's previous commitment transaction has been\n\u003e revoked\n\u003e\n\u003e This allows the sender (C in our context) to provide a proof-of-closure\n\u003e after step 2, and before step 2, C can safely return a failure with\n\u003e `update_fail_htlc` (and refuse to proceed beyond step 2, thus ensuring it\n\u003e can still use the previous commitment that still has no HTLC).\n\u003e\n\u003e Of course, this change will require redesigning the update state machine,\n\u003e increasing the number of communication turnarounds, and creating a subtle\n\u003e incompatbility when transitioning a payment from a hop that knows only the\n\u003e old update state machine to a hop that knows the new update state machine.\n\u003e\n\u003e Purely Falsified Proof-Of-Closure\n\u003e ---------------------------------\n\u003e\n\u003e Of course, the attacking node E might want to create a false\n\u003e proof-of-closure.\n\u003e E can do this by simulating a Lightning channel: lock an amount of funds\n\u003e in a 2-of-2 (where E controls both keys), then spend it in a set of\n\u003e transactions mimicking the unilateral close.\n\u003e\n\u003e We observe, however, that the overhead of simulating a Lightning channel\n\u003e is the same as the overhead of actually creating and closing a Lightning\n\u003e channel.\n\u003e Since the punishment of proof-of-closure is to force attackers to have\n\u003e their channels closed, we can consider that this simulation of a channel\n\u003e open and close is sufficient as well.\n\u003e\n\u003e Future-Proofing\n\u003e ---------------\n\u003e\n\u003e This sketch of proof-of-closure can be used for any update mechanism:\n\u003e\n\u003e * With Poon-Dryja, C can use its own commitment transaction as the\n\u003e proof-of-closure.\n\u003e * With Decker-Wattenhofer, C can give all the offchain transactions up to\n\u003e the last stage in the multi-stage decrementing-`nSequence` mechanism.\n\u003e * With Deckker-Russell-Osuntokun, C can give the latest update and state\n\u003e trnsaction.\n\u003e\n\u003e Basically, we expect that for now, and in the future, any update mechanism\n\u003e worth consideration will have a concept of \"unilateral close\" where a\n\u003e channel can be dropped onchain, using data that only one of the channel\n\u003e participants holds.\n\u003e\n\u003e Such a unilateral close will be a sequence of one or more valid\n\u003e transactions, terminating in a transaction containing an HTLC-like contract\n\u003e in one of its outputs.\n\u003e\n\u003e Thus, to validate the unilateral close, it is only required to validate\n\u003e all the transactions contained in the proof-of-closure, and see that the\n\u003e last transaction has an HTLC output.\n\u003e\n\u003e The limitations are thus:\n\u003e\n\u003e * The acceptable forms of HTLC would need to be agreed-upon by the entire\n\u003e network.\n\u003e * Implementations would need to be able to assess, in a\n\u003e Bitcoin-consensus-compatible way, whether a transaction is valid or not.\n\u003e\n\u003e Payment Decorrelation and Payment Points\n\u003e ----------------------------------------\n\u003e\n\u003e Of course, having a single payment hash for the entire payment attempt is\n\u003e a privacy loss, which we intend to fix in the near future by using payment\n\u003e points, and adding a blinding scalar at each hop, aka. payment\n\u003e decorrelation.\n\u003e\n\u003e Thus, in the future, there will not be any HTLC, but instead a PTLC.\n\u003e Further, the payment point at each hop will be changed at each hop, in\n\u003e order to prevent decorrelation.\n\u003e\n\u003e Thus, C needs to provide proofs:\n\u003e\n\u003e * That an apparent singlesig on the unilateral close output is in fact a\n\u003e PTLC.\n\u003e   C needs to provide:\n\u003e   * A target point P.\n\u003e   * A partial signature that would spend that singlesig for a particular\n\u003e sighash.\n\u003e   * An adaptor signature which, with knowledge of the completed signature,\n\u003e adaptor signature, and sighash message, would have revealed the scalar\n\u003e behind P.\n\u003e * That the PTLC belongs to the same payment attempt as what B offered to C.\n\u003e   C needs to provide:\n\u003e   * The C-only blinding factor that is the difference between the payment\n\u003e point of the B-to-C PTLC and the C-to-E PTLC on the unilateral close.\n\u003e\n\u003e Then, when B needs to propagate the proof-of-closure back to A, B simply\n\u003e adds its own blinding factor to the reported blinding factor, in order to\n\u003e convince A that this is the same payment attempt.\n\u003e\n\u003e As we have brought up privacy, we observe that, when this mechanism\n\u003e triggers, there is a mild privacy loss, in that intermediate nodes now know\n\u003e some channel closure that is related to this payment, and can thus\n\u003e determine the exact path that the payment attempt went through, at least\n\u003e until the channel being closed.\n\u003e However, proof-of-closure is only propagated in case of violation of the\n\u003e soft timeout, so for normal non-malicious payments, proof-of-closure does\n\u003e not cause any privacy loss.\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200401/082a44f1/attachment-0001.html\u003e"}