<p>First of all at this stage all lightning network nodes implementations are hot wallets. There are people / teams working on hardware wallets in lightning. Also I don't get your base assumption why you would trust casa which I believe  is not open source more than trusting btc pay server which I believe is open source. The only reason I see is that you control the hardware of your casa node and it is not some machine somewhere on the web in some datacenter. </p>

<p>But let us assume your setup and assumptions are valid then in step 6 and 7 of your process you don't need to close the channel. You could just withdraw the funds from your HWN to your casa node. As the entire channel balance is now at casa side there is no risk with HWN being compromised. This is as good as closing a channel moving funds and create a new one but saves onchain tx and fees. </p>

<p>In step 3 it is important to note that if you casa ode owns those payment channels your casa node can't receive funds or error payments to the HWN. Casa needs inbound capacity. So either you have others open channels to you (e. G. Your customers) or you have to use one of the many submarine swap services that exchange onchain to offchain funds. Such a service could also be used in step 6 and 7.</p>

<p>Overall the node of btc pay server could be private and configured to only accept traffic on port 9375 from your casa node. In this way you make sure only you have a payment channel with it. Since without rendez vous Routing all invoices of your store point to your casa node your cars node might now be at risk. </p>

<p>That all being said it seems to me that for the concerns that you have you don't need this setup with a proxy node. I am not saying that such a setup might not make sense for other reasons. </p>

CC BY-SA 4.0
2019-08-09T21:04:18.683Z
This is a fantastic detailed answer, thank you for answering. I'm still parsing the many points/suggestions.   I think I misunderstood something from the get-go: that all lighting wallets are currently hot wallets (I devised the above plan under the assumption that the Casa lightning wallet was not a hot wallet, or inherently safer..which is not necessarily true as you noted). . . . Very good suggestions, thanks again!
ijdh89
CC BY-SA 4.0
2019-08-10T07:31:47.953Z
If you are happy / satisfied with the response you can mark it as correct next to the voting points. This signals to others that the answer is answered. I am happy I could help
Rene Pickhardt
CC BY-SA 4.0
2019-07-28T03:48:19.763Z
2019-07-28T03:48:19.763Z
Rene Pickhardt
<p>(Edit: I realize how Mt.Gox-y the below setup sounds, but I'm coming at it from a "lightning routing problem perspective", not necessarily a straight "bitcoin security perspective"...though...those two things overlap quite a bit.)</p>

<p><strong>The setup/problem</strong>: 
I have two lightning nodes: (A) a Casa lightning node ("Casa-Node") that I trust in my apt, and (B) a BTCPayServer lightning node hot-wallet ("hot-wallet node"). </p>

<p>BTCpayServer makes it REALLY easy to integrate a btc and lightning payment pipeline into my website, however the btcpay website has a warning the lightning wallet is a hot wallet, unsafe(ish) :( </p>

<p>I'd like to use my Casa node with BTCpayServer but they (casa) don't have that functionality yet. I don't want to simply put thousands of dollars on my BTCpay LN hot-wallet, as I don't trust it. The think of the casa node = trustworthy-node, and the Hot-wallet = less trustworthy-node.</p>

<p><strong>A potential solution?</strong> 
Came up with this idea: use my Casa Node as my primary routing node with payments coming in from strangers/customers, and have only one channel between my Casa Node and my Hot Wallet Node..so all LNpayment requests generated by the Hot Wallet Node get routed through the Casa Node, and I can easily balance the Casa/HotWallet, channel balance as needed (at the end of the day, move the funds back to the Casa Node and close that one channel out on-chain). </p>

<p><strong>Example flow</strong>: </p>

<ul>
<li>CasaNode = CN</li>
<li>BTCPAY Hot-wallet = HWN</li>
<li>Other nodes trying to pay HWN = L1, L2, L3</li>
</ul>

<p><em>Step 1</em>: Setup my website with BTCPay server, and enable HWN for the lightning payment pipeline. (assume my website is CatToys.info, and I sell four different $25 dollar items..made up but it helps the picture). </p>

<p><em>Step 2</em>: Create a big LNchannel between my CN (more secure) and HWN (less secure storefront node). E.g., create a $1,000 payment channel between my Casa Node and the BTCPay Lightning Hot Wallet Node.  </p>

<p><em>Step 3</em>: Create a bunch of random payment channels between CN and other big nodes in the lightning network. These random payment channels increase the odds of a routing path being found between a given website customer's LN node and HWN node that generated the LNrequest (e.g., the BTCpay server that is generating the lightning payment request). </p>

<p><em>Step 4</em>: Random customer browses CatToys.info, checks out via, which causes BTCPayserver to generate a lightning payment request for $25 via the HWN node. </p>

<p><em>Step 5</em>: Customer uses his lightning node (L1) to pay HWN...the routing proceeds as follows: </p>

<ul>
<li>$25 (in btc) from L1 --> CN --> HWN. </li>
</ul>

<p>Other customer use the same flow: </p>

<ul>
<li>$25 (in btc) From L2 --> CN --> HWN </li>
<li>$25 (in btc) From L3 --> CN --> HWN</li>
</ul>

<p><em>Step 6</em>: At the end of the day, HWN has 75 dollars (from the three customers paying 25 each for a cat toy). When I want to "close the store down" (which is a brick/morter thing to say, but just stay with me), I move all the funds in the CN--HWN channel back to CN, so the full $1000 is back on CN (i.e., move $75 back to CN), then close the channel out on-chain.</p>

<p><em>Step 7</em>: if I need to "open the store" for the next day, I just need to recreate a single channel from CN---HWN, which is cheap as it's only a single channel to open up, and CN is ready to go (always connecting to lots of nodes (and CN is trust worthy)).</p>

<p><em>This approach would</em>: let me use BTCPay server's hot wallet (or any wallet that I don't trust too much) with larger-ish funds, and give my hot-wallet channel instant liquidity by connecting to CN, and I would only need to worry about closing/opening/rebalancing a single lightning payment channel between CN----HWN, instead of trying to constantly open channels with different amounts of funding to keep my website enabled to receive lightning payments. </p>

<p>Thoughts? Would the above sequence work in the lightning network? And be safe/secure, and would payments actually be successfully routed to the website okay? </p>

<p>Any input appreciated, thx. </p>

<wallet><lightning-network><lightning-routing><proxy>
Would proxying a lightning hot-wallet with a lightning cold-wallet make the hot-wallet safer?
ijdh89
# Would proxying a lightning hot-wallet with a lightning cold-wallet make the hot-wallet safer?

(Asked by: username_0 on 2019-07-28)

(Edit: I realize how Mt.Gox-y the below setup sounds, but I'm coming at it from a "lightning routing problem perspective", not necessarily a straight "bitcoin security perspective"...though...those two things overlap quite a bit.)

**The setup/problem**:
I have two lightning nodes: (A) a Casa lightning node ("Casa-Node") that I trust in my apt, and (B) a BTCPayServer lightning node hot-wallet ("hot-wallet node").

BTCpayServer makes it REALLY easy to integrate a btc and lightning payment pipeline into my website, however the btcpay website has a warning the lightning wallet is a hot wallet, unsafe(ish) :(

I'd like to use my Casa node with BTCpayServer but they (casa) don't have that functionality yet. I don't want to simply put thousands of dollars on my BTCpay LN hot-wallet, as I don't trust it. The think of the casa node = trustworthy-node, and the Hot-wallet = less trustworthy-node.

**A potential solution?**
Came up with this idea: use my Casa Node as my primary routing node with payments coming in from strangers/customers, and have only one channel between my Casa Node and my Hot Wallet Node..so all LNpayment requests generated by the Hot Wallet Node get routed through the Casa Node, and I can easily balance the Casa/HotWallet, channel balance as needed (at the end of the day, move the funds back to the Casa Node and close that one channel out on-chain).

**Example flow**:

* CasaNode = CN
* BTCPAY Hot-wallet = HWN
* Other nodes trying to pay HWN = L1, L2, L3

*Step 1*: Setup my website with BTCPay server, and enable HWN for the lightning payment pipeline. (assume my website is CatToys.info, and I sell four different $25 dollar items..made up but it helps the picture).

*Step 2*: Create a big LNchannel between my CN (more secure) and HWN (less secure storefront node). E.g., create a $1,000 payment channel between my Casa Node and the BTCPay Lightning Hot Wallet Node.

*Step 3*: Create a bunch of random payment channels between CN and other big nodes in the lightning network. These random payment channels increase the odds of a routing path being found between a given website customer's LN node and HWN node that generated the LNrequest (e.g., the BTCpay server that is generating the lightning payment request).

*Step 4*: Random customer browses CatToys.info, checks out via, which causes BTCPayserver to generate a lightning payment request for $25 via the HWN node.

*Step 5*: Customer uses his lightning node (L1) to pay HWN...the routing proceeds as follows:

* $25 (in btc) from L1 --> CN --> HWN.

Other customer use the same flow:

* $25 (in btc) From L2 --> CN --> HWN
* $25 (in btc) From L3 --> CN --> HWN

*Step 6*: At the end of the day, HWN has 75 dollars (from the three customers paying 25 each for a cat toy). When I want to "close the store down" (which is a brick/morter thing to say, but just stay with me), I move all the funds in the CN--HWN channel back to CN, so the full $1000 is back on CN (i.e., move $75 back to CN), then close the channel out on-chain.

*Step 7*: if I need to "open the store" for the next day, I just need to recreate a single channel from CN---HWN, which is cheap as it's only a single channel to open up, and CN is ready to go (always connecting to lots of nodes (and CN is trust worthy)).

*This approach would*: let me use BTCPay server's hot wallet (or any wallet that I don't trust too much) with larger-ish funds, and give my hot-wallet channel instant liquidity by connecting to CN, and I would only need to worry about closing/opening/rebalancing a single lightning payment channel between CN----HWN, instead of trying to constantly open channels with different amounts of funding to keep my website enabled to receive lightning payments.

Thoughts? Would the above sequence work in the lightning network? And be safe/secure, and would payments actually be successfully routed to the website okay?

Any input appreciated, thx.

**Tags:** wallet, lightning-network, lightning-routing, proxy


---

## 1 answers

### Answer by username_1 on 2019-07-28. Score: 1

First of all at this stage all lightning network nodes implementations are hot wallets. There are people / teams working on hardware wallets in lightning. Also I don't get your base assumption why you would trust casa which I believe is not open source more than trusting btc pay server which I believe is open source. The only reason I see is that you control the hardware of your casa node and it is not some machine somewhere on the web in some datacenter.

But let us assume your setup and assumptions are valid then in step 6 and 7 of your process you don't need to close the channel. You could just withdraw the funds from your HWN to your casa node. As the entire channel balance is now at casa side there is no risk with HWN being compromised. This is as good as closing a channel moving funds and create a new one but saves onchain tx and fees.

In step 3 it is important to note that if you casa ode owns those payment channels your casa node can't receive funds or error payments to the HWN. Casa needs inbound capacity. So either you have others open channels to you (e. G. Your customers) or you have to use one of the many submarine swap services that exchange onchain to offchain funds. Such a service could also be used in step 6 and 7.

Overall the node of btc pay server could be private and configured to only accept traffic on port 9375 from your casa node. In this way you make sure only you have a payment channel with it. Since without rendez vous Routing all invoices of your store point to your casa node your cars node might now be at risk.

That all being said it seems to me that for the concerns that you have you don't need this setup with a proxy node. I am not saying that such a setup might not make sense for other reasons.

> **Comments:**
> **username_0**: This is a fantastic detailed answer, thank you for answering. I'm still parsing the many points/suggestions.   I think I misunderstood something from the get-go: that all lighting wallets are currently hot wallets (I devised the above plan under the assumption that the Casa lightning wallet was not a hot wallet, or inherently safer..which is not necessarily true as you noted). . . . Very good suggestions, thanks again!  
> **username_1**: If you are happy / satisfied with the response you can mark it as correct next to the voting points. This signals to others that the answer is answered. I am happy I could help  

---

