[Lightning-dev] SimLN: Simulate active test networks

Hi List, Writing to announce SimLN: https://github.com/bitcoin-dev-project/sim-ln! SimLN is a tool that simulates random payment activity on any test lightning network setup. It aims to make it easier to test applications and proposals against networks that are actively processing payments.

Re: [Lightning-dev] Jamming Mitigation Dry Run

Hi Elias, Thanks for re-emphasizing the importance of being privacy-conscious as we look into this work - we completely agree! > clarify upfront whether you intend to time-box the collection period, where the data would be stored, and who would have access to it Our ideal collection period

[Lightning-dev] Jamming Mitigation Dry Run

Hi list, ## TL;DR We're moving ahead with the plan discussed at the summit to "dry run" HTLC endorsement and local reputation tracking to better inform our efforts to mitigate jamming attacks. Our goals are: * To use real-world data to sanity check the "steady state" behavior of local

[Lightning-dev] Specification Meeting Transcripts

Hi List, Since the beginning of the year we've made an effort to record and transcribe the specification meetings that we hold every other Monday. We've managed to keep the habit up, so I'm sharing here in the hopes that they'll be discovered by those who will find them useful. These transcripts

[Lightning-dev] LN Summit 2023 Notes

Hi List, At the end of June we got together in NYC for the annual specification meeting. This time around we made an attempt at taking transcript-style notes which are available here: https://docs.google.com/document/d/1MZhAH82YLEXWz4bTnSQcdTQ03FpH4JpukK9Pm7V02bk/edit?usp=sharing . To decrease

Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation

of HTLC traffic and > market forces. > > > > Looking forward to giving an update on Staking Credentials [0], an > end-to-end approach to mitigate channel jamming. > > > > Best, > > Antoine > > > > [0] > https://lists.linuxfoundation.org/pipermail

[Lightning-dev] HTLC Endorsement for Jamming Mitigation

Hi list, Some updates on channel jamming! # Next Call - Monday 01 May @ 15:00 UTC - https://meet.jit.si/UnjammingLN - Agenda: https://github.com/ClaraShk/LNJamming/issues/12 # Data Gathering During these weekly calls, we've come to agreement that we would like to gather data about the use of

[Lightning-dev] Jamming Mitigation Call Summary - 03/06

Hi list, Writing with a summary from our latest jamming mitigations call. Full transcript is available at [1]. Details for the next call: * Tuesday 21 March @ 17:00 UTC - *please note change of day/time* * https://meet.jit.si/UnjammingLN * Agenda: https://github.com/ClaraShk/LNJamming/issues/9

[Lightning-dev] Jamming Mitigation Call 02/20

Hi List, A reminder that we've got another jamming call coming up tomorrow. Monday 20 Feb 19:00 UTC https://meet.jit.si/UnjammingLN We'll be talking about local reputation scoring. Feel free to add additional agenda items here: https://github.com/ClaraShk/LNJamming/issues/4 Cheers, Carla and

[Lightning-dev] Jamming Mitigation Call Summary - 02/06

Hi list, Unfortunately we had some technical issues with the recording for Monday's call so we're going to have to rely on my memory (a severely corrupted data store). Thankfully, Clara jotted down some notes as well, but please chime in if you attended and we've missed something out! Details

[Lightning-dev] Jamming Mitigation Call Summary - 01/23

Hi list, On Monday last week we resumed our fortnightly channel jamming mitigation calls for 2023. Details for the next call: * Monday 02/06 @ 18:00 UTC * https://meet.jit.si/UnjammingLN * Agenda: https://github.com/ClaraShk/LNJamming/issues/2 # Meeting Summary This email attempts to summarize

Re: [Lightning-dev] Error Codes for LN

4`:`fieldnum`] 1. type: 5 (`suggested_value`) 2. data: * [`...*byte`:`value`] 1. type: 7 (`erroneous_value`) 2. data: * [`...*byte`:`value`] 1. type: 9 (`error_code`) 2. data: * [`u16`:`code`] Cheers, - Carla On Wed, Jul 7, 2021 at 2:36 AM Rusty Russel

[Lightning-dev] Error Codes for LN

Hi all, I’d like to make a case for re-purposing the existing error message (17) in the spec to allow for more structured errors, and create a path for standardized, enriched errors going forward. As is: the error message contains an arbitrary string, and is used to communicate fatal errors