ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-09 📝 Original message: Good morning Tyler, > ...
📅 Original date posted:2018-04-09
📝 Original message:
Good morning Tyler,
> This is not the intention. This BOLT _does not_ replace bootstrapping seed functionality, now or ever. A client can supplement her view of the network by getting the graph from well-known nodes if she wishes, but no more. To do otherwise _would_ centralize the network to an uncomfortable degree. I used "autoconnect" because that's the terminology in the mobile wallet, but it is misleading.
Ah, I see. Should have been "autochannel" I suppose.
>> I am not sure how the risk gets managed if the public and private nodes are owned by the same economic entity.
>
> If the public facing node gets hacked, it cannot draw funds from the private node, only send them out to the attacker on the network, or close the channels and send the funds + wallet balance to an on-chain address. The "warm" funds in your example sit on the C side of the B -> C channel.
Let us break this down.
Suppose we start with this state:
A 2 <-> 0 B 2 <-> 0 C
Now, again, suppose the situation is that B and C are owned by the same economic entity, Tyler & Rompert Enterprises.
Suppose A pays 1 BTC to C:
A 1 <-> 1 B 1 <-> 1 C
Now suppose public node B is hacked. This means B can close the channels and move the funds onchain to the hacker onchain address. In that case, a total of 2 BTC can be stolen from node B.
Now suppose Tyler & Rompert Enterprises decides not to actually have a private node C. We start with this state:
A 2 <-> 0 B
Suppose A pays 1 BTC to B:
A 1 <-> 1 B
Now suppose public node B is hacked. This means B can close the channels and move the funds onchain to the hacker onchain address. In that case, a total of 1 BTC can be stolen from node B. Compare this to the previous situation, where 2 BTC can be stolen from node B, *precisely because of the existence of B<->C*.
So it is strictly better it seems, from a risk perspective, to just use a public node directly, than running a public node and one or more private nodes. You lose less this way than also funding a channel from your public to your private node.
Either that, or you contract to an external party who takes on the risk of running a public node, most likely in exchange for much higher feerates to your private node.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180409/c471c6ac/attachment.html>;
📝 Original message:
Good morning Tyler,
> This is not the intention. This BOLT _does not_ replace bootstrapping seed functionality, now or ever. A client can supplement her view of the network by getting the graph from well-known nodes if she wishes, but no more. To do otherwise _would_ centralize the network to an uncomfortable degree. I used "autoconnect" because that's the terminology in the mobile wallet, but it is misleading.
Ah, I see. Should have been "autochannel" I suppose.
>> I am not sure how the risk gets managed if the public and private nodes are owned by the same economic entity.
>
> If the public facing node gets hacked, it cannot draw funds from the private node, only send them out to the attacker on the network, or close the channels and send the funds + wallet balance to an on-chain address. The "warm" funds in your example sit on the C side of the B -> C channel.
Let us break this down.
Suppose we start with this state:
A 2 <-> 0 B 2 <-> 0 C
Now, again, suppose the situation is that B and C are owned by the same economic entity, Tyler & Rompert Enterprises.
Suppose A pays 1 BTC to C:
A 1 <-> 1 B 1 <-> 1 C
Now suppose public node B is hacked. This means B can close the channels and move the funds onchain to the hacker onchain address. In that case, a total of 2 BTC can be stolen from node B.
Now suppose Tyler & Rompert Enterprises decides not to actually have a private node C. We start with this state:
A 2 <-> 0 B
Suppose A pays 1 BTC to B:
A 1 <-> 1 B
Now suppose public node B is hacked. This means B can close the channels and move the funds onchain to the hacker onchain address. In that case, a total of 1 BTC can be stolen from node B. Compare this to the previous situation, where 2 BTC can be stolen from node B, *precisely because of the existence of B<->C*.
So it is strictly better it seems, from a risk perspective, to just use a public node directly, than running a public node and one or more private nodes. You lose less this way than also funding a channel from your public to your private node.
Either that, or you contract to an external party who takes on the risk of running a public node, most likely in exchange for much higher feerates to your private node.
Regards,
ZmnSCPxj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180409/c471c6ac/attachment.html>;