Tyler H [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-09 📝 Original message: I understand now, I ...
📅 Original date posted:2018-04-09
📝 Original message:
I understand now, I hadn't fully considered the necessary channels for such
a configuration, though there is still the value of domain owners being
able to advertise preferred nodes to connect to in order to pay them
efficiently. The external party idea is interesting, but I'm fearful that
it can't be done in a way that retains a bare minimum of privacy.
Thanks,
Tyler
On Mon, Apr 9, 2018 at 8:58 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> 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/20180410/9d723a63/attachment.html>;
📝 Original message:
I understand now, I hadn't fully considered the necessary channels for such
a configuration, though there is still the value of domain owners being
able to advertise preferred nodes to connect to in order to pay them
efficiently. The external party idea is interesting, but I'm fearful that
it can't be done in a way that retains a bare minimum of privacy.
Thanks,
Tyler
On Mon, Apr 9, 2018 at 8:58 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> 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/20180410/9d723a63/attachment.html>;