Only place I see the onion peeling discussed is here:
https://github.com/lightningnetwork/lightning-rfc/issues/182.
On Tue, May 22, 2018 at 3:50 PM, ZmnSCPxj via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> wrote:
> Good morning Corne,
>
> I think onion unpeeling never made it into th
Good morning Corne,
I think onion unpeeling never made it into the BOLT spec precisely due to the
problems with it. I think the unpeeling in question is essentially a hop node
(rather than the ultimate payer/source) unpeeling the onion in order to find
out who was being slow. Perhaps the discu
> You missed the vital detail: that you must prove channel closure if you
> can't unpeel the onion further. That *will* hit an unresponsive party
> with a penalty.[1]
Is this specified in a BOLT somewhere? I tried to find it several times,
without success.
CJP
_
Yes Rusty, you are correct that an attacker still gets leverage on their
ability to destroy reputation unless the loss rates increase exponentially.
And I agree that would be a very steep increase, serving do decrease
circuit lengths dramatically. The reasoning for the linear increase in
reputation
Good morning Rusty,
> Also, you talked about reputation_loss_rate as being a private per-node
>
> thing, and being an explicit thing in the HTLC. I'm ignoring the
>
> former, and assuming the latter.
Reputation (the score) is a private per-node thing, while the
`reputation_loss_rate` is expli
ZmnSCPxj writes:
>>> Please describe the below:
>>>
>>> 1. Behavior if payment succeeds after T time.
>>> 2. Behavior if payment fails after T time.
>>>
>>> It seems you only described "Behavior if payment succeeds after T time".
>>
>> Ah, sorry if I didn't make that clear. The reputation is inc
Good morning Jim,
>> This can still be manipulated if Rusty1 opens a direct channel to Jim. Then
>> Rusty1 can route payments Rusty1->Jim->Rusty2 that succeed quickly, then
>> route payments Rusty1->ZmnSCPxj->Jim->Rusty2 that stall. Thus Rusty2 can
>> have the Jim->Rusty2 reputation boosted,
>
> This can still be manipulated if Rusty1 opens a direct channel to Jim.
> Then Rusty1 can route payments Rusty1->Jim->Rusty2 that succeed quickly,
> then route payments Rusty1->ZmnSCPxj->Jim->Rusty2 that stall. Thus Rusty2
> can have the Jim->Rusty2 reputation boosted, while alternating with
>
Good morning,
>> But I can make you look like a delaying node whenever I want. The only
>> way to ensure that I lose more reputation than you do is to leak
>> information about route length for *everyone*. And even then, it's just
>> a matter of numbers. I can make successful payments to myself
>
> You're forgetting the failure cases, where now I can profit.
>
> If I disconnect from another node, I now have a disincentive to tell
> others. At the moment we send an update disabling the channel (though
> we should give a few seconds for reconnect first, but whatever).
>
> Similarly, the re
Jim Posen writes:
> Thanks for the thoughtful responses.
>
>> You missed the vital detail: that you must prove channel closure if you
>> can't unpeel the onion further. That *will* hit an unresponsive party
>> with a penalty.
>
> Ah, that is a good point. I still find the proposal overall worryin
On Fri, May 11, 2018 at 9:18 AM, Jim Posen wrote:
> Hmm, I'm not quite following the situation. What do you mean by "directs
> normal traffic"? Since the sender constructs the entire circuit, routing
> nodes do not get any discretion over which nodes to forward a payment to,
> only whether to f
Hmm, I'm not quite following the situation. What do you mean by "directs
normal traffic"? Since the sender constructs the entire circuit, routing
nodes do not get any discretion over which nodes to forward a payment to,
only whether to forward or fail. What an attacker could do is perform a
loop at
hello, I'm a curious lurker trying to follow this conversation:
On Thu, 10 May 2018, 2:40 pm ZmnSCPxj via Lightning-dev, <
lightning-dev@lists.linuxfoundation.org> wrote:
>
> The concern however is that the CLTV already partly leaks the distance
> from the payee, whereas the reputation-loss-rate
Good morning Jim,
> One more point in terms of information leakage is that noise can be added to
> the "this is the rate that you'll lose reputation at" field to help obfuscate
> the number of upstream hops. I proposed setting it to "this is the upstream
> rate that I'm losing reputation at" +
One more point in terms of information leakage is that noise can be added
to the "this is the rate that you'll lose reputation at" field to help
obfuscate the number of upstream hops. I proposed setting it to "this is
the upstream rate that I'm losing reputation at" + downstream HTLC value,
but a n
Thanks for the thoughtful responses.
> You missed the vital detail: that you must prove channel closure if you
> can't unpeel the onion further. That *will* hit an unresponsive party
> with a penalty.
Ah, that is a good point. I still find the proposal overall worryingly
complex in terms of comm
Good morning Rusty, Jim, and list,
> I can destroy your node's reputation by routing crap through you; even
>
> if it costs me marginaly more reputation than it does you, that just
>
> means that the largest players can force failure upon smaller players,
>
> centralizing the network.
My under
Jim Posen writes:
> There are two directions of solutions I have heard: 1) protocol support for
> decrypting the onion route if the HTLC is kept in-flight for too long 2)
> requiring fees even if the payment fails as a cost to the attacker 3) some
> sort of reputation system for nodes.
>
> Option
I have been thinking a lot lately about attacks on lightning routing nodes,
the worst of which is the so-called Loop Attack [1]. See the mailing list
thread for more details, but the basic idea is that a sender and receiver
collude to create a long circuit and refuse to settle or fail the HTLC at
t
20 matches
Mail list logo
