[c-lightning] refunding the active channels in LN

[ZmnSCPxj]

Good morning Sarat G.

It is better to forget about individual channels and better to consider network flows instead.

All you care about is whether you have incoming flow or not in order to receive your payout.

All you care about is whether you have outgoing flow or not in order to pay out your bet.

There is no need for the dealer node to be directly connected to the players.

Regards,
ZmnSCPxj

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, December 14, 2018 11:10 AM, Sarat G <sarath.ginjupalli89 at gmail.com> wrote:

> Hi  ZmnSCPxj,
>
> If what I mentioned above is ambiguous, I summarise my problem statement to as follows:
>
>> node A opens a channel with node B with a funding tx of 10000 satoshis(for the sake of example).
>> A  (10000)---------->B(0)
>
>> Now A pays 3000 satoshis to B.
>> A  (7000)---------->B(3000)
>
>> After this, if B decides to pay 10000 satoshis to A, it can't pay that amount via the existing LN channel as the balance in that channel at B is only 3000 satoshis.
>
> Any suggestions to solve this problem is very much appreciated.
> Thank You.
>
> Regards,
> Sarat G
>
> On Fri, Dec 14, 2018 at 8:24 AM Sarat G <sarath.ginjupalli89 at gmail.com> wrote:
>
>> Hi  ZmnSCPxj,
>>
>> Good Morning.
>>
>> Completely agree with you on setting up multiple channels. But my scenario is something similar to this.
>>
>> I'm designing a game, where in which the playing nodes can join the table at any moment and the table is maintained by a trusted node in the network. During the game, there is series of rounds of betting during which the playing nodes establishes the channels with the trusted node and make the payments and when the game is done, the trusted node pays back the amount to the playing node.
>>
>> Here the relationship between the playing node and trusted node often one time, unless the player chooses the same trusting node again. In these kind of scenarios I have no choice in establishing the route of payment via different lightning channels since the playing node doesn't aware of any other neighbours to the trusted node.
>>
>> In addition to this, say if node1 establishes the LN channel1 with node2 with a funding tx1, why doesn't node1 is prohibiting to establish the LN channel2 with funding tx2 with node2. Is this limitation is something part of the lightning spec or am I missing something here, please correct me.
>>
>> Thank You.
>> Regards,
>> Sarat G
>>
>> On Thu, Dec 13, 2018 at 6:30 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>>
>>> Best is to just open a channel to a different node.
>>> By maintaining multiple channels, you can be forwarding node.
>>>
>>> Deleting lightning state is a bad idea.
>>> You should consider multiple channels, not focus on just one channel to the network.
>>>
>>> Regards,
>>> ZmnSCPxj
>>>
>>> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>>>
>>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>>> On Thursday, December 13, 2018 8:20 PM, Sarat G <sarath.ginjupalli89 at gmail.com> wrote:
>>>
>>>> Hi  ZmnSCPxj,
>>>>
>>>> I encountered the issue mentioned here(https://github.com/ElementsProject/lightning/issues/1272). I understand the problem is relate to the channel capacity in my case.
>>>>
>>>> For that I'm trying to refund the channel with the higher amount and unfortunately it's not allowing me to refund the existing channel.
>>>>
>>>> I would like to know, what could be the work around in these kind scenarios, how can I increase the channel capacity in such cases?
>>>>
>>>> At this moment, I'm cleaning the peers and channels from the lightning sqlite3 database and restarting the lightningd, and then funding the channel with higher amounts inorder to make it work.
>>>>
>>>> Sorry for asking so many questions, your thoughts on this helpful to me.
>>>>
>>>> Regards,
>>>> Sarat G
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/c-lightning/attachments/20181216/dbe453a5/attachment.html>