From jim.posen at gmail.com Wed May 23 07:41:25 2018 From: jim.posen at gmail.com (Jim Posen) Date: Wed, 23 May 2018 00:41:25 -0700 Subject: [Lightning-dev] Mitigations for loop attacks In-Reply-To: References: <871seljpak.fsf@rustcorp.com.au> <1c4e8789-ed63-f06d-7c84-6dcba1f8a5f9@bitonic.nl> Message-ID: 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 at lists.linuxfoundation.org> wrote: > 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 discussion regarding it > is archived elsewhere; I do not know myself. > > Regards, > ZmnSCPxj > > ?Sent with ProtonMail Secure Email.? > > ??????? Original Message ??????? > > On May 22, 2018 11:47 PM, Corn? Plooy via Lightning-dev < > lightning-dev at lists.linuxfoundation.org> wrote: > > > > 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 > > > > Lightning-dev mailing list > > > > Lightning-dev at lists.linuxfoundation.org > > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > _______________________________________________ > Lightning-dev mailing list > Lightning-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: