From cezary.dziemian at gmail.com Fri Feb 2 16:48:47 2018 From: cezary.dziemian at gmail.com (Cezary Dziemian) Date: Fri, 2 Feb 2018 17:48:47 +0100 Subject: [Lightning-dev] channel_reserve_satoshis? In-Reply-To: References: Message-ID: 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 : > 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: