Re: [Lightning-dev] Griefing-Penalty: A proposal for mitigating Griefing Attack
up would be: > > * S->F has the contract, funded by S only: > * If F can reveal x such that h = h(x) for a known h, F can claim the > fund. > * After 2 days, S can recover the fund. > * F->R has the contract, funded by F only: > * If R can reveal x such that h = h(x) for a known h, R can claim the > fund. > * After 1 day, F can recover the fund. > > Then, 1 Planck interval before the 1-day limit, R cancels the HTLC by > doing some form of `update_fail_htlc` to F. > This causes F to not earn any funds, even though it had its funds locked > for 1 day minus 1 Planck interval; thus in practice, R can lock the funds > of F for a little less than the time limit imposed. > > > > With the Mitigating Reverse Griefing technique, the setup would be: > > * S->F has the contract, funded by S and F: > * If F can reveal x such that h = h(x) for a known h, F can claim the > fund. > * If F can reveal r such that y = h(r) for a known y, S and F can > recover their original contributions to the fund. > * After 2 days, S can claim the fund. > * F->R has the contract, funded by F and R: > * If R can reveal x such that h = h(x) for a known h, R can claim the > fund. > * If R can reveal r such that y = h(r) for a known y, F and R can > recover their original contributions to the fund. > * After 1 day, F can claim the fund. > > Then, 1 Planck interval before the 1-day limit, R uses the second clause > to cancel the entire payment. > > This is exactly the same result as with the current griefing attack: F is > induced to lock its funds for 1 day minus 1 Planck interval, but is never > compensated for it. > It is immaterial whether the mechanism used is `update_fail_htlc` or some > other mechanism. > > > So not only does Mitigating Reverse-Griefing just replace reverse-griefing > with the attack described in my previous post, which I am now calling > backflip-reverse-griefing (because calling it "reverse-reverse-griefing" > would be ***SO BORING AND OBVIOUS***), it also returns the original > griefing attack. > > > I think it is a principle of protocol design that, in general, protecting > against one attack could open you up to the opposite of that attack. > > > It is helpful to remember that the original griefing attack is basically a > withholding attack, wherein a participant does not respond after a > particular step in the protocol. > By adding more steps, you simply add more places where a participant can > stop responding after some step in the protocol, and thus add even more > attack surface. > > > Regards, > ZmnSCPxj > > -- Yours sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Griefing-Penalty: A proposal for mitigating Griefing Attack
longer before somebody forwards through them, and is generally paid > only a few dozen millisatoshi each time. > > > > 2. Note that this output again is encumbered by the RSMC (1000 block > relative confirmation times as stated in [1]) This means that it has to > wait for 1000 blocks after broadcasting the penalty transaction before it > can actually spend the output. > > I am unaware of any modern implementation that uses timelocks that large. > > > > > > 3. The fund locked in the contract, which acts as compensation in case > of misbehavior, is a substantial amount. Definitely, an intermediate party > won’t keep its funds unutilized and try to resolve payment as soon as > possible. > > Like I pointed out elsewhere, griefing attacks are attacks committed by > payer/payee conspiracies against forwarding nodes; we can disregard this > point since it applies to non-griefing-penalty (i.e. current Lightning) > just as well. > > > > 4. It leads to channel closure. Any operation performed on-chain is a > costly affair. A rational party will not prefer to close the channel. > > And like I pointed out, because any counterparty can close its channel > with you at any time, this risk can be discounted by the expected average > chance that a counterparty will close the channel for no reason. > Yes, to earn by reverse-griefing you can need to trigger the channel to be > closed, but even if you leave it open, there is a chance the counterparty > will close it for no reason it will bother to explain to you. > > > > > > > Thus an honest-rational party can earn in either of the two ways: > > > > 1. A fee for processing payments. > > > > 2. If affected by griefing attack, it gets compensated for the > collateral loss. > > > > > > > Given we route using onion routing, it would be trivial to create a > loop in the route so that the same node occurs twice in it, thus trivially > meeting the "at least two nodes in the path must be corrupted" requirement. > That is, the sender and the receiver can be the same node, making it appear > twice in the path. > > > > Our assumption that at most one party is corrupted under adversarial > model holds true for self-payment. Please refer to Corollary 1 of our > Security Analysis section in the paper. > > Okay. > > > > > > The solution should really prevent griefing without introducing any > reverse-griefing. > > > > To avoid reverse-griefing, we may add an extra round (as preprocessing > step) before initiating the lock phase. Additionally, the off-chain > contract might contain two hashes: one for normal payment and one for > error. Thanks to Rene Pickhardt for his suggestions. > > > Can you describe this in more detail? > > > Regards, > ZmnSCPj > -- Yours sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Griefing-Penalty: A proposal for mitigating Griefing Attack
ecting it to C, in the form A->B->C. A establishes an HTLC > with B, locking 1 msat in the contract having expiration time of say 2 > days. B after receiving the incoming contract, forms a contract with C, > locking 1 msat in the contract with locktime of 1 day. > > > > A->B-->C > > > > HTLC(1msat, 2 day) HTLC(1msat, 1 day) > > > > Now if C griefs, funds of A and B remain locked as they cannot resolve > HTLC. After an elapsed time of 1 day, the fund gets unlocked and B gets > back 1 msat. Similarly, B cancels contract with A after 1 day, A unlocks 1 > msat. The problem with this construction is that C doesn’t lose anything. > > > > Griefing-Penalty: a strategy to penalize the adversary > > > > Hence we have come up with the following idea: > > > > 1) An off-chain contract established between 2 parties requires both the > parties to lock funds – one party locking the amount that is to be > forwarded and the other party locking the fund which can be claimed as a > penalty, if this party griefs. > > > > 2) The penalty locked is proportional to the product of the amount being > forwarded and the expiration time of the contract. All the parties affected > by griefing must get compensation since their liquidity is tied up for a > certain period of time. > > > > Considering the example used for demonstrating griefing attack. We > modify the contract and term it as HTLC-GP (Hashed Timelock Contract with > Griefing Penalty). We assume a rate of penalty, say 0.01 per hour, for > calculating the penalty the party has to lock in order to accept an > off-chain contract request. > > > > A forwards the term of the contract to B, requesting B to lock > 0.01*1*48=0.48 msat as a penalty. A locks 1 msat in the contract, so the > total amount locked in the contract is 1.48 msat. In the same way, B > forwards the term of the contract to C, requesting C to lock 0.01*1*24=0.24 > msat as a penalty. B locks 1 msat in the contract, so the total amount > locked in the contract is 1.24 msat. If the payment is not resolved within > 1 day, all the parties who have forwarded the contract will claim the > penalty locked in the contract. > > > > > A-->B>C > > > > HTLC-GP(1.48 msat, 2 days) HTLC-GP(1.24 msat,1 day) > > > > If C releases the preimage before the expiration of locktime, it will > claim the full amount locked in the contract, i.e. 1.24 msat. Similarly, B > claims 1.48 msat from the contract established with A. > > > > Suppose C griefs. After an elapse of 1 day, B claims 1.24 msat from the > contract. C loses 0.24 msat. When B cancels contract with A, it will settle > by paying 1.48 msat to A. But then B loses an additional 0.24 msat. This is > not desired as B was not involved in mounting the attack. As per the > objective, even B should earn a remuneration as it got affected by griefing. > > > > Hence, B should have asked C to lock funds in the contract which can be > used for compensating both B and A. So C must lock 0.48 msat + 0.24 msat = > 0.72 msat. So if C griefs, now it loses 0.72 msat (proportional to the > collateral cost of the path). B pays 0.48 msat to A, keeping 0.24 msat with > itself as compensation. > > > > > A-->B>C > > > > HTLC-GP(1.48 msat, 2 days) HTLC-GP(1.72 msat,1 day) > > > > > A->B>C > (griefs) > > > > (A gain 0.48 msat) (B gain 0.24 msat) (C loses 0.72 > msat) > > > > -- > > Yours sincerely, > > Subhra Mazumdar. > > > -- Yours sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Griefing-Penalty: A proposal for mitigating Griefing Attack
->C HTLC-GP(1.48 msat, 2 days) HTLC-GP(1.72 msat,1 day) A->B>C (griefs) (A gain 0.48 msat) (B gain 0.24 msat) (C loses 0.72 msat) -- Yours sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Force close of channel with unresolved htlc
Hi, I am having a doubt regarding force closure of channel. Suppose A->B there is an htlc which has been established for transfering fund. Now suppose for some unfortunate reason B doesnt have the witness to resolve htlc and the mean time A suffers crash fault. Then can B close the channel given that it has no way out of resolving the htlc due to lack of witness? ___ 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
gt; > 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 > > > > > > > Lightning-dev@lists.linuxfoundation.org > > > > > > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > > -- > > Yours sincerely, > > Subhra Mazumdar. > > > -- Yours sincerely, Subhra Mazumdar. ___ 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
f-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 > > > > > Lightning-dev@lists.linuxfoundation.org > > > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > -- Yours sincerely, Subhra Mazumdar. ___ 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
(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 > > > > > Lightning-dev@lists.linuxfoundation.org > > > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > -- Yours sincerely, Subhra Mazumdar. ___ 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
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
Re: [Lightning-dev] Blind paths revisited
w idiotically refusing to claim money. > > > > > > Grief attacks are attacks by payers and payees on intermediate nodes > (S and R attacking A,B,C,D,E,F), and in that case the entire payment secret > would be known by both S and R anyway. > > > > > > So S and B cannot cooperate to perform a griefing attack on the path. > > > > > > Regards, > > > ZmnSCPxj > > > > > > > > > > > On Wed, Apr 1, 2020 at 10:39 PM ZmnSCPxj > wrote: > > > > > > > > > Good morning Subhra, > > > > > > > > > > > Commenting on it : "As for ZmnSCPxj's suggestion, I think there > is the same kind of issue. > > > > > > The secrets we establish with anonymous multi-hops locks are > between the *sender* > > > > > > and each of the hops. In the route blinding case, what we're > adding are secrets > > > > > > between the *recipient* and the hops, and we don't want the > sender to be able to > > > > > > influence those." > > > > > > Is it a good idea to rely entirely on the sender for sampling > the secrets as well as generating the PTLC? As happens in anonymous > multi-hops locks, for example. Or as it has been discussed later in the > thread, both receiver and sender must be involved in creation of PTLC? What > happens if sender/receiver is/(or both are) corrupted? Can it leak secrets > to other parties? > > > > > > > > > > If both are corrupted, this brings up the question: who are you > hiding any information from? > > > > > The corruptor has already corrupted both: there is no security or > privacy possible, the payment is already totally compromised. > > > > > > > > > > The operation of forwarding nodes is simple enough that in general > they cannot be attacked: sure, the sender and receiver together knows who > they are, but forwarding nodes are the ones who advertise themselves in > order to be forwarded through, so they already are known anyway. > > > > > > > > > > When considering privacy, we should always consider that it is the > payment as a whole which we want to have privacy: we want that third > parties will not be able to nail down which particular sender sent to which > particular receiver. > > > > > Thus if the sender already leaks who it is paying to, that is > pretty much the entire loss of privacy. > > > > > > > > > > Now, currently on Lightning, in general the receiver does not know > the sender node. > > > > > (Applications on top of Lightning might have the receiver require > the sender to provide private data, such as a drop point to send a physical > product to, but *looking only on Lightning* the sender does not send any of > its information to the receiver). > > > > > > > > > > However, currently, the exact receiver node has to be known by the > sender, in order for the sender to make a route to it. > > > > > This is a concern since it may be possible for layer-crossing > shenanigans to be performed, for example the sender might attempt to > eclipse the receiver on the Bitcoin blockchain layer and make it lose funds > by not realizing that a PTLC/HTLC has been timed out (because the eclipse > attack prevents new blocks from propagating to the receiver, who blithely > continues to think that the timeout has not been reached when in fact it > has). > > > > > > > > > > The proposal to have a receiver provide a partial, blinded path > gives the receiver better privacy protection against the sender: the sender > knows it is one of a possible number of nodes within some number of hops > from a particular node, but does not know if it is that exact node, one of > its neighbors, or one of its neighbor neighbors (etc.) is the actual > receiver. > > > > > This should make it harder for the sender to attack the receiver > by attempting to locate its node and eclipse it at the Bitcoin layer, or > other blockchain-layer shenanigans. > > > > > > > > > > Now, the argument I make is that while the blinding factors in a > decorrelated PTLC-based payment may be generated by the sender in order for > the sender to have path privacy, it is safe for the receiver to provide > blinding factors to a partial path as well. > > > > > We should remember that the blinding factors are just scalars > added to the final point/scalar at the ultimate recipient, and the final > point/scalar pair is completely controlled by the recipient anyway, so it > should not be an issue here: the point that the sender will target at the > first node in the receiver-provided partial route is no different from the > final point that the sender would have targeted if it knew exactly who the > receiver is. > > > > > > > > > > Regards, > > > > > ZmnSCPxj > > > > > > > > -- > > > > Yours sincerely, > > > > Subhra Mazumdar. > > > > -- > > Yours sincerely, > > Subhra Mazumdar. > > > -- Yours sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Blind paths revisited
for example. Or as it has been discussed later in the thread, both > receiver and sender must be involved in creation of PTLC? What happens if > sender/receiver is/(or both are) corrupted? Can it leak secrets to other > parties? > > > > > > If both are corrupted, this brings up the question: who are you hiding > any information from? > > > The corruptor has already corrupted both: there is no security or > privacy possible, the payment is already totally compromised. > > > > > > The operation of forwarding nodes is simple enough that in general > they cannot be attacked: sure, the sender and receiver together knows who > they are, but forwarding nodes are the ones who advertise themselves in > order to be forwarded through, so they already are known anyway. > > > > > > When considering privacy, we should always consider that it is the > payment as a whole which we want to have privacy: we want that third > parties will not be able to nail down which particular sender sent to which > particular receiver. > > > Thus if the sender already leaks who it is paying to, that is pretty > much the entire loss of privacy. > > > > > > Now, currently on Lightning, in general the receiver does not know the > sender node. > > > (Applications on top of Lightning might have the receiver require the > sender to provide private data, such as a drop point to send a physical > product to, but *looking only on Lightning* the sender does not send any of > its information to the receiver). > > > > > > However, currently, the exact receiver node has to be known by the > sender, in order for the sender to make a route to it. > > > This is a concern since it may be possible for layer-crossing > shenanigans to be performed, for example the sender might attempt to > eclipse the receiver on the Bitcoin blockchain layer and make it lose funds > by not realizing that a PTLC/HTLC has been timed out (because the eclipse > attack prevents new blocks from propagating to the receiver, who blithely > continues to think that the timeout has not been reached when in fact it > has). > > > > > > The proposal to have a receiver provide a partial, blinded path gives > the receiver better privacy protection against the sender: the sender knows > it is one of a possible number of nodes within some number of hops from a > particular node, but does not know if it is that exact node, one of its > neighbors, or one of its neighbor neighbors (etc.) is the actual receiver. > > > This should make it harder for the sender to attack the receiver by > attempting to locate its node and eclipse it at the Bitcoin layer, or other > blockchain-layer shenanigans. > > > > > > Now, the argument I make is that while the blinding factors in a > decorrelated PTLC-based payment may be generated by the sender in order for > the sender to have path privacy, it is safe for the receiver to provide > blinding factors to a partial path as well. > > > We should remember that the blinding factors are just scalars added to > the final point/scalar at the ultimate recipient, and the final > point/scalar pair is completely controlled by the recipient anyway, so it > should not be an issue here: the point that the sender will target at the > first node in the receiver-provided partial route is no different from the > final point that the sender would have targeted if it knew exactly who the > receiver is. > > > > > > Regards, > > > ZmnSCPxj > > > > -- > > Yours sincerely, > > Subhra Mazumdar. > > > -- Yours sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Blind paths revisited
Hi ZmnSCPxj, Thanks for the explanation. Pardon my knowledge in this domain but what I meant is that sender has malicious intent and wants honest parties to suffer. So by leaking secrets, I meant not revealing its or receiver's identity to the forwarding nodes, but somehow manipulating subset of the nodes so that an attack can be launched in the network. For example, consider path S->A->B->C->D->E->F->R. If we consider the protocol anonymous multihop lock, S samples secret x_a,x_b,x_c,x_d,x_e,x_f for the nodes A,B,C,D,E and F respectively. R gets the key k=x_a+x_b+x_c+x_d+x_e+x_f. If S colludes with B (possibly leak the value x_c,x_d,x_e,x_f to B), lock funds C,D,E but then not allowing it to relay funds (possibly do a griefing attack?). What I meant is that if one totally relies on S for the setup phase, won't it lead to other vulnerabilities? The situation might sound unrealistic but I still have doubt whether we guarantee fairness if put our trust entirely on one single entity. On Wed, Apr 1, 2020 at 10:39 PM ZmnSCPxj wrote: > Good morning Subhra, > > > Commenting on it : "As for ZmnSCPxj's suggestion, I think there is the > same kind of issue. > > The secrets we establish with anonymous multi-hops locks are between the > *sender* > > and each of the hops. In the route blinding case, what we're adding are > secrets > > between the *recipient* and the hops, and we don't want the sender to be > able to > > influence those." > > Is it a good idea to rely entirely on the sender for sampling the > secrets as well as generating the PTLC? As happens in anonymous multi-hops > locks, for example. Or as it has been discussed later in the thread, both > receiver and sender must be involved in creation of PTLC? What happens if > sender/receiver is/(or both are) corrupted? Can it leak secrets to other > parties? > > If both are corrupted, this brings up the question: who are you hiding any > information from? > The corruptor has already corrupted both: there is no security or privacy > possible, the payment is already totally compromised. > > The operation of forwarding nodes is simple enough that in general they > cannot be attacked: sure, the sender and receiver together knows who they > are, but forwarding nodes are the ones who advertise themselves in order to > be forwarded through, so they already are known anyway. > > When considering privacy, we should always consider that it is the payment > as a whole which we want to have privacy: we want that third parties will > not be able to nail down which particular sender sent to which particular > receiver. > Thus if the sender already leaks who it is paying to, that is pretty much > the entire loss of privacy. > > Now, currently on Lightning, in general the receiver does not know the > sender node. > (Applications on top of Lightning might have the receiver require the > sender to provide private data, such as a drop point to send a physical > product to, but *looking only on Lightning* the sender does not send any of > its information to the receiver). > > However, currently, the exact receiver node has to be known by the sender, > in order for the sender to make a route to it. > This is a concern since it may be possible for layer-crossing shenanigans > to be performed, for example the sender might attempt to eclipse the > receiver on the Bitcoin blockchain layer and make it lose funds by not > realizing that a PTLC/HTLC has been timed out (because the eclipse attack > prevents new blocks from propagating to the receiver, who blithely > continues to think that the timeout has not been reached when in fact it > has). > > The proposal to have a receiver provide a partial, blinded path gives the > receiver better privacy protection against the sender: the sender knows it > is one of a possible number of nodes within some number of hops from a > particular node, but does not know if it is that exact node, one of its > neighbors, or one of its neighbor neighbors (etc.) is the actual receiver. > This should make it harder for the sender to attack the receiver by > attempting to locate its node and eclipse it at the Bitcoin layer, or other > blockchain-layer shenanigans. > > Now, the argument I make is that while the blinding factors in a > decorrelated PTLC-based payment may be generated by the sender in order for > the sender to have path privacy, it is safe for the receiver to provide > blinding factors to a partial path as well. > We should remember that the blinding factors are just scalars added to the > final point/scalar at the ultimate recipient, and the final point/scalar > pair is completely controlled by the recipient anyway, so it should not be > an issue here: the point that the s
Re: [Lightning-dev] Blind paths revisited
Commenting on it : "As for ZmnSCPxj's suggestion, I think there is the same kind of issue. The secrets we establish with anonymous multi-hops locks are between the *sender* and each of the hops. In the route blinding case, what we're adding are secrets between the *recipient* and the hops, and we don't want the sender to be able to influence those." Is it a good idea to rely entirely on the sender for sampling the secrets as well as generating the PTLC? As happens in anonymous multi-hops locks, for example. Or as it has been discussed later in the thread, both receiver and sender must be involved in creation of PTLC? What happens if sender/receiver is/(or both are) corrupted? Can it leak secrets to other parties? On Wed, Mar 11, 2020 at 9:57 PM Bastien TEINTURIER via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Good morning list, > > Thanks Rusty for following up on this, I'm glad it may be useful for > offers! > I certainly want this as well for wallet users' privacy. > > I have gathered my proposal in a better format than my previous gist here: > > https://github.com/lightningnetwork/lightning-rfc/blob/route-blinding/proposals/route-blinding.md > > You will note that I've been able to simplify the scheme a bit compared to > my > gist. It's now very clear that this is exactly the same kind of secrets > derivation than what Sphinx does. I still have things I want to add to the > proposal, but at least the crypto part should be ready to review (and I > think > it does need more eyes on it). > > Feel free to add comments directly on the branch commits, it may be easier > to > review that way. Let me know if you think I should turn it into a draft PR > to > facilitate discussions. It kept it vague on some specific parts on purpose > (such as invoice fields, encrypted blob format); we will learn from early > prototype implementations and enrich the proposal as we go. > > A few comments on your previous mails. I have removed the (ab)use of > `payment_secret`, but I think your comment on using the `blinding` to > replace > it would not work because that blinding is known by the next-to-last node > (which computes it and forwards it to the final node). > The goal of `payment_secret` is explicitly to avoid having the > next-to-last node > discover it to prevent him from probing. But I think that you didn't plan > on > doing the blinding the same way I'm doing it, which may explain the > difference. > > As for ZmnSCPxj's suggestion, I think there is the same kind of issue. > The secrets we establish with anonymous multi-hops locks are between the > *sender* > and each of the hops. In the route blinding case, what we're adding are > secrets > between the *recipient* and the hops, and we don't want the sender to be > able to > influence those. It's a kind of reverse Sphinx. So I'm not sure yet the > recipient > could safely contribute to those secrets, but maybe we'll find a nice > trick in > the future! > > Cheers, > Bastien > > Le mer. 11 mars 2020 à 00:22, Rusty Russell a > écrit : > >> ZmnSCPxj writes: >> > Good morning Rusty, et al., >> > >> > >> >> Note that this means no payment secret is necessary, since the incoming >> >> `blinding` serves the same purpose. If we wanted to, we could (ab)use >> >> payment_secret as the first 32-bytes to put in Carol's enc1 (i.e. it's >> >> the ECDH for Carol to decrypt enc1). >> > >> > I confess to not reading everything in detail, but it seems to me that, >> with payment point + scalar and path decorrelation, we need to establish a >> secret with each hop anyway (the blinding scalar for path decorrelation), >> so if you need a secret per hop, possibly this could be reused as well? >> >> Indeed, this could be used the same way, though for that secret it can >> simply be placed inside the onion rather than passed alongside. >> >> Cheers, >> Rusty. >> ___ >> Lightning-dev mailing list >> Lightning-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -- Yours sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Difference between ignoring htlc request due to wrong payment hash vs refusing to release preimage in LND
Hi ZmnSCPxj, Thank you for the explanation. So I went through BOLT 04 specification and quoting a few error possibilities: An *intermediate hop* MUST NOT, but the *final node*: - if the payment_secret doesn't match the expected value for that payment_hash, or the payment_secret is required and is not present: - MUST fail the HTLC. - MUST return an incorrect_or_unknown_payment_details error. - if the payment hash is unknown: - MUST fail the HTLC. - MUST return an incorrect_or_unknown_payment_details error. So it is the final node which is expected to fail the htlc in these 2 cases. But then what if final node denies revealing the secret? Say in the scenario A->B->C->D, D doesn't reveal the secret. So in such a case, what is C supposed to do? Shall it resort to condition no. 1( secret doesn't match), generate an error message and unlock funds of A->B and B->C as soon as possible? On Tue, Mar 24, 2020 at 4:57 PM ZmnSCPxj wrote: > Good morning Subhra, > > > Another question related to the paper https://arxiv.org/abs/2003.3. > Over here, it is stated in page 13, "Surge of unresolved HTLCs while > probing: Recalling steps 5-7 in Figure 4, each probe sets up a chain of > irredeemable HTLCs (since a matching preimage would have to be > brute-forced). Eventually, running multiple probes over the same channels > will escrow its funds in these HTLCs, effectively DOSing the probe route > and forcing the nodes to wait until the HTLCs time out before being able to > forward other payments. This is an issue we encountered over and over > during 4.2 and 4.3, often giving us one shot at probing before having to > wait multiple hours for the HTLCs to expire. This is also why we chose the > channels leading up to our final target to have a much higher balance, so > that we would have enough.." So there was no matching preimage with > receiver as per Fig 4. So that means in the route say A->B->C->D, if D > doesn't have a matching preimage and suppose C->D uses lock time of 144 > blocks, B->C 288 blocks and A->B uses a locktime of 432 blocks, so won't be > the case funds in A->B and B->C still remains locked for the mentioned > locktime? > > It is helpful to remember that inside a channel, every contract has an > implicit branch "if both of us in this channel agree, we can spend this > contract funds any way we want". > > This is because every contract is dependent on a transaction spending from > a 2-of-2, and both parties can always sign a new 2-of-2 transaction without > that contract --- it is just that both have to agree to do this. > > In case of a reported failure, the receiving node in the channel basically > says "just between the two of us, I will not be able to claim this HTLC > using the hashlock branch anyway because , so > this will inevitably be claimable to you in the timelock anyway, so we > might as well just agree to re-assign the HTLC funds back to you right now". > > The sending node is then willing to sign off on this > outside-of-the-contract agreement, since it lets it get the funds back > before the timelock expires, and to reuse those funds otherwise. > > Thus, even if D griefs up to 143 blocks it wants, at the 144th block C can > report immediately back to B and then A with the above failure mechanism. > > B and C are incentivized to do this quickly since it would allow the funds > to be reused again in a different, probably-will-not-be-griefed near-future > payment, which might earn them fees in the future. > > Thus if B and C are not controlled by the A+D conglomerate then they have > no incentive to extend the griefing attack further. > > Of course, if either B or C is offline at the time, then the new state > where the HTLC is removed out-of-contract is not possible to sign with both > parties. > > > I know this is not the definition of griefing attack but then can this > possibly mimic the situation where receiver denies having the correct > preimage? > > No, since B and C are incentivized to report this immediately in order to > free up the funds in order for them to forward "soon". > > Regards, > ZmnSCPxj > > -- Yours sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Difference between ignoring htlc request due to wrong payment hash vs refusing to release preimage in LND
Another question related to the paper https://arxiv.org/abs/2003.3.
Over here, it is stated in page 13, "Surge of unresolved HTLCs while
probing: Recalling steps 5-7 in Figure 4, each probe sets up a chain of
irredeemable HTLCs (since a matching preimage would have to be
brute-forced). Eventually, running multiple probes over the same channels
will escrow its funds in these HTLCs, effectively DOSing the probe route
and forcing the nodes to wait until the HTLCs time out before being able to
forward other payments. This is an issue we encountered over and over
during 4.2 and 4.3, often giving us one shot at probing before having to
wait multiple hours for the HTLCs to expire. This is also why we chose the
channels leading up to our final target to have a much higher balance, so
that we would have enough.." So there was no matching preimage with
receiver as per Fig 4. So that means in the route say A->B->C->D, if D
doesn't have a matching preimage and suppose C->D uses lock time of 144
blocks, B->C 288 blocks and A->B uses a locktime of 432 blocks, so won't be
the case funds in A->B and B->C still remains locked for the mentioned
locktime? I know this is not the definition of griefing attack but then can
this possibly mimic the situation where receiver denies having the correct
preimage?
On Tue, Mar 24, 2020 at 1:57 PM ZmnSCPxj wrote:
> Good morning Subhra,
>
> > Hi,
> > I was just playing around with LND and established a channel between
> 2 parties A and B. When sending a payment to B via HTLC, B adds an invoice
> and over here I used a different payment hash for A for sendpayment with a
> delta of 144 blocks. The error I got on initiating send payment is
> "incorrect or unknown payment details". So what is exactly happening here?
> Is B ignoring any formation of HTLC between them?
>
> A and B form an HTLC in them, to the point that it is "irrevocably
> committed".
> It is a recommendation of BOLT spec that you pretty much do not do
> anything until an incoming HTLC reaches "irrevocably committed" state.
>
> Then, B looks at the HTLC data.
> If B knows the preimage to the payment hash, it claims the HTLC
> immediately as soon as it is irrevocably committed.
>
> If B does not know the preimage, it checks if there is forwarding data.
> If there is no forwarding data (B is the final hop) then B responds with
> "incorrect or unknown payment details", then A waits for the channel state
> to advance so that the HTLC getting removed reaches "irrevocably
> committed", then reports the failure to the user.
>
> > I hope in this case no money gets locked in this case.
>
> Money got locked temporarily int the HTLC, but was freed very soon
> afterwards, as fast as B and A can advance the channel state (which is
> limited by your hardware and network speeds).
>
>
> > Then how can one mimic griefing attack scenario (B refusing to release
> the correct preimage) in LND?
>
> You may need to modify LND code directly, or ask LND devs if there are any
> such hooks available.
>
> In C-Lightning, you will have to install a plugin, devise some way for the
> plugin to know of what payment hash you want to grief, then have the plugin
> hook into `htlc_accepted`.
> In `htlc_accepted` handler, if the incoming HTLC has a payment hash
> matching what you want to grief, you then perform a `waitblockheight`
> command to wait for the target block height you want to grief for, then
> return from the `htlc_accepted` handler.
> (This can be complicated by the exact language you use to implement the
> plugin, remember the plugin should be async so it should still respond with
> `{"result":"continue"}` immediately to other incoming `htlc_accepted` as
> normal, if you implement the plugin in Python the Python C-Lightning plugin
> library should "just work" as far as I know as it transforms the Python
> into an async language, but ask cdecker for that; but if you have a
> sufficiently monadic framework for asynchronicity (a la Javascript
> `Promise`/Haskell `IO`) it should work like that.)
>
> Regards,
> ZmnSCPxj
>
--
Yours sincerely,
Subhra Mazumdar.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Difference between ignoring htlc request due to wrong payment hash vs refusing to release preimage in LND
Thanks ZmnSCPxj. Just a clarification on the idea proposed so that means
here B needs to delay the HTLC acceptance? Pardon my knowledge on
c-lightning, but what exactly happens upon htlc_acceptance? Release of
preimage or just an acknowledgment by B reaching to the point of
irrevocably committed?
On Tue, Mar 24, 2020 at 1:57 PM ZmnSCPxj wrote:
> Good morning Subhra,
>
> > Hi,
> > I was just playing around with LND and established a channel between
> 2 parties A and B. When sending a payment to B via HTLC, B adds an invoice
> and over here I used a different payment hash for A for sendpayment with a
> delta of 144 blocks. The error I got on initiating send payment is
> "incorrect or unknown payment details". So what is exactly happening here?
> Is B ignoring any formation of HTLC between them?
>
> A and B form an HTLC in them, to the point that it is "irrevocably
> committed".
> It is a recommendation of BOLT spec that you pretty much do not do
> anything until an incoming HTLC reaches "irrevocably committed" state.
>
> Then, B looks at the HTLC data.
> If B knows the preimage to the payment hash, it claims the HTLC
> immediately as soon as it is irrevocably committed.
>
> If B does not know the preimage, it checks if there is forwarding data.
> If there is no forwarding data (B is the final hop) then B responds with
> "incorrect or unknown payment details", then A waits for the channel state
> to advance so that the HTLC getting removed reaches "irrevocably
> committed", then reports the failure to the user.
>
> > I hope in this case no money gets locked in this case.
>
> Money got locked temporarily int the HTLC, but was freed very soon
> afterwards, as fast as B and A can advance the channel state (which is
> limited by your hardware and network speeds).
>
>
> > Then how can one mimic griefing attack scenario (B refusing to release
> the correct preimage) in LND?
>
> You may need to modify LND code directly, or ask LND devs if there are any
> such hooks available.
>
> In C-Lightning, you will have to install a plugin, devise some way for the
> plugin to know of what payment hash you want to grief, then have the plugin
> hook into `htlc_accepted`.
> In `htlc_accepted` handler, if the incoming HTLC has a payment hash
> matching what you want to grief, you then perform a `waitblockheight`
> command to wait for the target block height you want to grief for, then
> return from the `htlc_accepted` handler.
> (This can be complicated by the exact language you use to implement the
> plugin, remember the plugin should be async so it should still respond with
> `{"result":"continue"}` immediately to other incoming `htlc_accepted` as
> normal, if you implement the plugin in Python the Python C-Lightning plugin
> library should "just work" as far as I know as it transforms the Python
> into an async language, but ask cdecker for that; but if you have a
> sufficiently monadic framework for asynchronicity (a la Javascript
> `Promise`/Haskell `IO`) it should work like that.)
>
> Regards,
> ZmnSCPxj
>
--
Yours sincerely,
Subhra Mazumdar.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Difference between ignoring htlc request due to wrong payment hash vs refusing to release preimage in LND
Hi, I was just playing around with LND and established a channel between 2 parties A and B. When sending a payment to B via HTLC, B adds an invoice and over here I used a different payment hash for A for sendpayment with a delta of 144 blocks. The error I got on initiating send payment is "incorrect or unknown payment details". So what is exactly happening here? Is B ignoring any formation of HTLC between them? I hope in this case no money gets locked in this case. Then how can one mimic griefing attack scenario (B refusing to release the correct preimage) in LND? -- Yours sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Locking of funds by both parties in HTLC to enforce penalty
So that means if we follow a right to left approach for establishing HTLC i.e. from B to C first then A to B, is there a chance? But I guess that's doesn't sound logical. Also the point raised by you is valid. B can never be punished if it is not possessing the secret at the point of establishment of HTLC. So in that case this becomes a challenge, A to B , B to A atomicity. What if A to B HTLC is established but B to A there is no contract. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Locking of funds by both parties in HTLC to enforce penalty
Can you send the draft on fair atomic swap? Also the scenario stated in the pdf you have shared is based on exchange of asset. But here I am not trying to work on different ledger A to B and B to A. Here it deals with just simple transfer of funds from A to B. So whatever HTLC A establishes with B, is it not the case where just one HTLC from A to B is enough? Why do we need another HTLC to be established from B to A ? To clarify this, we have two situation - 1. HTLC A & B (on channel AB): both A and B lock say 0.1 BTC each i.e. 0.2 BTC 2. HTLC A (on channel AB) : A locks 0.1 BTC, HTLC B (on channel BA): B locks 0.1 BTC Pardon me if I am wrong but I am still confused why situation 1 will not be possible ? On Fri, Mar 6, 2020 at 12:00 PM Lloyd Fournier wrote: > Hi Subhra, > > Afaik, the only problem is the one you identified, it doesn't work across > multiple hops but only for the final hop. This penalty idea is the basis > for doing atomc swaps fairly: > https://coblox.tech/docs/financial_crypto19.pdf > > LL > On Fri, Mar 6, 2020 at 4:58 PM Subhra Mazumdar < > subhra.mazumdar1...@gmail.com> wrote: > >> Hi, >> I was reading the paper by Poon and Dryja on Bitcoin Lightning >> Network and was going through the construction of HTLC. Suppose 2 parties A >> and B have a channel with each party locking 0.5 BTC. Suppose A wants to >> transfer 0.1 BTC to B contingent to the knowledge of R : H=h(R) produced >> within a locktime of say t days. So the script output for A is - >> 1. 0.4 BTC to A >> 2. 0.5 BTC to B >> 3. 0.1 BTC locked in HTLC between A & B. >> Why we cannot set the terms as say 0.4 BTC to A, 0.2 BTC to B and 0.4 BTC >> to HTLC, where HTLC output can follow either of the paths - If B produces R >> within t days then it gets back 0.4 BTC else after t days A can broadcast >> with 0.4 BTC going to the A? This prevents B from not responding (and >> induce possibly griefing attack across a longer path by withholding the >> solution) since it will lose out 0.3 BTC. What can be the problem if the >> terms of HTLC itself tries to enforce a penalty on the counterparty? >> >> -- >> Yours sincerely, >> Subhra Mazumdar. >> >> _______ >> Lightning-dev mailing list >> Lightning-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > -- Yours sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Locking of funds by both parties in HTLC to enforce penalty
But wont the decision of penalty be based on what incoming contract expects from a node ? Suppose there is a contract between A and B and then B and C, where A wants to transfer money to C. So if it is the case that A impose penalty on B using its local HTLC, won't B put the same clause on C as well so that in case C misbehaves it is able to spool out the penalty for the rest of the path from C itself ? On Fri, Mar 6, 2020 at 12:00 PM Lloyd Fournier wrote: > Hi Subhra, > > Afaik, the only problem is the one you identified, it doesn't work across > multiple hops but only for the final hop. This penalty idea is the basis > for doing atomc swaps fairly: > https://coblox.tech/docs/financial_crypto19.pdf > > LL > On Fri, Mar 6, 2020 at 4:58 PM Subhra Mazumdar < > subhra.mazumdar1...@gmail.com> wrote: > >> Hi, >> I was reading the paper by Poon and Dryja on Bitcoin Lightning >> Network and was going through the construction of HTLC. Suppose 2 parties A >> and B have a channel with each party locking 0.5 BTC. Suppose A wants to >> transfer 0.1 BTC to B contingent to the knowledge of R : H=h(R) produced >> within a locktime of say t days. So the script output for A is - >> 1. 0.4 BTC to A >> 2. 0.5 BTC to B >> 3. 0.1 BTC locked in HTLC between A & B. >> Why we cannot set the terms as say 0.4 BTC to A, 0.2 BTC to B and 0.4 BTC >> to HTLC, where HTLC output can follow either of the paths - If B produces R >> within t days then it gets back 0.4 BTC else after t days A can broadcast >> with 0.4 BTC going to the A? This prevents B from not responding (and >> induce possibly griefing attack across a longer path by withholding the >> solution) since it will lose out 0.3 BTC. What can be the problem if the >> terms of HTLC itself tries to enforce a penalty on the counterparty? >> >> -- >> Yours sincerely, >> Subhra Mazumdar. >> >> ___ >> Lightning-dev mailing list >> Lightning-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > -- Yours sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Locking of funds by both parties in HTLC to enforce penalty
Hi, I was reading the paper by Poon and Dryja on Bitcoin Lightning Network and was going through the construction of HTLC. Suppose 2 parties A and B have a channel with each party locking 0.5 BTC. Suppose A wants to transfer 0.1 BTC to B contingent to the knowledge of R : H=h(R) produced within a locktime of say t days. So the script output for A is - 1. 0.4 BTC to A 2. 0.5 BTC to B 3. 0.1 BTC locked in HTLC between A & B. Why we cannot set the terms as say 0.4 BTC to A, 0.2 BTC to B and 0.4 BTC to HTLC, where HTLC output can follow either of the paths - If B produces R within t days then it gets back 0.4 BTC else after t days A can broadcast with 0.4 BTC going to the A? This prevents B from not responding (and induce possibly griefing attack across a longer path by withholding the solution) since it will lose out 0.3 BTC. What can be the problem if the terms of HTLC itself tries to enforce a penalty on the counterparty? -- Yours sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Reduce the amount of collateral locked by scripts for transferring funds in lightning network
e as well. > > > In any case, from a skim of the AMCU paper, it looks like all the > intermediate hops *need* to validate that all the *other* intermediate hops > follow the protocol, by presenting all the transactions involved. > This probably implies that all the intermediate hops know the entire > route, and thus who the ultimate sender and receiver are, thus utterly bad > for privacy. > Hopefully my reading is wrong, or this is fixable, but if neither, it is > unlikely to be used in Lightning. > > > Regards, > ZmnSCPxj > > > Hi ZmnSCPxj, > > It is stated in the paper "Atomic multi-channel updates with > constant collateral in bitcoin-compatible payment-channel networks" and I > am quoting verbatim (page 11) (last email still waiting moderator approval) > "Phase I: Setup. The first phase requires to freeze the coins available at > each channel involved in the protocol. Doing this naively (i.e., locking > the complete balance in the channel at once) would lock more coins than > required, unnecessarily increasing the collateral in the protocol. Instead, > during the setup phase, the balance at each payment channel is split in > two, effectively creating thereby two sub-channels: one sub-channel is set > with the coins required for the present protocol session, while the other > one is set with the > > remaining coins, which can then be freely spent. In the illustrative > example shown in Figure 4.2, the setup phase starts with the user A > collaborating with user B to create the transaction Tx A > > setup , where they split the 10 coins they have in the channel in two > sub-channels: one sub-channel with 8 coins to be used in the rest of the > protocol session and one sub-channel with the rest (i.e., 2 coins). This > transaction is signed by both users so that it can be eventually enforced > on-chain if required. The rest of the users behave analogously. Note that > operations at each channel in this phase of the protocol can be carried out > in parallel." Does this sound good ? > > > > On Mon, Jan 27, 2020 at 9:41 AM Subhra Mazumdar < > subhra.mazumdar1...@gmail.com> wrote: > > > > > Hi ZmnSCPxj, > > >It is stated in the paper "Atomic multi-channel updates with > constant collateral in bitcoin-compatible payment-channel networks". I am > attaching the screenshot of the paragraph which mentions about locking the > amount which is required for payment transfer and not the entire channel > fund. > > > > > > On Mon, Jan 27, 2020 at 6:15 AM ZmnSCPxj > wrote: > > > > > > > Good morning Subhra, > > > > > > > > This does not seem to make sense? > > > > For a payment that is less than the channel funds on your side, only > that amount is locked behind an HTLC, and the rest remains useable for > other HTLCs. > > > > > > > > What exactly are you referring to? > > > > > > > > Regards, > > > > ZmnSCPxj > > > > > > > > > Hi, > > > > > I was wondering when parties apply condition on fraction of > channel fund for ensuring successful payment, entire channel fund is held. > Is it possible to lock just partial amount of fund of a payment channel and > leave the rest to be used by some another payment request ? Concept of > subchannels of a single channel has been suggested in "Atomic multi-channel > updates with constant collateral in bitcoin-compatible payment-channel > networks" > https://scholar.google.com/scholar?cluster=40566801298747858=en_sdt=2005=0,5 > but I am still in doubt what happens during closing of subchannel ? > > > > > -- > > > > > Yours sincerely, > > > > > Subhra Mazumdar. > > > > > > -- > > > Yours sincerely, > > > Subhra Mazumdar. > > > > -- > > Yours sincerely, > > Subhra Mazumdar. > > > -- Yours sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Not revealing the channel capacity during opening of channel in lightning network
So introducing proof of knowledge of fund locked instead of revealing the amount of fund locked by counterparties will introduce added complexity while routing but how effective is this going to be against handling attacks like hijacking of routes and channel exhaustion ? On Mon, Jan 27, 2020, 20:12 Matt Corallo wrote: > Note that there's no real reason lightning nodes *have* to have > confidence in that - if a node routes your payment to the next hop, how > they do it doesn't really matter. Allowing things like non-lightning > "channels" (eg just a contractual agreement to settle up later between > two mutually-trusting parties) would actually be quite compelling. > > The reason lightning nodes *today* require proof-of-funds-locked is > largely for DoS resistance, effectively rate-limiting flooding the > global routing table with garbage, but such rate-limiting could be > accomplished (albeit with a ton more complexity) via other means. > > Matt > > On 1/27/20 7:50 AM, Ugam Kamat wrote: > > Hey Subhra – In order to have faith that the channel announced by the > > nodes is actually locked on the Bitcoin mainchain we need to have the > > outpoint (`txid` and `vout`) of the funding transaction. If we do not > > verify that the funding transaction has been confirmed, nodes can cheat > > us that a particular transaction is confirmed when it is not the case. > > As a result we require that nodes announce this information along with > > the public keys and the signatures of the public keys that was used to > > lock the funding transaction. > > > > > > > > This information is broadcasted in the `channel_announcement` message in > > the `short_channel_id` field which includes the block number, > > transaction number and vout. Since Bitcoin does not allow confidential > > transactions, we can query the blockchain and find out the channel > > capacity even when the amounts are never explicitly mentioned. > > > > > > > > > > > > Ugam > > > > > > > > *From:* Lightning-dev > > *On Behalf Of *Subhra Mazumdar > > *Sent:* Monday, January 27, 2020 12:45 PM > > *To:* lightning-dev@lists.linuxfoundation.org > > *Subject:* [Lightning-dev] Not revealing the channel capacity during > > opening of channel in lightning network > > > > > > > > Dear All, > > > > What can be the potential problem if a channel is opened > > whereby the channel capacity is not revealed publicly but just a range > > proof of the attribute (capacity >0 and capacity < value) is provided ? > > Will it pose a problem during routing of transaction ? What are the pros > > and cons ? > > > > I think that revealing channel capacity make the channels susceptible to > > channel exhaustion attack or a particular node might be targeted for > > node isolation attack ? > > > > > > -- > > > > Yours sincerely, > > Subhra Mazumdar. > > > > > > ___ > > Lightning-dev mailing list > > Lightning-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Not revealing the channel capacity during opening of channel in lightning network
Hey thanks for clearing the confusion. Well then may be we can look out for such a provision in off chain payment systems for Monero. On Mon, Jan 27, 2020, 13:20 Ugam Kamat wrote: > Hey Subhra – In order to have faith that the channel announced by the > nodes is actually locked on the Bitcoin mainchain we need to have the > outpoint (`txid` and `vout`) of the funding transaction. If we do not > verify that the funding transaction has been confirmed, nodes can cheat us > that a particular transaction is confirmed when it is not the case. As a > result we require that nodes announce this information along with the > public keys and the signatures of the public keys that was used to lock the > funding transaction. > > > > This information is broadcasted in the `channel_announcement` message in > the `short_channel_id` field which includes the block number, transaction > number and vout. Since Bitcoin does not allow confidential transactions, we > can query the blockchain and find out the channel capacity even when the > amounts are never explicitly mentioned. > > > > > > Ugam > > > > *From:* Lightning-dev *On > Behalf Of *Subhra Mazumdar > *Sent:* Monday, January 27, 2020 12:45 PM > *To:* lightning-dev@lists.linuxfoundation.org > *Subject:* [Lightning-dev] Not revealing the channel capacity during > opening of channel in lightning network > > > > Dear All, > > What can be the potential problem if a channel is opened whereby > the channel capacity is not revealed publicly but just a range proof of the > attribute (capacity >0 and capacity < value) is provided ? Will it pose a > problem during routing of transaction ? What are the pros and cons ? > > I think that revealing channel capacity make the channels susceptible to > channel exhaustion attack or a particular node might be targeted for node > isolation attack ? > > > -- > > Yours sincerely, > Subhra Mazumdar. > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Not revealing the channel capacity during opening of channel in lightning network
Dear All, What can be the potential problem if a channel is opened whereby the channel capacity is not revealed publicly but just a range proof of the attribute (capacity >0 and capacity < value) is provided ? Will it pose a problem during routing of transaction ? What are the pros and cons ? I think that revealing channel capacity make the channels susceptible to channel exhaustion attack or a particular node might be targeted for node isolation attack ? -- Yours sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Reduce the amount of collateral locked by scripts for transferring funds in lightning network
Hi ZmnSCPxj, It is stated in the paper "Atomic multi-channel updates with constant collateral in bitcoin-compatible payment-channel networks" and I am quoting verbatim (page 11) (last email still waiting moderator approval) "Phase I: Setup. The first phase requires to freeze the coins available at each channel involved in the protocol. Doing this naively (i.e., locking the complete balance in the channel at once) would lock more coins than required, unnecessarily increasing the collateral in the protocol. Instead, during the setup phase, the balance at each payment channel is split in two, effectively creating thereby two sub-channels: one sub-channel is set with the coins required for the present protocol session, while the other one is set with the remaining coins, which can then be freely spent. In the illustrative example shown in Figure 4.2, the setup phase starts with the user A collaborating with user B to create the transaction Tx A setup , where they split the 10 coins they have in the channel in two sub-channels: one sub-channel with 8 coins to be used in the rest of the protocol session and one sub-channel with the rest (i.e., 2 coins). This transaction is signed by both users so that it can be eventually enforced on-chain if required. The rest of the users behave analogously. Note that operations at each channel in this phase of the protocol can be carried out in parallel." Does this sound good ? On Mon, Jan 27, 2020 at 9:41 AM Subhra Mazumdar < subhra.mazumdar1...@gmail.com> wrote: > Hi ZmnSCPxj, >It is stated in the paper "Atomic multi-channel updates with > constant collateral in bitcoin-compatible payment-channel networks". I am > attaching the screenshot of the paragraph which mentions about locking the > amount which is required for payment transfer and not the entire channel > fund. > > On Mon, Jan 27, 2020 at 6:15 AM ZmnSCPxj wrote: > >> Good morning Subhra, >> >> This does not seem to make sense? >> For a payment that is less than the channel funds on your side, only that >> amount is locked behind an HTLC, and the rest remains useable for other >> HTLCs. >> >> What exactly are you referring to? >> >> Regards, >> ZmnSCPxj >> >> > Hi, >> > I was wondering when parties apply condition on fraction of >> channel fund for ensuring successful payment, entire channel fund is held. >> Is it possible to lock just partial amount of fund of a payment channel and >> leave the rest to be used by some another payment request ? Concept of >> subchannels of a single channel has been suggested in "Atomic multi-channel >> updates with constant collateral in bitcoin-compatible payment-channel >> networks" >> https://scholar.google.com/scholar?cluster=40566801298747858=en_sdt=2005=0,5 >> but I am still in doubt what happens during closing of subchannel ? >> > -- >> > Yours sincerely, >> > Subhra Mazumdar. >> >> >> > > -- > Yours sincerely, > Subhra Mazumdar. > > -- Yours sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Reduce the amount of collateral locked by scripts for transferring funds in lightning network
Hi, I was wondering when parties apply condition on fraction of channel fund for ensuring successful payment, entire channel fund is held. Is it possible to lock just partial amount of fund of a payment channel and leave the rest to be used by some another payment request ? Concept of subchannels of a single channel has been suggested in "Atomic multi-channel updates with constant collateral in bitcoin-compatible payment-channel networks" https://scholar.google.com/scholar?cluster=40566801298747858=en_sdt=2005=0,5 but I am still in doubt what happens during closing of subchannel ? -- Yours sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)
Thanks for the link. I will have a look. On Tue, Jan 21, 2020, 06:17 ZmnSCPxj wrote: > Good morning Subhra, > > Refer to this protocol instead of DLAS: > https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002035.html > In this protocol, an *encrypted* form of the *entire file* is sent. > Consequently, a *single* payment is made, where the payment preimage is > the decryption key. > Knowing an additional zk proof is necessary to show that the file is > indeed encrypted using the decryption key that is the preimage of the given > hash (the linked thread has details I believe). > > Relevantly, there is no need to consider blocks of a file when using the > linked protocol instead of DLAS. > Of course, a Zk-proof of some property of the entire file, that can be > understood by an end-user, may not be possible. > Likely, you might want to prove of a video file that a thumbnail of the > video file is extracted from a frame of the video, and show that thumbnail > to the end-user. > Looking at the *rest* of the frames of the video (after you have paid for > its decryption) may very reveal them to be frames of a video of Rick Astley > singing "Never Gonna Give You Up". > ! > > Regards, > ZmnSCPxj > > > So is it sufficient to give a zk proof of the entire file and not of the > individual blocks which are transferred at each iteration? Also does it > make sense that you make partial payment per block instead of waiting for > the total file to arrive. It might be the case that the zk proof of the > total file is correct but then sender might cheat while sending individual > block. > > > > On Tue, Jan 21, 2020, 00:26 Matt Corallo > wrote: > > > > > Don’t and data in lighting payments unless you have to. It’s super > DoS-y and rude to your peers. If you’re just transferring a file, you can > use ZKCP to send an encrypted copy of the file with the encryption key > being the payment_preimage, making the whole thing one big atomic action. > > > > > > > On Jan 20, 2020, at 13:33, Subhra Mazumdar < > subhra.mazumdar1...@gmail.com> wrote: > > > > > > > > > > > Sounds good. But how do I provide a correctness for the entire asset > to be transferred when I am already partitioning into several units (say > chunks of file ? ) So as an when the block of file is received then we have > to give a ZK proof "block x is part of File F". Is it how this should work ? > > > > > > > > On Mon, Jan 20, 2020 at 11:59 PM Matt Corallo < > lf-li...@mattcorallo.com> wrote: > > > > > > > > > Zk proofs are incredibly fast these days for small-ish programs. > They’re much too slow for a consensus system where every party needs to > download and validate them, but for relatively simple programs a two-party > system using them is very doable. > > > > > > > > > > > On Jan 20, 2020, at 13:23, Subhra Mazumdar < > subhra.mazumdar1...@gmail.com> wrote: > > > > > > > > > > > > > > > > > But isn't it that the use of ZK proof will render the system > slow and hence defy the very purpose of lightning network which intends to > make things scalable as well as faster transaction ? > > > > > > > > > > > > On Mon, Jan 20, 2020 at 11:48 PM Matt Corallo < > lf-li...@mattcorallo.com> wrote: > > > > > > > > > > > > > That paper discusses it, but I don't think there was ever a > paper proper > > > > > > > on ZKCP. There are various discussions of it, though, if you > google. > > > > > > > Sadly this is common in this space - lots of great ideas where > no one > > > > > > > ever bothered to write academic-style papers about them (hence > why > > > > > > > academic papers around Bitcoin tend to miss nearly all > relevant context, > > > > > > > sadly). > > > > > > > > > > > > > > Matt > > > > > > > > > > > > > > On 1/20/20 6:10 PM, Subhra Mazumdar wrote: > > > > > > > > Are you referring to the paper Zero knowledge contingent > payment > > > > > > > > revisited ? I will look into the construction. Thanks for the > > > > > > > > information! :) > > > > > > > > > > > > > > > > On Mon, Jan 20, 2020, 23:31 Matt Corallo < > lf-li...@mattcorallo.com > > > > > > > > <mailto:lf-li...@mattcorallo.com>> wrote: &g
Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)
So is it sufficient to give a zk proof of the entire file and not of the individual blocks which are transferred at each iteration? Also does it make sense that you make partial payment per block instead of waiting for the total file to arrive. It might be the case that the zk proof of the total file is correct but then sender might cheat while sending individual block. On Tue, Jan 21, 2020, 00:26 Matt Corallo wrote: > Don’t and data in lighting payments unless you have to. It’s super DoS-y > and rude to your peers. If you’re just transferring a file, you can use > ZKCP to send an encrypted copy of the file with the encryption key being > the payment_preimage, making the whole thing one big atomic action. > > On Jan 20, 2020, at 13:33, Subhra Mazumdar > wrote: > > > Sounds good. But how do I provide a correctness for the entire asset to be > transferred when I am already partitioning into several units (say chunks > of file ? ) So as an when the block of file is received then we have to > give a ZK proof "block x is part of File F". Is it how this should work ? > > On Mon, Jan 20, 2020 at 11:59 PM Matt Corallo > wrote: > >> Zk proofs are incredibly fast these days for small-ish programs. They’re >> much too slow for a consensus system where every party needs to download >> and validate them, but for relatively simple programs a two-party system >> using them is very doable. >> >> On Jan 20, 2020, at 13:23, Subhra Mazumdar >> wrote: >> >> >> But isn't it that the use of ZK proof will render the system slow and >> hence defy the very purpose of lightning network which intends to make >> things scalable as well as faster transaction ? >> >> On Mon, Jan 20, 2020 at 11:48 PM Matt Corallo >> wrote: >> >>> That paper discusses it, but I don't think there was ever a paper proper >>> on ZKCP. There are various discussions of it, though, if you google. >>> Sadly this is common in this space - lots of great ideas where no one >>> ever bothered to write academic-style papers about them (hence why >>> academic papers around Bitcoin tend to miss nearly all relevant context, >>> sadly). >>> >>> Matt >>> >>> On 1/20/20 6:10 PM, Subhra Mazumdar wrote: >>> > Are you referring to the paper Zero knowledge contingent payment >>> > revisited ? I will look into the construction. Thanks for the >>> > information! :) >>> > >>> > On Mon, Jan 20, 2020, 23:31 Matt Corallo >> > <mailto:lf-li...@mattcorallo.com>> wrote: >>> > >>> > On 11/9/19 4:31 AM, Takaya Imai wrote: >>> > > [What I do not describe] >>> > > * A way to detect that data is correct or not, namely zero >>> knowledge >>> > > proof process. >>> > >>> > Have you come across Zero Knowledge Contingent Payments? >>> Originally it >>> > was designed for on-chain applications but it slots neatly into >>> > lightning as it only requires a method to lock funds to a hash >>> preimage. >>> > >>> > Matt >>> > ___ >>> > Lightning-dev mailing list >>> > Lightning-dev@lists.linuxfoundation.org >>> > <mailto:Lightning-dev@lists.linuxfoundation.org> >>> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >>> > >>> >> >> >> -- >> Yours sincerely, >> Subhra Mazumdar. >> >> > > -- > Yours sincerely, > Subhra Mazumdar. > > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)
Sounds good. But how do I provide a correctness for the entire asset to be transferred when I am already partitioning into several units (say chunks of file ? ) So as an when the block of file is received then we have to give a ZK proof "block x is part of File F". Is it how this should work ? On Mon, Jan 20, 2020 at 11:59 PM Matt Corallo wrote: > Zk proofs are incredibly fast these days for small-ish programs. They’re > much too slow for a consensus system where every party needs to download > and validate them, but for relatively simple programs a two-party system > using them is very doable. > > On Jan 20, 2020, at 13:23, Subhra Mazumdar > wrote: > > > But isn't it that the use of ZK proof will render the system slow and > hence defy the very purpose of lightning network which intends to make > things scalable as well as faster transaction ? > > On Mon, Jan 20, 2020 at 11:48 PM Matt Corallo > wrote: > >> That paper discusses it, but I don't think there was ever a paper proper >> on ZKCP. There are various discussions of it, though, if you google. >> Sadly this is common in this space - lots of great ideas where no one >> ever bothered to write academic-style papers about them (hence why >> academic papers around Bitcoin tend to miss nearly all relevant context, >> sadly). >> >> Matt >> >> On 1/20/20 6:10 PM, Subhra Mazumdar wrote: >> > Are you referring to the paper Zero knowledge contingent payment >> > revisited ? I will look into the construction. Thanks for the >> > information! :) >> > >> > On Mon, Jan 20, 2020, 23:31 Matt Corallo > > <mailto:lf-li...@mattcorallo.com>> wrote: >> > >> > On 11/9/19 4:31 AM, Takaya Imai wrote: >> > > [What I do not describe] >> > > * A way to detect that data is correct or not, namely zero >> knowledge >> > > proof process. >> > >> > Have you come across Zero Knowledge Contingent Payments? Originally >> it >> > was designed for on-chain applications but it slots neatly into >> > lightning as it only requires a method to lock funds to a hash >> preimage. >> > >> > Matt >> > _______ >> > Lightning-dev mailing list >> > Lightning-dev@lists.linuxfoundation.org >> > <mailto:Lightning-dev@lists.linuxfoundation.org> >> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > >> > > > -- > Yours sincerely, > Subhra Mazumdar. > > -- Yours sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)
But isn't it that the use of ZK proof will render the system slow and hence defy the very purpose of lightning network which intends to make things scalable as well as faster transaction ? On Mon, Jan 20, 2020 at 11:48 PM Matt Corallo wrote: > That paper discusses it, but I don't think there was ever a paper proper > on ZKCP. There are various discussions of it, though, if you google. > Sadly this is common in this space - lots of great ideas where no one > ever bothered to write academic-style papers about them (hence why > academic papers around Bitcoin tend to miss nearly all relevant context, > sadly). > > Matt > > On 1/20/20 6:10 PM, Subhra Mazumdar wrote: > > Are you referring to the paper Zero knowledge contingent payment > > revisited ? I will look into the construction. Thanks for the > > information! :) > > > > On Mon, Jan 20, 2020, 23:31 Matt Corallo > <mailto:lf-li...@mattcorallo.com>> wrote: > > > > On 11/9/19 4:31 AM, Takaya Imai wrote: > > > [What I do not describe] > > > * A way to detect that data is correct or not, namely zero > knowledge > > > proof process. > > > > Have you come across Zero Knowledge Contingent Payments? Originally > it > > was designed for on-chain applications but it slots neatly into > > lightning as it only requires a method to lock funds to a hash > preimage. > > > > Matt > > ___ > > Lightning-dev mailing list > > Lightning-dev@lists.linuxfoundation.org > > <mailto:Lightning-dev@lists.linuxfoundation.org> > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > -- Yours sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)
Are you referring to the paper Zero knowledge contingent payment revisited ? I will look into the construction. Thanks for the information! :) On Mon, Jan 20, 2020, 23:31 Matt Corallo wrote: > On 11/9/19 4:31 AM, Takaya Imai wrote: > > [What I do not describe] > > * A way to detect that data is correct or not, namely zero knowledge > > proof process. > > Have you come across Zero Knowledge Contingent Payments? Originally it > was designed for on-chain applications but it slots neatly into > lightning as it only requires a method to lock funds to a hash preimage. > > Matt > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)
Thanks Takaya for clearing my doubts. Regarding the answer to the question "What happens if it fails in an iteration ? So the recipient of the file remains happy with the partial content ? Or will the payment be revoked (not sure how) if recipient doesn't get the full content ? This is about the DLAS-up protocol. The protocol uses OG AMP so the payments and data transfers are revoked in case that it fails" I am talking about different iterations. If it's the case that you have a 5GB file then you are sending 256bit via each path. May be in one iteration you are able to send some 200 byte (assuming we get 8 paths at a time). So it's the case that you need 5GB/200B iterations. But og amp guarantees atomic delivery for blocks per iteration right and not for all the iterations taken together ? Also how do you ensure correctness of the file shared (using Zk proof ?) ? On Mon, Jan 20, 2020, 12:03 Takaya Imai wrote: > Hi Subhra, > > thanks for your question. > > > So as of now if we consider transfer of a file (may of few KB) then you > split it into several blocks and use atomic multi path payment whole using > the blocks for embedding with the preimage inorder to obtain payment. > > But it might be the case you may not have sufficient number of path to > transfer all the blocks at one go because of preimage size limitation of > 256 bit (I didn't get the point that there is no limitation on data size, > can anyone explain that ?). > > Yes. It needs many blocks and paths if large file. > But it has no problem because it can use the same path several times. > > Of course it needs much money to transfer large file. But this is good > point in order to retain lightning network stable. > > For DOS attack, OG AMP has the same problem. It might that recipient needs > a limit how many split blocks the recipient accept > > > So may be you need several iteration and I presume thats what lightning > network will pitch in where we have several such microtransactions going on. > >. > > Thanks, > Takaya Imai > > 2020年1月16日(木) 16:14 Subhra Mazumdar : > >> Hello Takaya, >> I really liked the idea of data atomic swap mentioned over here. >> So as of now if we consider transfer of a file (may of few KB) then you >> split it into several blocks and use atomic multi path payment whole using >> the blocks for embedding with the preimage inorder to obtain payment. But >> it might be the case you may not have sufficient number of path to transfer >> all the blocks at one go because of preimage size limitation of 256 bit (I >> didn't get the point that there is no limitation on data size, can anyone >> explain that ?). So may be you need several iteration and I presume thats >> what lightning network will pitch in where we have several such >> microtransactions going on. What happens if it fails in an iteration ? So >> the recipient of the file remains happy with the partial content ? Or will >> the payment be revoked (not sure how) if recipient doesn't get the full >> content ? >> >> On Mon, Nov 11, 2019 at 6:29 AM Takaya Imai < >> takaya.i...@frontier-ptnrs.com> wrote: >> >>> Hi all, >>> >>> I propose Data Lightning Atomic Swap. >>> Anyone already have the same idea? >>> >>> >>> [Abstract] >>> This proposal is a way to swap data and lightning payment atomically. >>> It has two patterns, one is for a payer to swap data-download with >>> lightning payment to a payee (DLAS-down), the other is for a payer to swap >>> data-upload with lightning payment to a payee (DLAS-up). >>> >>> The data is embedded to preimage so sending and receiving the data need >>> lightning payment at the same time. >>> >>> - >>> >>> [Motivation] >>> Atomic Swaps among crypto currencies has various ways to implement >>> (on-chain to on-chain[1], on-chain to of-chain(Submarine Swap[2])). And >>> Atomic Swaps between data and crypto currencies are also proposed as a part >>> of TumbleBit mechanism[3], Storm mechanism[4] and so on. >>> >>> Recently Joost Jager proposed Instant messages with lightning onion >>> routing, whatsat[5], which use recent sphinx payload change[6]. This is >>> very awesome but not atomic with lightning payment. >>> >>> Atomic lightning mechanism for data is useful in use cases below. >>> >>> - >>> >>> [Pros & Cons] >>> >>> * DLAS-down >>> ** Pros >>> *** Atomic data download exchange with lightning payment >>> ** Cons >>> *** It ne
Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)
only one for one channel and the data can be decrypted > if enc_key is leaked. So enc_key should be generated newly every time by a > way like hash chain but the protocol image above is just example for > simplicity. > * .x means X axis value of points on Elliptic Curve. > * If data is less than 256 bits, then 0x00 is padded (I am not sure which > of big endian and little endian is better). > > > > 2, Data upload <-> lightning (DLAS-down) > > Payer sends data and lightning payment from Payee atomically. > This is like OG AMP(Atomic Multi-path Payment)[7] system. > > Payer Mediators > Payee > > = > data(512bit, padded) > > share1(256bit) > share2(256bit) > > base_s = share1 XOR share2 > data1(256bit) || data2(256bit) = data(512bit) > XOR_d1 = data1 XOR base_s > XOR_d2 = data2 XOR base_s > PreImg1 = sha256(base_s || data || 1) > PreImg2 = sha256(base_s || data || 2) > > sha256(PreImg1), XOR_d1, share1 -> sha256(PreImg1), XOR_d1, share1 -> > sha256(PreImg1), XOR_d1, share1 > sha256(PreImg2), XOR_d2, share2 -> sha256(PreImg2), XOR_d2, share2 -> > sha256(PreImg2), XOR_d2, share1 > > > base s = share1 XOR share2 > > data = (XOR_d1 XOR base_s) || (XOR_d2 XOR base_s) > > PreImg1 = sha256(base_s || data || 1) > > PreImg2 = sha256(base_s || data || 2) > > PreImg1<---PreImg1<- > PreImg1 > PreImg2<---PreImg2<- > PreImg2 > > > * This protocol example has 512 bits data and they are transferred in two > paths. However, it can transfer larger data in several payment paths like > [5]. > * || means string concatenation. > * If data is less than 512 bits, then 0x00 is padded(I am not sure which > of big endian and little endian is better). > > > - > > > [Use Cases] > > 1, Lightning Network ecosystem > > * Hosting Incentives like Acai Protocol > ** Watchtower Hosting incentive, Backup Hosting incentive > *** Commitment tx data sending to Data Host(DLAS-up) > Commitment tx data is embedded in preimage so that Payer can not send > the data without remittance > *** Channel backup data receiving from Data Host(DLAS-down) > Channel backup data is embedded in preimage so that Payer can not > receive the data without remittance > > 2, Crypto currency Problems > > * Distributed secret key sharing (just come up with an idea though) > ** As a key backup, one of secret key shares is distributed with > encryption(DLAS-up) to some nodes, which nodes receive lightning payment as > key managing fee. And the nodes send a proof for managing the key as > response of bloom filter periodically, and exchange encrypted secret key > share with lightning payment to asset holder(DLAS-down). > ** For example 2 out of 3 multi signature key sharing, asset holder puts > the first key, the custodial has the second key, and the third key at the > lightning distribution nodes. Asset holders usually spend assets using > their key and the key on Distributed Nodes. > > > 3, Problems so far > > * Prevention email spam and DDoS attack with large data > ** Payer can not send email or data without remittance(DLAS-up) > ** Payer can not receive reply-email without remittance(DLAS-down) > > * Incentive of receiving advertisements on browser or desktop/mobile app > ** Payer can not send advertisements without remittance(DLAS-up) > > * Bounty for code bug fixes based on cryptographic proofs or secret > computations > ** (DLAS-down) > > > > [References] > > [1] https://bitcointalk.org/index.php?topic=321228 > [2] https://twitter.com/roasbeef/status/964608261830750208 > [3] https://eprint.iacr.org/2016/575 > [4] https://github.com/storm-org/storm-spec > [5] https://twitter.com/joostjgr/status/1190714028626251779 > [6] https://github.com/lightningnetwork/lightning-rfc/pull/619 > [7] > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html > > > document on github: > https://github.com/takaya-imai/data_lightning_atomic_swap > > Best regards, > Takaya Imai > Email: takaya.i...@frontier-ptnrs.com, takaya.i...@unitedbitcoiners.com > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -- Yours sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Byzantine nodes in Lightning network
Is there any literature available on how protocols would get affected in presence of Byzantine nodes ? For example, consider that a 2 byzantine nodes open a payment channel, since none of the intermediate transaction in a channel gets recorded, will this impact other transactions which gets routed through this channel ? -- Yours sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Doubt regarding payment channel capacity
Hello everyone, My doubt might be silly and apologies for the same. Suppose in a payment channel network say 2 parties B and C are malicious, controlled by same adversary. They had initially opened a channel of 1 BTC. But suppose they get 3 transaction request will flow value of 0.4 BTC each. After 1st 2 transaction, B and C has capacity of 0.2 BTC. But what if BC reports an incorrect residual balance thereby accepting the 3rd transaction. Who will keep track of this capacity violation since no one is keeping track of this residual value ? If this case is true, then parties might resort to such a strategy opening a low value channel but still accepting multiple transactions where the total payment value of all transaction exceeds channel capacity. Please correct me if I am wrong. -- Yours sincerely, Subhra Mazumdar. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
