<p>The short answer is no. It is not and will never be possible to start a regtest emulating the live lightning network one to one.</p>
<p>Take for example the <code>node_id</code> that each node has in the network. It is the public key to a corresponding private key that only the operator of that node knows, and much of our protocols rely on being able to either prove that you are a given node (signatures) or be able to establish confidential communication with that node. So your network will have to differ when it comes to <code>node_id</code>s. Furthermore transactions that fund channels on the mainnet also use signatures to prove ownership, and there is little point in replicating 100M transactions on regtest (which btw has different block intervals and subsidies) to get the exact same <code>short_channel_id</code>s used to refer to channels.</p>
<p>That being said, you can get close, if you're ok with having a mapping of <code>regtest_node_id</code> -&gt; <code>mainnet_node_id</code> and the same for <code>short_channel_id</code>s. So structurally replicating the network to perform experiments on the network is possible, but you might need tooling to help.</p>
<p>That is for the visible part of the network, but keep in mind that not all the network participants announce their channels and nodes, so be sure that whatever you want to test mainly considers the core routing network and doesn't rely heavily on endpoint behavior.</p>
<p>One last thing: emulating the real network is but the first step, you'll also have to characterise how nodes behave (who initiates a payment to whom at what time?). That will likely be a major part of your research as imbalances that you try to compensate by looking into rebalancing strategies is essentially what you want to simulate, and that's where user behavior as well as higher level concepts such as source-subgraphs and sink-subgraphs come into play. Simple assumptions (e.g., all-pairs equal source-destination) may help you here, but be sure to point out this assumption explicitly so people don't try to transfer the result to cases where this assumption is not true.</p>

CC BY-SA 4.0
2022-11-04T18:18:22.250Z
Thank you very much for your reply! I was expecting that response and now see the big picture better. I also understand the importance of having assumptions to limit the range of my conclusions and their correctness. But could you specify what exactly you mean by all-pairs equal source destination? Do you suggest considering only zero-hop payments?
dancingsushi
CC BY-SA 4.0
2022-11-05T12:57:06.567Z
It essentially just means that to simulate a payment you pick a random sender and a random recipient out of all the nodes in the network. It's the least specific assumption you can make, and likely wrong, but a good approximation given that we don't really know if and where clusters of senders / recipients are on the network. This can (and should) be refined as we learn more about user behavior on the network.
cdecker
CC BY-SA 4.0
2022-11-04T14:08:47.407Z
2022-11-04T14:14:02.877Z
2022-11-04T14:14:02.877Z
cdecker
<p>I am currently writing a bachelor thesis where I plan to conduct some experiments on <code>regtest</code> network to evaluate how effective a particular rebalancing algorithm performs compared to currently used rebalancing solutions. Previously, during the research phase, I had in mind to run it on the <code>testnet</code>, but then I realized that it wouldn't make a lot of sense because of unfair circumstances (I would not be able to rebalance on the same network/graph states). This led me to the idea of using <code>regtest</code> to be able to simulate and experiment with networks under the same conditions. But this is not a perfect environment either, as it is a sandbox environment, and I have to monitor the state of the whole network myself. I use the <a href="https://github.com/cmdruid/regtest-workbench" rel="nofollow noreferrer"><code>regtest</code> workbench</a> and it makes my job a lot easier in many ways, but now I'm faced with an important question, the answer to which would help me bring my local network closer to the real setup. Namely, <em><strong>is there any way to import a lightning network snapshot into the <code>regtest</code> local network?</strong></em></p>
<p>As far as I understand, this question has already been answered <a href="https://bitcoin.stackexchange.com/questions/52062/regtest-setup-to-analyze-the-protocol">here</a>, but perhaps something has changed.</p>
<p>Do you think <em><strong>I have taken the right approach to do the needed experiments?</strong></em> I would like to play with my rebalancing method on <code>testnet</code> as well, but as I see it now, I would not be able to draw any conclusions as I would not have a comparative factor. In that case, I don't see any contribution a bachelor's work could have made. <em><strong>Maybe you could advise something useful for this vector of work in the context of the libraries and projects?</strong></em></p>
<p>Thanks in advance for the answers!</p>

<bitcoin-core><lightning-network><testnet><regtest><core-lightning>
Is it possible to import a LN snapshot into the regtest network (possibly pruned version)?
dancingsushi
# Is it possible to import a LN snapshot into the regtest network (possibly pruned version)?

(Asked by: username_0 on 2022-11-04)

I am currently writing a bachelor thesis where I plan to conduct some experiments on `regtest` network to evaluate how effective a particular rebalancing algorithm performs compared to currently used rebalancing solutions. Previously, during the research phase, I had in mind to run it on the `testnet`, but then I realized that it wouldn't make a lot of sense because of unfair circumstances (I would not be able to rebalance on the same network/graph states). This led me to the idea of using `regtest` to be able to simulate and experiment with networks under the same conditions. But this is not a perfect environment either, as it is a sandbox environment, and I have to monitor the state of the whole network myself. I use the [`regtest` workbench](https://github.com/cmdruid/regtest-workbench) and it makes my job a lot easier in many ways, but now I'm faced with an important question, the answer to which would help me bring my local network closer to the real setup. Namely, ***is there any way to import a lightning network snapshot into the `regtest` local network?***

As far as I understand, this question has already been answered [here](https://bitcoin.stackexchange.com/questions/52062/regtest-setup-to-analyze-the-protocol), but perhaps something has changed.

Do you think ***I have taken the right approach to do the needed experiments?*** I would like to play with my rebalancing method on `testnet` as well, but as I see it now, I would not be able to draw any conclusions as I would not have a comparative factor. In that case, I don't see any contribution a bachelor's work could have made. ***Maybe you could advise something useful for this vector of work in the context of the libraries and projects?***

Thanks in advance for the answers!

**Tags:** bitcoin-core, lightning-network, testnet, regtest, core-lightning


---

## 1 answers

### Answer by username_1 on 2022-11-04. Score: 2 | Accepted answer

The short answer is no. It is not and will never be possible to start a regtest emulating the live lightning network one to one.

Take for example the `node_id` that each node has in the network. It is the public key to a corresponding private key that only the operator of that node knows, and much of our protocols rely on being able to either prove that you are a given node (signatures) or be able to establish confidential communication with that node. So your network will have to differ when it comes to `node_id`s. Furthermore transactions that fund channels on the mainnet also use signatures to prove ownership, and there is little point in replicating 100M transactions on regtest (which btw has different block intervals and subsidies) to get the exact same `short_channel_id`s used to refer to channels.

That being said, you can get close, if you're ok with having a mapping of `regtest_node_id` -> `mainnet_node_id` and the same for `short_channel_id`s. So structurally replicating the network to perform experiments on the network is possible, but you might need tooling to help.

That is for the visible part of the network, but keep in mind that not all the network participants announce their channels and nodes, so be sure that whatever you want to test mainly considers the core routing network and doesn't rely heavily on endpoint behavior.

One last thing: emulating the real network is but the first step, you'll also have to characterise how nodes behave (who initiates a payment to whom at what time?). That will likely be a major part of your research as imbalances that you try to compensate by looking into rebalancing strategies is essentially what you want to simulate, and that's where user behavior as well as higher level concepts such as source-subgraphs and sink-subgraphs come into play. Simple assumptions (e.g., all-pairs equal source-destination) may help you here, but be sure to point out this assumption explicitly so people don't try to transfer the result to cases where this assumption is not true.

> **Comments:**
> **username_0**: Thank you very much for your reply! I was expecting that response and now see the big picture better. I also understand the importance of having assumptions to limit the range of my conclusions and their correctness. But could you specify what exactly you mean by all-pairs equal source destination? Do you suggest considering only zero-hop payments?  
> **username_1**: It essentially just means that to simulate a payment you pick a random sender and a random recipient out of all the nodes in the network. It's the least specific assumption you can make, and likely wrong, but a good approximation given that we don't really know if and where clusters of senders / recipients are on the network. This can (and should) be refined as we learn more about user behavior on the network.  

---

