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. Please use it, break it, tell us what you like, and more importantly what you hate! ## How does it work? SimLN is setup agnostic. It can run on any test environment: local dev, signet, polar, scaling lightning, and the like! All you need is: * A network with open channels, where you have execution access on some of the nodes. * A config file that provides the simulator with node details. * Rust compiler installed. If you want to more precisely control the activity it generates, you can also configure specific payment flows like: send 100k from Alice to Bob every hour. Does this match mainnet? Obviously not. We have made many assumptions, and picked some (configurable) magic numbers. But we believe that providing a tool that allows easy testing against “busy” networks, even if it’s not the exact type of busy that we see in mainnet, allows more rigorous testing of changes and proposals. How is random activity generated? (Reader beware: this is the part with all the difficult math that I made Clara do for me) There are two magic numbers that we use to describe how we set up payments: * Capacity multiplier: a number representing how frequently a node sends its full balance/ capacity over a calendar month. For example, if a node starts with 1 BTC and sends 3 BTC over a calendar month, the Capacity multiplier is 3. * Expected payment amount: the expected payment amount in the network. Step 1: Payment Frequency For each node that will be sending payments, we use an exponential distribution to determine the amount of time between payments. You can think about this like bitcoin block times: we know how many payments we need to send to hit our capacity * multiplier in a month for our expected payment size. We’ll hit approximately that many when we sample this distribution, though the wait times will vary. Step 2: Payment Destination Destination nodes are selected using a weighted uniform distribution, using node capacity as weights. Our intuition here is that deployment of capital correlates with higher payment activity. Using this distribution, we’ll be more likely to pick larger nodes as destinations than smaller ones. Step 3: Payment Amount Once we have a source and destination node, we pick our payment amount using a log normal distribution with our expected payment amount as the mean. We also relate the variance in this distribution to the size of the sending and receiving node, to introduce more varied payment sizes for larger nodes and less varied for smaller nodes. On average we’ll send our expected payment amount, but the actual amount sent per individual payment will vary. I’ve intentionally left the mathematical details out, see [0] for full details of the design. ## Why does it suck? * It assigns the same capital efficiency to every node in the network, which certainly does not represent reality. * Destination nodes are weighted by capacity deployed, so it’s biased towards generating payments between large nodes. * The expected payment amount for individual nodes is likely dependent on the capacity they have deployed. * It’s a very new prototype, so it’s probably bug city. Please open up issues with vitriolic complaints! ## Why doesn’t it suck? * It saves you from boring manual generation or painful bash scripts! * It works anywhere, so can be dropped into your existing dev environment. * It can produce NPC (“non-player character”) background noise for you to run tests specific to your work on top of. * It makes deploying to production less scary. Join us in the simulation! Sergi, Jodom, Theo, Emanuel, Art, Stephan, Lamar and Carla [0] https://github.com/bitcoin-dev-project/sim-ln/issues/111
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
