đź“… Original date posted:2023-10-10
🗒️ Summary of this message: SimLN is a tool that simulates random payment activity on any lightning network setup, making it easier to test applications and proposals.
đź“ť Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20231010/db6cd1f5/attachment.html>;
Carla Kirk-Cohen [ARCHIVE] /
npub17x…anw36
2023-10-18 15:02:07
in reply to nevent1q…4cqv
Author Public Key
npub17xugd458km0nm8edu8u2efuqmxzft3tmu92j3tyc0fa4gxdk9mkqmanw36Published at
2023-10-18 15:02:07Event JSON
{
"id": "cc47916ed17def50856b3b9fc8b32beb8287b0bf005b6a22e664d3ef13dd7183",
"pubkey": "f1b886d687b6df3d9f2de1f8aca780d98495c57be15528ac987a7b5419b62eec",
"created_at": 1697634127,
"kind": 1,
"tags": [
[
"e",
"2013f622146dcfae144baf954f8ade71bcd6410836a6f9613b99f15d99278fb5",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2023-10-10\n🗒️ Summary of this message: SimLN is a tool that simulates random payment activity on any lightning network setup, making it easier to test applications and proposals.\n📝 Original message:\nHi List,\n\nWriting to announce SimLN: https://github.com/bitcoin-dev-project/sim-ln!\n\nSimLN is a tool that simulates random payment activity on any test\nlightning network setup. It aims to make it easier to test applications and\nproposals against networks that are actively processing payments.\n\nPlease use it, break it, tell us what you like, and more importantly what\nyou hate!\n\n## How does it work?\nSimLN is setup agnostic. It can run on any test environment: local dev,\nsignet, polar, scaling lightning, and the like!\n\nAll you need is:\n* A network with open channels, where you have execution access on some of\nthe nodes.\n* A config file that provides the simulator with node details.\n* Rust compiler installed.\n\nIf you want to more precisely control the activity it generates, you can\nalso configure specific payment flows like: send 100k from Alice to Bob\nevery hour.\n\nDoes this match mainnet?\nObviously not. We have made many assumptions, and picked some\n(configurable) magic numbers.\n\nBut we believe that providing a tool that allows easy testing against\n“busy” networks, even if it’s not the exact type of busy that we see in\nmainnet, allows more rigorous testing of changes and proposals.\n\nHow is random activity generated?\n(Reader beware: this is the part with all the difficult math that I made\nClara do for me)\n\nThere are two magic numbers that we use to describe how we set up payments:\n* Capacity multiplier: a number representing how frequently a node sends\nits full balance/ capacity over a calendar month. For example, if a node\nstarts with 1 BTC and sends 3 BTC over a calendar month, the Capacity\nmultiplier is 3.\n* Expected payment amount: the expected payment amount in the network.\n\nStep 1: Payment Frequency\nFor each node that will be sending payments, we use an exponential\ndistribution to determine the amount of time between payments. You can\nthink about this like bitcoin block times: we know how many payments we\nneed to send to hit our capacity * multiplier in a month for our expected\npayment size. We’ll hit approximately that many when we sample this\ndistribution, though the wait times will vary.\n\nStep 2: Payment Destination\nDestination nodes are selected using a weighted uniform distribution, using\nnode capacity as weights. Our intuition here is that deployment of capital\ncorrelates with higher payment activity. Using this distribution, we’ll be\nmore likely to pick larger nodes as destinations than smaller ones.\n\nStep 3: Payment Amount\nOnce we have a source and destination node, we pick our payment amount\nusing a log normal distribution with our expected payment amount as the\nmean. We also relate the variance in this distribution to the size of the\nsending and receiving node, to introduce more varied payment sizes for\nlarger nodes and less varied for smaller nodes. On average we’ll send our\nexpected payment amount, but the actual amount sent per individual payment\nwill vary.\n\nI’ve intentionally left the mathematical details out, see [0] for full\ndetails of the design.\n\n## Why does it suck?\n* It assigns the same capital efficiency to every node in the network,\nwhich certainly does not represent reality.\n* Destination nodes are weighted by capacity deployed, so it’s biased\ntowards generating payments between large nodes.\n* The expected payment amount for individual nodes is likely dependent on\nthe capacity they have deployed.\n* It’s a very new prototype, so it’s probably bug city. Please open up\nissues with vitriolic complaints!\n\n## Why doesn’t it suck?\n* It saves you from boring manual generation or painful bash scripts!\n* It works anywhere, so can be dropped into your existing dev environment.\n* It can produce NPC (“non-player character”) background noise for you to\nrun tests specific to your work on top of.\n* It makes deploying to production less scary.\n\nJoin us in the simulation!\nSergi, Jodom, Theo, Emanuel, Art, Stephan, Lamar and Carla\n\n[0] https://github.com/bitcoin-dev-project/sim-ln/issues/111\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20231010/db6cd1f5/attachment.html\u003e",
"sig": "e7a61433063039ecd9cf542f7d22fe26fce420c9d6c282a4549e491dcb9ce3040b8a8e211ca65415555cafef846a0f24da5247102b32ad472f91c8faf62192d0"
}