Re: [Lightning-dev] TOR enabled dynamic Proof of Work defense for onion services
Hi Rene, > In their technical document [1] they mention that their new patch cannot defend against a large botnet and suggest that anonymous credentials [2] among other techniques should be investigated. >From my memory, mitigating channel jamming with dynamic proof-of-work (e.g bip154) was discussed during Zurich lightning event back in 2021, and discarded exactly on this motivation that it wouldn't fit the hashrate capabilities of a large botnet in the real-world of mobile-first client with constrained CPUs. The Tor scheme has been aware on my side since a while. Since then, I've been working on an implementation of Privacy Pass (quoted in the Kadianakis mail) dubbed Staking Credentials [0]. Primarily replacing cryptosystems by elliptic curve based rather than blinded RSA like the IETF draft [1] and with credentials loaded with sats as a user challenge. I'm currently working on a Rust implementation architecture-agnostic to fit the Lightning Network and Nostr-based services/routing purposes [2] [3]. Looking forward to a game-theory formalization of this system dynamics. Best, Antoine [0] https://bitcoinops.org/en/newsletters/2022/11/30/#reputation-credentials-proposal-to-mitigate-ln-jamming-attacks [1] https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-rsa-blind-signatures-03 [2] https://github.com/lightning/bolts/pull/1043 [3] https://github.com/civkit/staking-credentials Le dim. 27 août 2023 à 23:36, René Pickhardt a écrit : > Dear fellow Lightning Network developers, > > given the congestion problems with channels (aka jamming) that we are > facing and the various proposals and ideas that are floating around I > thought I quickly notify you that the TOR project has introduced a dynamic > proof of work system together with a market based auction system for > bandwidth via a priority queue to fight DoS attacks [0]. While our problems > differ I think there are still enough similarities to justify the relevance > of this mail. > > In their technical document [1] they mention that their new patch cannot > defend against a large botnet and suggest that anonymous credentials [2] > among other techniques should be investigated. > > Personal comment: I am a bit surprised that while they obviously looked at > Bitcoin they seemed to not have seriously considered to just use Bitcoin > (for example via Lightning Network paywalls) or a mining protocol directly. > Instead they argue that the auction based bids are more suitable than a > static difficulty target as used in bitcoin. However IMHO the dynamic > properties of their auction mechanism could easily have been achieve by the > amount of sats being offered instead of a dynamic proof of work solution. > > With kind regards Rene Pickhardt > > > [0] > https://blog.torproject.org/introducing-proof-of-work-defense-for-onion-services/ > > [1] > https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/327-pow-over-intro.txt > > [2] https://lists.torproject.org/pipermail/tor-dev/2020-March/014198.html > ___ > 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] TOR enabled dynamic Proof of Work defense for onion services
Maybe the anonymous credentials approach from [2] could use credentials loaded with sats? On Mon 28. 8. 2023 at 0:36, René Pickhardt wrote: > Dear fellow Lightning Network developers, > > given the congestion problems with channels (aka jamming) that we are > facing and the various proposals and ideas that are floating around I > thought I quickly notify you that the TOR project has introduced a dynamic > proof of work system together with a market based auction system for > bandwidth via a priority queue to fight DoS attacks [0]. While our problems > differ I think there are still enough similarities to justify the relevance > of this mail. > > In their technical document [1] they mention that their new patch cannot > defend against a large botnet and suggest that anonymous credentials [2] > among other techniques should be investigated. > > Personal comment: I am a bit surprised that while they obviously looked at > Bitcoin they seemed to not have seriously considered to just use Bitcoin > (for example via Lightning Network paywalls) or a mining protocol directly. > Instead they argue that the auction based bids are more suitable than a > static difficulty target as used in bitcoin. However IMHO the dynamic > properties of their auction mechanism could easily have been achieve by the > amount of sats being offered instead of a dynamic proof of work solution. > > With kind regards Rene Pickhardt > > > [0] > https://blog.torproject.org/introducing-proof-of-work-defense-for-onion-services/ > > [1] > https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/327-pow-over-intro.txt > > [2] https://lists.torproject.org/pipermail/tor-dev/2020-March/014198.html > ___ > 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
[Lightning-dev] TOR enabled dynamic Proof of Work defense for onion services
Dear fellow Lightning Network developers, given the congestion problems with channels (aka jamming) that we are facing and the various proposals and ideas that are floating around I thought I quickly notify you that the TOR project has introduced a dynamic proof of work system together with a market based auction system for bandwidth via a priority queue to fight DoS attacks [0]. While our problems differ I think there are still enough similarities to justify the relevance of this mail. In their technical document [1] they mention that their new patch cannot defend against a large botnet and suggest that anonymous credentials [2] among other techniques should be investigated. Personal comment: I am a bit surprised that while they obviously looked at Bitcoin they seemed to not have seriously considered to just use Bitcoin (for example via Lightning Network paywalls) or a mining protocol directly. Instead they argue that the auction based bids are more suitable than a static difficulty target as used in bitcoin. However IMHO the dynamic properties of their auction mechanism could easily have been achieve by the amount of sats being offered instead of a dynamic proof of work solution. With kind regards Rene Pickhardt [0] https://blog.torproject.org/introducing-proof-of-work-defense-for-onion-services/ [1] https://gitlab.torproject.org/tpo/core/torspec/-/blob/main/proposals/327-pow-over-intro.txt [2] https://lists.torproject.org/pipermail/tor-dev/2020-March/014198.html ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
