ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-02-02 📝 Original message: Good morning Cezary, > ...
📅 Original date posted:2018-02-02
📝 Original message:
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/aea3e478/attachment-0001.html>;
📝 Original message:
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/aea3e478/attachment-0001.html>;