Thank you very much for answer.

Thanks for explanation about 'channel_reserve_satoshis'. I misunderstood '
channel_reserve_satoshis ' with 'dust_limit'.

Lets say I would like to receive ln payments. How can I do this, without
locking funds on the other side of channel?

Best regards,
Cezary

2018-02-02 15:07 GMT+01:00 ZmnSCPxj <zmnsc...@protonmail.com>:

> Good morning Cezary,
>
> When we send open_channel, how we can communicate other party that we
> would like him to put into channel some of his funds?
>
>
> There is no way to do that  as of BOLT v1.0
>
> There are too many issues to allow channel opening by somebody else to ask
> your node to commit money into channels.
>
> 1.  If I ask you to put 10.0 BTC from you to put into a channel I make,
> and you accept, I know you have at least 10.0 BTC lying around.
> 2.  I might open a channel to you and ask you to put in money, then when
> you have committed the money into the channel, disconnect my node and
> reformat its hard disk, so that you are forced to use a unilateral close on
> your side, and locking your funds due to the unilateral close.  Even if
> there is a rule that I must commit at least the same amount as you, a
> richer attacker can still lock up the funds of a poorer victim.
>
> In general such dual-funded channels require some measure of trust between
> you and your counterparty due to the above issues, at least that you know
> that the one initiating the opening will not suddenly disappear.
>
> Such trust issues can be mitigated by simply disallowing dual-funding by
> default on your node, and requiring you to explicitly allow multi-funding,
> once, for a particular amount, coming from a particular peer.  But in any
> case, for now it is not defined in BOLT v1.0.
>
> Is this what is "channel_reserve_satoshis" field for?
>
>
> No.  `channel_reserve_satoshis` is different.  It is the amount that each
> of you should keep on the channel, once the channel state has moved from
> "all of the funds is assigned to the opener of the channel."
>
> The reason for this field is below.
>
> 1.  Suppose I open a 1BTC channel to you.  We agree to a
> `channel_reserve_satoshis` amounting to 0.1BTC.  The initial channel state
> is (me=1.0BTC, you=0BTC)
> 2.  This means I can make 9 payments of 0.1BTC each, so that the channel
> state is now (me=0.1BTC, you = 0.9BTC).
> 3.  The `channel_reserve_satoshis` means I cannot pay further to you, i.e.
> I cannot move the channel state to (me=0BTC, you=1BTC)..
> 4.  Suppose we allowed this (me=0BTC, you=1BTC) state.  Then it is
> costless for me to attempt to steal -- after all, I have 0 money on the
> channel and there is nothing to punish me with.  Even if I steal, and you
> detect it, I lose nothing because I own nothing on the channel.
> 5.  But if the channel is constrained, so that I need to keep 0.1BTC on
> the channel, then stealing attempts have a cost.  If you detect me, I stand
> to lose 0.1BTC.  If you have a better than 90% chance of detecting me, say
> 91%, a mere 9% chance of 0.9BTC payoff is not enough to counterbalance the
> 91% chance of losing 0.1BTC I currently have on the channel
> 6.  In short, the `channel_reserve_satoshis` ensures we do not have
> costless theft.
>
> Regards,
> ZmnSCPxj
>
>
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to