<p>What you’ve described is just a subset of possible architectures that are currently capable of being created using payment channels (the lightning network). Yes, this sort of ‘server/client’ relationship could/does exist (though I’m not sure I would call it that, exactly), but it’s also possible for any of the nodes involved in it to open channels with other nodes on the network as well.</p>
<blockquote>
<p>Are there any downsides of this approach apart from the clear fact that in order to make payments users have to use (but not trust!) the same Server?</p>
</blockquote>
<ul>
<li>Being <em>required</em> to use this server <em>is</em> the downside: lightning is otherwise a free and open network, which allows users to independently allocate their capital in ways which they find beneficial and efficient.</li>
<li>you’ve mentioned a ‘light client’, which implies a client that does not fully validate the network state. This leaves open some vulnerabilities, in that the ‘server’ could provide false information to light-clients, in a way which they could not easily detect. The specifics of this would depend on the implementation details, of course.</li>
<li>having a single ‘server’ is a critical risk to the network: if it goes offline or is hacked, etc, then this mini-lightning-network will be taken offline entirely. Compare this to a more distributed architecture, where losing any one node is of minimal effect on the ability of other nodes to interact with each other.</li>
</ul>

CC BY-SA 4.0
2021-06-09T19:45:59.803Z
Indeed & I agree that a whole network is much more beneficial & fault-tolerant. On the other hand it might yield more complex implementations as we're seeing with slower user-mass adoption. In a Client-Server network topology what would the channels look like? For instance if I start a channel with the server of 1 btc then I can't receive money until I spend money (bi-directional). And would you know if any of these  lightning client-server models exist?
Luca Matteis
CC BY-SA 4.0
2021-06-09T17:53:51.320Z
2021-06-09T17:53:51.320Z
chytrik
<p>Let's imagine a minimal version of the Lightning network with a single &quot;central&quot; lightning node (say a service provider which we can call a Server) surrounded by thin clients (the actual users potentially simply using open-source client software on their phone).</p>
<p>The network part in this scenario is non-existant as communication simply happens between Users &lt;-&gt; Server. Obviously to pay anybody in this system both users have to use the same Server.</p>
<p>I would imagine then each User simply having a channel open with the Server and whenever users Alice &amp; Bob need to make payments with each other they simply use their single open channel with Server, and Server adjusts the 2 channels accordingly to follow on the payment. (<strong>I imagine some issues here with the payment not being possible if the channels are not funded in the direction needed for the payment</strong>).</p>
<p>Alice &amp; Bob then each get their confirmation instantly validated by their open-source thin client (hence no trust with Server is needed).</p>
<p>I know there's has been lots of research and complexity around the &quot;network&quot; part of Lightning (such as routing mechanisms, funding channels, knowledge &amp; discovery of network typography etc.) hence I was curious whether a simpler Client&lt;-&gt;Server approach as mentioned above would be an easier and more user-friendly implementation strategy for simpler use-cases (such as regular users using a non-trusted central server like somelightningnode.com).</p>
<p>Are there any downsides of this approach apart from the clear fact that in order to make payments users have to use (but not trust!) the same Server?</p>

<lightning-network><lightning-service-provider>
Can Lightning work without the "network" part?
Luca Matteis
# Can Lightning work without the "network" part?

(Asked by: username_0 on 2021-06-09)

Let's imagine a minimal version of the Lightning network with a single "central" lightning node (say a service provider which we can call a Server) surrounded by thin clients (the actual users potentially simply using open-source client software on their phone).

The network part in this scenario is non-existant as communication simply happens between Users <-> Server. Obviously to pay anybody in this system both users have to use the same Server.

I would imagine then each User simply having a channel open with the Server and whenever users Alice & Bob need to make payments with each other they simply use their single open channel with Server, and Server adjusts the 2 channels accordingly to follow on the payment. (**I imagine some issues here with the payment not being possible if the channels are not funded in the direction needed for the payment**).

Alice & Bob then each get their confirmation instantly validated by their open-source thin client (hence no trust with Server is needed).

I know there's has been lots of research and complexity around the "network" part of Lightning (such as routing mechanisms, funding channels, knowledge & discovery of network typography etc.) hence I was curious whether a simpler Client<->Server approach as mentioned above would be an easier and more user-friendly implementation strategy for simpler use-cases (such as regular users using a non-trusted central server like somelightningnode.com).

Are there any downsides of this approach apart from the clear fact that in order to make payments users have to use (but not trust!) the same Server?

**Tags:** lightning-network, lightning-service-provider


---

## 1 answers

### Answer by username_1 on 2021-06-09. Score: 1

What you’ve described is just a subset of possible architectures that are currently capable of being created using payment channels (the lightning network). Yes, this sort of ‘server/client’ relationship could/does exist (though I’m not sure I would call it that, exactly), but it’s also possible for any of the nodes involved in it to open channels with other nodes on the network as well.

> Are there any downsides of this approach apart from the clear fact that in order to make payments users have to use (but not trust!) the same Server?

* Being *required* to use this server *is* the downside: lightning is otherwise a free and open network, which allows users to independently allocate their capital in ways which they find beneficial and efficient.
* you’ve mentioned a ‘light client’, which implies a client that does not fully validate the network state. This leaves open some vulnerabilities, in that the ‘server’ could provide false information to light-clients, in a way which they could not easily detect. The specifics of this would depend on the implementation details, of course.
* having a single ‘server’ is a critical risk to the network: if it goes offline or is hacked, etc, then this mini-lightning-network will be taken offline entirely. Compare this to a more distributed architecture, where losing any one node is of minimal effect on the ability of other nodes to interact with each other.

> **Comments:**
> **username_0**: Indeed & I agree that a whole network is much more beneficial & fault-tolerant. On the other hand it might yield more complex implementations as we're seeing with slower user-mass adoption. In a Client-Server network topology what would the channels look like? For instance if I start a channel with the server of 1 btc then I can't receive money until I spend money (bi-directional). And would you know if any of these  lightning client-server models exist?  

---

