What is Nostr?
Cezary Dziemian [ARCHIVE] /
npub13gh…fght
2023-06-09 12:48:45
in reply to nevent1q…3zw3

Cezary Dziemian [ARCHIVE] on Nostr: 📅 Original date posted:2018-02-02 📝 Original message: Thank you very much for ...

📅 Original date posted:2018-02-02
📝 Original message:
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 <ZmnSCPxj at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180202/db61ac20/attachment.html>;
Author Public Key
npub13gh6gyar6e767uyntdradum63zhv2faha996en2hw4q5xx82kfsqe5fght