Re: [Lightning-dev] Blind paths revisited
Thank you for the clarification. Sorry for misinterpreting the paper of anonymous multihop lock. A bit of rephrasing of what I exactly meant and apologies for describing vaguely. Following your discussion on griefing attack, it is clear the payer and payee wants to intentionally deprive intermediate nodes, by colluding. However, by griefing (a misnomer for this situation) I didn't mean exactly withholding the solution but something like this: Given S->A->B->C->D->E->F->R, S, B and F are controlled by the same adversary and considering all the parties have completed the lock phase. Now R triggers release phase and F gets x_r from R. However, F adds x_f to x_r forwards it directly to B, doesn't complete signature with E and cancels the HTLC just before the elapse of expiration time, E terminates its HTLC with D and so on. B has x_c+x_d+x_e+x_f+x_r (shared by F and shared by S). It continues normally completing payment with A and then S. I am not sure whether again this attack makes sense. On Thu, Apr 2, 2020 at 6:04 AM ZmnSCPxj wrote: > Good morning Subhra, > > > 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. > > Note that in the context of PTLCs, R does not get a key (as in private > key) of x_a+x_b+x_c+x_d+x_e+x_f. > Instead, R still continues to use its normal private key for claiming > HTLC/PTLC. > We simply have R generate an adaptor signature first and hand that over to > F, such that completing the signature and publishing it onchain will reveal > a secret x_r (which is NOT the node privkey of R). > > What happens really here is that each hop sets up a PTLC. > The sender is responsible for ensuring that the F->R PTLC is equal to x_r > * G, that E->F is equal to (x_f + x_r) * G, that D->E is equal to (x_e + > x_f + x_r) * G, and so on. > However, the sender knows only (x_r * G) without knowing x_r, thus it > never is able to completely control the secret at every point -- the > receiver knows the other secret as well. > > That is the entire crux of the argument --- *both* sender and receiver > control the secrets anyway, so it is not controlled by a single entity, at > least for non-self-payments. > > > 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?). > > Griefing attacks are only possible by not claiming or forwarding the > attack. > If S and B "collude" to perform a grief, then either B never forwards to > C, in which case there is no possible way to attack, or C receives it and > claims it but B does not claim it, in which case B paid out money and is > now 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 secur
Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation
Good morning Nadav, > Love the idea! I have a couple questions though: > > I'm not convinced that "Purely Falsified Proof-Of-Closure" aren't effective. > Consider a similar network to the one you described where we have channels A > - B - C and A - E - C but where we add a "fake" channel E - E'. Now if the > attacker sets up a payment from E to E' using the route E - C - B - A - E - > E', then the attacker can successfully lock up all of B's channels (as is > desirable to get rid of competition) and also generate a false proof of > closure for the E - E' channel. Even if this false proof (which is a > commitment tx) ends up being published on chain, E has lost no ability to > route and has successfully made B unable to route between A and C. If my > understanding of the proposal is correct, and it may not be, then the > punishment for grieving payments is the threat of closing channels that would > benefit from the grieving attack. But adding a new channel on the end to be > closed seems to invalidate this punishment? The consideration is that much of the cost of a channel is with the setup and teardown --- E could always just reopen the CE channel again later. Thus, the cost that E bears in setting up EE and tearing down EE would be still similar to the cost of losing CE and reestablishing it again. Further, any amount it places in the EE channel would be an amount it could have been using as liquidity on Lightning, but which it cannot use for forwarding (because it is a channel to nowhere). Ultimately, proof-of-closure is an economic mechanism, not an information-theoretic one. So the mere existence of EE, to be later sacrificed, is enough punishment on E. I think. > > A second question I have is if you think that it would be advisable to use > up-front payments (pay for attempt, not just success) on payments with > abnormally high soft timeouts? If all this works, this combination seems to > be a way to enable hodl invoices under the proof of closure proposal. Possibly, though this increases the complexity of the proposal even more. >I just thought of a potentially more serious problem, at least for Poon-Dryja >channels, isn't it true that giving a proof of closure is equivalent to >actually closing the channel since once other parties have copies of the fully >signed commitment transaction, it cannot be safely revoked since other parties >now have the ability to publish an old state? I might be missing something but >this seems like a big problem. Since this is a proof-of-***closure***, this is indeed an actual closing of the channel. It would not be proof-of-closure if the channel was not being closed, but proof-of-something-else. What is desired is simply that C can plausibly say "I punished somebody else by closing on them, please do not punish me for punishing them". Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Blind paths revisited
Good morning Subhra, > 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. Note that in the context of PTLCs, R does not get a key (as in private key) of x_a+x_b+x_c+x_d+x_e+x_f. Instead, R still continues to use its normal private key for claiming HTLC/PTLC. We simply have R generate an adaptor signature first and hand that over to F, such that completing the signature and publishing it onchain will reveal a secret x_r (which is NOT the node privkey of R). What happens really here is that each hop sets up a PTLC. The sender is responsible for ensuring that the F->R PTLC is equal to x_r * G, that E->F is equal to (x_f + x_r) * G, that D->E is equal to (x_e + x_f + x_r) * G, and so on. However, the sender knows only (x_r * G) without knowing x_r, thus it never is able to completely control the secret at every point -- the receiver knows the other secret as well. That is the entire crux of the argument --- *both* sender and receiver control the secrets anyway, so it is not controlled by a single entity, at least for non-self-payments. > 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?). Griefing attacks are only possible by not claiming or forwarding the attack. If S and B "collude" to perform a grief, then either B never forwards to C, in which case there is no possible way to attack, or C receives it and claims it but B does not claim it, in which case B paid out money and is now 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 infor
Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation
I just thought of a potentially more serious problem, at least for Poon-Dryja channels, isn't it true that giving a proof of closure is equivalent to actually closing the channel since once other parties have copies of the fully signed commitment transaction, it cannot be safely revoked since other parties now have the ability to publish an old state? I might be missing something but this seems like a big problem. Best, Nadav On Wed, Apr 1, 2020 at 1:07 PM Nadav Kohen wrote: > Hi ZmnSCPxj and list, > > Love the idea! I have a couple questions though: > > I'm not convinced that "Purely Falsified Proof-Of-Closure" aren't > effective. Consider a similar network to the one you described where we > have channels A - B - C and A - E - C but where we add a "fake" channel E - > E'. Now if the attacker sets up a payment from E to E' using the route E - > C - B - A - E - E', then the attacker can successfully lock up all of B's > channels (as is desirable to get rid of competition) and also generate a > false proof of closure for the E - E' channel. Even if this false proof > (which is a commitment tx) ends up being published on chain, E has lost no > ability to route and has successfully made B unable to route between A and > C. If my understanding of the proposal is correct, and it may not be, then > the punishment for grieving payments is the threat of closing channels that > would benefit from the grieving attack. But adding a new channel on the end > to be closed seems to invalidate this punishment? > > A second question I have is if you think that it would be advisable to use > up-front payments (pay for attempt, not just success) on payments with > abnormally high soft timeouts? If all this works, this combination seems to > be a way to enable hodl invoices under the proof of closure proposal. > > Best, > Nadav > > On Wed, Apr 1, 2020 at 1:19 AM ZmnSCPxj via Lightning-dev < > lightning-dev@lists.linuxfoundation.org> wrote: > >> Introduction >> >> >> Given the fact that contracts on offchain protocols need to be >> enforceable onchain as well, timelocks involved in multi-hop payments are >> measured in blocks. >> This is because the blockchain can only (third-party-verifiably) enforce >> timeouts in units of entire blocks. >> This leads to very long timeouts for payment delivery, thus multi-hop >> offchain payment attempts can be, deliberately or accidentally, be in a >> "pending" state up to the very large timeouts involved. >> >> Deliberately setting up a multi-hop payment such that it will be in a >> "pending" state for long periods of time is colloquially known as a >> "griefing attack". >> In this article, we assess various proposed solutions to mitigate the >> effects of griefing attacks, and propose a particular solution, >> proof-of-closure, as well, that requires significant changes to the update >> state machine. >> >> Digression: Why Grief? >> == >> >> Before embarking on our investigation for solutions to the griefing >> problem, we should first wonder if griefing is, in fact, a problem. >> >> This brings up the question of: why would anybody grief at all? >> >> Humans, like cats and other less-sapient pieces of walking meat, often >> find enjoyment in causing the suffering of others for no immediate direct >> gain to themselves, as a public demonstration of dominance over those they >> make suffer (aka "shits and giggles", which, if executed correctly, can >> lead to eventual direct gains to themselves or their progeny or relatives >> or allies, but such details are often outside the ken of the very beings >> who execute such survival strategies: brains are pieces of meat that have >> been hacked to act as action-reaction engines, but are not sophisticated >> enough to execute as pure rationality engines at all times). >> Fortunately, in the Bitcoin world, only purely rational beings of pure >> selfishness can exist in the long run, thus we can neglect such motivations >> as mere noise. >> >> First, let us investigate *how* griefing attacks can be performed. >> >> * An intermediate node in a multi-hop attempt can delay forwarding or >> failing an incoming HTLC. >> * A final node in a payment attempt can delay claiming an incoming HTLC. >> >> Let us consider a purely rational intermediate node of pure selfishness: >> >> * If it forwards as soon as possible, it can earn fees, and also speed up >> the release of the HTLC-locked funds so that they can reuse those funds as >> liquidity for further payment attempts. >> * Thus, delaying an HTLC is not selfishly-rational for an intermediate >> node. >> >> Thus, for an intermediate node, it seems there is no selfishly-rational >> motivation to execute a griefing attack on an arbitrary payment attempt. >> We can then conclude that an intermediate that delays a payment would do >> so, not of its own rational self-interest, but as an accident, such as an >> unforeseen connectivity or power failure. >> >> However, things ar
Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation
Hi ZmnSCPxj and list, Love the idea! I have a couple questions though: I'm not convinced that "Purely Falsified Proof-Of-Closure" aren't effective. Consider a similar network to the one you described where we have channels A - B - C and A - E - C but where we add a "fake" channel E - E'. Now if the attacker sets up a payment from E to E' using the route E - C - B - A - E - E', then the attacker can successfully lock up all of B's channels (as is desirable to get rid of competition) and also generate a false proof of closure for the E - E' channel. Even if this false proof (which is a commitment tx) ends up being published on chain, E has lost no ability to route and has successfully made B unable to route between A and C. If my understanding of the proposal is correct, and it may not be, then the punishment for grieving payments is the threat of closing channels that would benefit from the grieving attack. But adding a new channel on the end to be closed seems to invalidate this punishment? A second question I have is if you think that it would be advisable to use up-front payments (pay for attempt, not just success) on payments with abnormally high soft timeouts? If all this works, this combination seems to be a way to enable hodl invoices under the proof of closure proposal. Best, Nadav On Wed, Apr 1, 2020 at 1:19 AM ZmnSCPxj via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Introduction > > > Given the fact that contracts on offchain protocols need to be enforceable > onchain as well, timelocks involved in multi-hop payments are measured in > blocks. > This is because the blockchain can only (third-party-verifiably) enforce > timeouts in units of entire blocks. > This leads to very long timeouts for payment delivery, thus multi-hop > offchain payment attempts can be, deliberately or accidentally, be in a > "pending" state up to the very large timeouts involved. > > Deliberately setting up a multi-hop payment such that it will be in a > "pending" state for long periods of time is colloquially known as a > "griefing attack". > In this article, we assess various proposed solutions to mitigate the > effects of griefing attacks, and propose a particular solution, > proof-of-closure, as well, that requires significant changes to the update > state machine. > > Digression: Why Grief? > == > > Before embarking on our investigation for solutions to the griefing > problem, we should first wonder if griefing is, in fact, a problem. > > This brings up the question of: why would anybody grief at all? > > Humans, like cats and other less-sapient pieces of walking meat, often > find enjoyment in causing the suffering of others for no immediate direct > gain to themselves, as a public demonstration of dominance over those they > make suffer (aka "shits and giggles", which, if executed correctly, can > lead to eventual direct gains to themselves or their progeny or relatives > or allies, but such details are often outside the ken of the very beings > who execute such survival strategies: brains are pieces of meat that have > been hacked to act as action-reaction engines, but are not sophisticated > enough to execute as pure rationality engines at all times). > Fortunately, in the Bitcoin world, only purely rational beings of pure > selfishness can exist in the long run, thus we can neglect such motivations > as mere noise. > > First, let us investigate *how* griefing attacks can be performed. > > * An intermediate node in a multi-hop attempt can delay forwarding or > failing an incoming HTLC. > * A final node in a payment attempt can delay claiming an incoming HTLC. > > Let us consider a purely rational intermediate node of pure selfishness: > > * If it forwards as soon as possible, it can earn fees, and also speed up > the release of the HTLC-locked funds so that they can reuse those funds as > liquidity for further payment attempts. > * Thus, delaying an HTLC is not selfishly-rational for an intermediate > node. > > Thus, for an intermediate node, it seems there is no selfishly-rational > motivation to execute a griefing attack on an arbitrary payment attempt. > We can then conclude that an intermediate that delays a payment would do > so, not of its own rational self-interest, but as an accident, such as an > unforeseen connectivity or power failure. > > However, things are different when we consider a non-arbitrary payment. > Suppose a node were to make a payment attempt to itself, and deliberately > delay claiming this self-payment. > This lets any single node, *who happens to own large liquidity*, to lock > up the liquidity of other nodes. > > The motivation to lock up the liquidity of other nodes is to *eliminate > competition*. > Suppose we have a network as below: > > A -- B -- C > \ / >\ / > \ / > E > > When A and C want to transact with one another, they may choose to route > via either B or E. > B and E are th
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 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. _
Re: [Lightning-dev] A better encoding for lightning invoices
Good morning Bastien, > We believe the > same encoding could be used to compress the bitcoin blockchain. With more > training > data, we believe our AI-optimized mapping could allow bitcoin blocks to fit > in a > single tweet; we would then be able to use Twitter feeds to store the whole > blockchain. An utter derailment of this thread, but this claim seems to me a massive departure from my understanding of information theory. I am put to mind of the fable of the 1-bit image compressor, which can compress any image to just 1 bit; its decompression algorithm checked if the input bit is a 1 and if so, emitted the Lenna test image, and if the input bit was 0, would fail with a decompression error. Since the only requirement for publication in a journal is to be able to correctly compress and decompress the Lenna test image, the image compressor achieves 1-bit compression of any image, as shown by the successful compression and decompression of the Lenna test image. I wonder if the blockchain data is stored in the tweet, or in the AI that decides how to store it in the tweet. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Blind paths revisited
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 ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
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
[Lightning-dev] A better encoding for lightning invoices
Good morning list, In Bolt 11 we decided to use bech32 to encode lightning invoices. While bech32 has some nice properties, it isn't well suited for invoices. The main drawback of Bolt 11 invoices is their size: when you start adding routing hints or rendezvous onions, invoices become huge and hard to share. Empirical evidence shows that most lightning transactions are done over Twitter (73,41% of all lightning payments in 2019 were made via tweets). Since Twitter only allows up to 280 characters per tweet, this has severely impacted the development of new features for lightning. Anything that made an invoice bigger ended up being unused as users were left without any option to share those invoices. After several months of research and experimentation at Acinq Research, we have come up with a highly efficient invoice encoding, optimized primarily for Twitter. This has caused further delays in the development of our iOS wallet, but we felt this was a much higher priority. Our encoding uses an AI-optimized mapping from 11-bit words to Twitter emojis. Early results show that emoji invoices are more than 2 times smaller than legacy invoices. Reckless users are already using this in production: https://twitter.com/realtbast/status/1245258812279398400?s=20 https://twitter.com/acinq_co/status/1245258815597096960 There is a spec PR available at [1], along with reference eclair code [2]. We plan to release this feature in the next update of our Phoenix wallet [3]. We'd like feedback from this list on how to improve this further. We believe the same encoding could be used to compress the bitcoin blockchain. With more training data, we believe our AI-optimized mapping could allow bitcoin blocks to fit in a single tweet; we would then be able to use Twitter feeds to store the whole blockchain. Cheers, Bastien [1] https://github.com/lightningnetwork/lightning-rfc/pull/762 [2] https://github.com/ACINQ/eclair/tree/emoji-encoding [3] https://phoenix.acinq.co/ ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
