Lloyd Fournier [ARCHIVE] on Nostr: 📅 Original date posted:2020-12-17 📝 Original message: On Thu, Dec 17, 2020 at ...
📅 Original date posted:2020-12-17
📝 Original message:
On Thu, Dec 17, 2020 at 1:56 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> A common occurrence is that hardware failure is not detected until when
the hardware is used, especially when used by casual users.
>
> Consider the sequence of events:
>
> * Part of the storage device fails.
> * Due to being a casual user, the user does not use state-of-the-art
checksumming filesystems like ZFS and does not monitor disk health by
S.M.A.R.T.
> * A high-onchain-fee condition exists.
> * The casual user attempts to send out a payment consisting of almost all
funds in their LN channels via several HTLCs on MPP or other multipath.
> * Because of the activity generated, the filesystem assigns the LN
database to the failing part.
> * Storage fails with most funds in outgoing HTLCs.
Note that this is fine if the payment goes through. Their counterparty will
have to go on-chain to claim the payment (since your node is down due to
data-loss) and then you claim whatever is left from your seed.
The main risk here is for routing nodes which are hopefully only using this
technique as a very poor last resort.
If you actually manage to get online and try to restore before the on-chain
settlement then just attaching outgoing HTLCs to the mutual close would be
fine -- that way the peer can still claim the money from you if the payment
goes through and you can get the refund if not.
The same could apply to incoming HTLCs as long as you can reproduce your
HTLC pre-image deterministically.
PS good to hear you are a ZFS user too
>
> Thus, merely activating the wallet and using HTLCs may result in a
*detectable* failure of the hardware (which was already failing before,
just not noticed by the casual user).
>
> On the other hand, we can consider this situation as having a complexity
penalty.
>
> As someone who has seen a lot of storage devices slowly fail in unique
and interesting (and data-losing) ways, I am always going to assume that
storage devices are going to fail at any time, including a few hours after
installation.
>
> It would be preferable if HTLCs and PTLCs are not gifted.
Yes I am convinced.
> >
> > > Using static-key channels (i.e. channel keys are our node keys)
allows us to recover even the outgoing channel with outgoing HTLC that has
been forgotten by the outgoing peer.
> >
> > Right. I think this doesn't work with PTLCs though.
>
> Yes, loss of the adaptor signature means we cannot recover in this case.
Let's think about this again. There is no reason why the oblivious mutual
close has to be the only thing the peer sends you upon connection. They can
also send you the necessary signatures for each PTLC output on the mutual
close because you can't do anything with this unless you choose to receive
the mutual close signature. You verify these each time you connect without
data loss so optimistically you should be able to recover both incoming and
outgoing PTLCs
> Right, that would work.
>
> How about just using a multiplicative tweak of your own privkey and the
pubkey of the other node (i.e. just use the "raw" ECDH point), that would
work as 2-of-2 in 2p-ECDSA, and I believe (but do not know) should also be
signable using MuSig/MuSig2 under taproot?
I think multiplicative combination of keys does *not* work for Schnorr
multisignatures.
>
> "Peer selling private information" is always going to be an issue with
unpublished channels, and this seems to be an inherent issue with that
model.
>
> Note that due to the existence of proof-of-discrete-log-equivalence, a
node operator can *prove* to someone buying private information that a
particular outpoint onchain is actually an unpublished channel.
> If I have privkey `z` and you have pubkey `L`, I can show `z * G` (my
node pubkey), `L` (your "unpublished" (ha, ha) node pubkey), and `z * L`
(our ECDH secret), plus a proof-of-discrete-log-equivalence that the `z` in
`z * G` is the same `z` in `z * L`, in order to convice them of the ECDH
secret.
> I suspect part of the proof-of-discrete-log-equivalance can be gated as
well by a ZKCP on payment point+scalar the proof is provided only on
payment.
> The selling node operator does not even need to reveal `z`.
>
> As the ECDH secret is what tweaks the channel keys, that is enough to
convince any surveilling buyer.
> Further, `z` is not revealed, and channel funds cannot be stolen by just
knowledge of the ECDH secret, thus protecting the interests of the selling
forwarding node.
>
> Now of course, I could just be making up `L` (i.e. LL could be a
sockpuppet of mine).
> However, between these two choices:
>
> * I lock up a set number of millisatoshi in a Z + L channel where L is a
sockpuppet, and sell this fake information to surveillors.
> * I lock up a set number of millisatoshi in a Z + L channel where L is a
genuine user node that thinks unpublished channels are private, and sell
this genuine information to surveillors.
>
> Which is more lucrative for me?
> The latter case would be more lucrative for me, as I not only earn from
selling your data to surveillors, I also earn routing fees.
> The former case can only earn me selling fake data to surveillors, with
no opportunity to earn forwarding fees.
Correct and interesting analysis. I agree that you don't want to
accidentally opt in to having your peer have a way to cryptographically
prove you have a channel with them.
Except in the situation where you are already cryptographically proving to
everyone you have a channel with them in the channel announcement.
>
> > A mitigation of this problem
> > would be for users who want unpublished channels to turn the
> > use-node-key-as-channel-key feature off for their keys in the channel
> > so they would still be able to do a backup-free channel scan but the
> > well-established node would lose the ability to do so.
>
> If the user has all channels unpublished, it is not (normally) gossiped.
> So the well-established node would not have the ability to recover *all*
channels by backup-free scans of published nodes in the first place, only
those that are to published nodes.
>
> Or do you refer to something else?
I was thinking about public nodes with un-announced channels.
For completely private/unpublished nodes then I agree with your statement
that there is no hope no matter how you compute the keys to recover
automatically.
>
> It might be easier for the "client" here to make up different node IDs
for each "server" it connects to, by e.g. hashing its base privkey with the
server pubkey and using the hash as the privkey for its fake node ID with
that server.
>
Right. Something like this is what I was suggesting for public nodes who
want to have unpublished channels that they want to be able to channel scan
for but *do not want the other party* to be able to do so (to avoid
concerns you made clear earlier).
I think there's no strong reason to make up a new node id -- it can just be
an option in open_channel like "use this key instead of my node id for
everything in this channel".
Cheers,
LL
On Thu, Dec 17, 2020 at 1:56 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning LL,
>
> > > > - What do you do if the channel state has HTLCs in flight? I don't
> know -- I guess you can just put them onto the settlement tx? That way it's
> possible the payment could still go through. Alternatively you could just
> gift the money to the party offering the recovery settlement.
> > >
> > > Gifting the money is not a good option --- we allow HTLCs to be almost
> as high as the total channel value minus fees and reserve.
> > > Thus all the claimable value could potentially be in an outgoing HTLC.
> > > Worse, if our node is a forwarding node, it would be easy for a third
> party to arrange to have our funds in various HTLCs.
> >
> > Hopefully this recovery system is used by people whose channels are in
> > a HTLC free state 99.9999% of the time (and hopefully hardware
> > failures do not somehow coincide with HTLCs!).
> > As a user, it would be cool to be able to just lock up all my Bitcoin
> > into channels with well-established lightning nodes. That way if fees
> > go ballistic I can still move money around cheaply.
> > One of the main concerns for this pattern of user behaviour is the
> > recovery story I think. The first line of defence for routing nodes
> > (people who are taking their role in LN seriously) has to be redundant
> > data storage.
> > This would be a poor last-resort solution for routing nodes.
>
> A common occurrence is that hardware failure is not detected until when
> the hardware is used, especially when used by casual users.
>
> Consider the sequence of events:
>
> * Part of the storage device fails.
> * Due to being a casual user, the user does not use state-of-the-art
> checksumming filesystems like ZFS and does not monitor disk health by
> S.M.A.R.T.
> * A high-onchain-fee condition exists.
> * The casual user attempts to send out a payment consisting of almost all
> funds in their LN channels via several HTLCs on MPP or other multipath.
> * Because of the activity generated, the filesystem assigns the LN
> database to the failing part.
> * Storage fails with most funds in outgoing HTLCs.
>
> Thus, merely activating the wallet and using HTLCs may result in a
> *detectable* failure of the hardware (which was already failing before,
> just not noticed by the casual user).
>
> On the other hand, we can consider this situation as having a complexity
> penalty.
>
> As someone who has seen a lot of storage devices slowly fail in unique and
> interesting (and data-losing) ways, I am always going to assume that
> storage devices are going to fail at any time, including a few hours after
> installation.
>
> It would be preferable if HTLCs and PTLCs are not gifted.
> On the other hand, it might not be possible (as you note about PTLCs).
>
> >
> > > Using static-key channels (i.e. channel keys are our node keys) allows
> us to recover even the outgoing channel with outgoing HTLC that has been
> forgotten by the outgoing peer.
> >
> > Right. I think this doesn't work with PTLCs though.
>
> Yes, loss of the adaptor signature means we cannot recover in this case.
>
> >
> > > Using static-key channels does have slightly weaker privacy:
> > >
> > > - Published nodes reveal all their channels with other published
> nodes on the blockchain.
> > > - While it is true that published nodes already reveal their
> channels with published nodes, they are currently only revealed on the LN
> gossip network, which is not archived; historical channels that are now
> closed are not informed to current surveillors.
> > > - On the other hand, all it takes is one "LN wayback
> machine" to record all LN gossip, which are self-attesting and include a
> signature from the node.
> > > - Unpublished nodes risk revealing their channels with published
> nodes via the blockchain.
> > > - Invoices created by unpublished nodes currently reveal their
> public key.
> > > Payers can then uncover all the channels of that node.
> > >
> >
> > I don't think so? You need to know the private key of the node to
> > discover its channels! The points actually used in the channels would
> > be randomized with shared secret from Diffie-Hellman so are unlinkable
> > to the public keys of the two nodes under decisional Diffie-Hellman
> > assumption.
>
> Right, that would work.
>
> How about just using a multiplicative tweak of your own privkey and the
> pubkey of the other node (i.e. just use the "raw" ECDH point), that would
> work as 2-of-2 in 2p-ECDSA, and I believe (but do not know) should also be
> signable using MuSig/MuSig2 under taproot?
>
>
> >
> > There is more minor but still real concern of "deniability" of
> > unpublished closed channels if a large node operator later becomes
> > corrupted or coerced by a malicious actor. Since the node operator
> > still knows their secret key (obviously) they can still do a scan
> > (same as you would do in recovery) on the whole chain and find any
> > past channels they had with any nodes.
>
> "Peer selling private information" is always going to be an issue with
> unpublished channels, and this seems to be an inherent issue with that
> model.
>
> Note that due to the existence of proof-of-discrete-log-equivalence, a
> node operator can *prove* to someone buying private information that a
> particular outpoint onchain is actually an unpublished channel.
> If I have privkey `z` and you have pubkey `L`, I can show `z * G` (my node
> pubkey), `L` (your "unpublished" (ha, ha) node pubkey), and `z * L` (our
> ECDH secret), plus a proof-of-discrete-log-equivalence that the `z` in `z *
> G` is the same `z` in `z * L`, in order to convice them of the ECDH secret.
> I suspect part of the proof-of-discrete-log-equivalance can be gated as
> well by a ZKCP on payment point+scalar the proof is provided only on
> payment.
> The selling node operator does not even need to reveal `z`.
>
> As the ECDH secret is what tweaks the channel keys, that is enough to
> convince any surveilling buyer.
> Further, `z` is not revealed, and channel funds cannot be stolen by just
> knowledge of the ECDH secret, thus protecting the interests of the selling
> forwarding node.
>
> Now of course, I could just be making up `L` (i.e. LL could be a
> sockpuppet of mine).
> However, between these two choices:
>
> * I lock up a set number of millisatoshi in a Z + L channel where L is a
> sockpuppet, and sell this fake information to surveillors.
> * I lock up a set number of millisatoshi in a Z + L channel where L is a
> genuine user node that thinks unpublished channels are private, and sell
> this genuine information to surveillors.
>
> Which is more lucrative for me?
> The latter case would be more lucrative for me, as I not only earn from
> selling your data to surveillors, I also earn routing fees.
> The former case can only earn me selling fake data to surveillors, with no
> opportunity to earn forwarding fees.
>
> > A mitigation of this problem
> > would be for users who want unpublished channels to turn the
> > use-node-key-as-channel-key feature off for their keys in the channel
> > so they would still be able to do a backup-free channel scan but the
> > well-established node would lose the ability to do so.
>
> If the user has all channels unpublished, it is not (normally) gossiped.
> So the well-established node would not have the ability to recover *all*
> channels by backup-free scans of published nodes in the first place, only
> those that are to published nodes.
>
> Or do you refer to something else?
>
> It might be easier for the "client" here to make up different node IDs for
> each "server" it connects to, by e.g. hashing its base privkey with the
> server pubkey and using the hash as the privkey for its fake node ID with
> that server.
>
>
> > This means that
> > after the channel is closed there would be no way for the large node
> > to find the channel again assuming they honestly delete the data.
>
> If forwarding nodes are expected to have storage redundancy, deletion of
> data could be difficult as well --- there may be lots of replicas of that
> data in various places (including obsolete replicas that the node operator
> might not particularly care about, being obsolete), and deletion might not
> catch them all.
> "Honestly delete" seems like a best-effort to me.
>
> On the other hand, if the model is that privacy is to be trusted to your
> peers, then this is no worse than unpublished channels, which has the same
> model.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201218/d47a1446/attachment-0001.html>;
📝 Original message:
On Thu, Dec 17, 2020 at 1:56 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> A common occurrence is that hardware failure is not detected until when
the hardware is used, especially when used by casual users.
>
> Consider the sequence of events:
>
> * Part of the storage device fails.
> * Due to being a casual user, the user does not use state-of-the-art
checksumming filesystems like ZFS and does not monitor disk health by
S.M.A.R.T.
> * A high-onchain-fee condition exists.
> * The casual user attempts to send out a payment consisting of almost all
funds in their LN channels via several HTLCs on MPP or other multipath.
> * Because of the activity generated, the filesystem assigns the LN
database to the failing part.
> * Storage fails with most funds in outgoing HTLCs.
Note that this is fine if the payment goes through. Their counterparty will
have to go on-chain to claim the payment (since your node is down due to
data-loss) and then you claim whatever is left from your seed.
The main risk here is for routing nodes which are hopefully only using this
technique as a very poor last resort.
If you actually manage to get online and try to restore before the on-chain
settlement then just attaching outgoing HTLCs to the mutual close would be
fine -- that way the peer can still claim the money from you if the payment
goes through and you can get the refund if not.
The same could apply to incoming HTLCs as long as you can reproduce your
HTLC pre-image deterministically.
PS good to hear you are a ZFS user too
>
> Thus, merely activating the wallet and using HTLCs may result in a
*detectable* failure of the hardware (which was already failing before,
just not noticed by the casual user).
>
> On the other hand, we can consider this situation as having a complexity
penalty.
>
> As someone who has seen a lot of storage devices slowly fail in unique
and interesting (and data-losing) ways, I am always going to assume that
storage devices are going to fail at any time, including a few hours after
installation.
>
> It would be preferable if HTLCs and PTLCs are not gifted.
Yes I am convinced.
> >
> > > Using static-key channels (i.e. channel keys are our node keys)
allows us to recover even the outgoing channel with outgoing HTLC that has
been forgotten by the outgoing peer.
> >
> > Right. I think this doesn't work with PTLCs though.
>
> Yes, loss of the adaptor signature means we cannot recover in this case.
Let's think about this again. There is no reason why the oblivious mutual
close has to be the only thing the peer sends you upon connection. They can
also send you the necessary signatures for each PTLC output on the mutual
close because you can't do anything with this unless you choose to receive
the mutual close signature. You verify these each time you connect without
data loss so optimistically you should be able to recover both incoming and
outgoing PTLCs
> Right, that would work.
>
> How about just using a multiplicative tweak of your own privkey and the
pubkey of the other node (i.e. just use the "raw" ECDH point), that would
work as 2-of-2 in 2p-ECDSA, and I believe (but do not know) should also be
signable using MuSig/MuSig2 under taproot?
I think multiplicative combination of keys does *not* work for Schnorr
multisignatures.
>
> "Peer selling private information" is always going to be an issue with
unpublished channels, and this seems to be an inherent issue with that
model.
>
> Note that due to the existence of proof-of-discrete-log-equivalence, a
node operator can *prove* to someone buying private information that a
particular outpoint onchain is actually an unpublished channel.
> If I have privkey `z` and you have pubkey `L`, I can show `z * G` (my
node pubkey), `L` (your "unpublished" (ha, ha) node pubkey), and `z * L`
(our ECDH secret), plus a proof-of-discrete-log-equivalence that the `z` in
`z * G` is the same `z` in `z * L`, in order to convice them of the ECDH
secret.
> I suspect part of the proof-of-discrete-log-equivalance can be gated as
well by a ZKCP on payment point+scalar the proof is provided only on
payment.
> The selling node operator does not even need to reveal `z`.
>
> As the ECDH secret is what tweaks the channel keys, that is enough to
convince any surveilling buyer.
> Further, `z` is not revealed, and channel funds cannot be stolen by just
knowledge of the ECDH secret, thus protecting the interests of the selling
forwarding node.
>
> Now of course, I could just be making up `L` (i.e. LL could be a
sockpuppet of mine).
> However, between these two choices:
>
> * I lock up a set number of millisatoshi in a Z + L channel where L is a
sockpuppet, and sell this fake information to surveillors.
> * I lock up a set number of millisatoshi in a Z + L channel where L is a
genuine user node that thinks unpublished channels are private, and sell
this genuine information to surveillors.
>
> Which is more lucrative for me?
> The latter case would be more lucrative for me, as I not only earn from
selling your data to surveillors, I also earn routing fees.
> The former case can only earn me selling fake data to surveillors, with
no opportunity to earn forwarding fees.
Correct and interesting analysis. I agree that you don't want to
accidentally opt in to having your peer have a way to cryptographically
prove you have a channel with them.
Except in the situation where you are already cryptographically proving to
everyone you have a channel with them in the channel announcement.
>
> > A mitigation of this problem
> > would be for users who want unpublished channels to turn the
> > use-node-key-as-channel-key feature off for their keys in the channel
> > so they would still be able to do a backup-free channel scan but the
> > well-established node would lose the ability to do so.
>
> If the user has all channels unpublished, it is not (normally) gossiped.
> So the well-established node would not have the ability to recover *all*
channels by backup-free scans of published nodes in the first place, only
those that are to published nodes.
>
> Or do you refer to something else?
I was thinking about public nodes with un-announced channels.
For completely private/unpublished nodes then I agree with your statement
that there is no hope no matter how you compute the keys to recover
automatically.
>
> It might be easier for the "client" here to make up different node IDs
for each "server" it connects to, by e.g. hashing its base privkey with the
server pubkey and using the hash as the privkey for its fake node ID with
that server.
>
Right. Something like this is what I was suggesting for public nodes who
want to have unpublished channels that they want to be able to channel scan
for but *do not want the other party* to be able to do so (to avoid
concerns you made clear earlier).
I think there's no strong reason to make up a new node id -- it can just be
an option in open_channel like "use this key instead of my node id for
everything in this channel".
Cheers,
LL
On Thu, Dec 17, 2020 at 1:56 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning LL,
>
> > > > - What do you do if the channel state has HTLCs in flight? I don't
> know -- I guess you can just put them onto the settlement tx? That way it's
> possible the payment could still go through. Alternatively you could just
> gift the money to the party offering the recovery settlement.
> > >
> > > Gifting the money is not a good option --- we allow HTLCs to be almost
> as high as the total channel value minus fees and reserve.
> > > Thus all the claimable value could potentially be in an outgoing HTLC.
> > > Worse, if our node is a forwarding node, it would be easy for a third
> party to arrange to have our funds in various HTLCs.
> >
> > Hopefully this recovery system is used by people whose channels are in
> > a HTLC free state 99.9999% of the time (and hopefully hardware
> > failures do not somehow coincide with HTLCs!).
> > As a user, it would be cool to be able to just lock up all my Bitcoin
> > into channels with well-established lightning nodes. That way if fees
> > go ballistic I can still move money around cheaply.
> > One of the main concerns for this pattern of user behaviour is the
> > recovery story I think. The first line of defence for routing nodes
> > (people who are taking their role in LN seriously) has to be redundant
> > data storage.
> > This would be a poor last-resort solution for routing nodes.
>
> A common occurrence is that hardware failure is not detected until when
> the hardware is used, especially when used by casual users.
>
> Consider the sequence of events:
>
> * Part of the storage device fails.
> * Due to being a casual user, the user does not use state-of-the-art
> checksumming filesystems like ZFS and does not monitor disk health by
> S.M.A.R.T.
> * A high-onchain-fee condition exists.
> * The casual user attempts to send out a payment consisting of almost all
> funds in their LN channels via several HTLCs on MPP or other multipath.
> * Because of the activity generated, the filesystem assigns the LN
> database to the failing part.
> * Storage fails with most funds in outgoing HTLCs.
>
> Thus, merely activating the wallet and using HTLCs may result in a
> *detectable* failure of the hardware (which was already failing before,
> just not noticed by the casual user).
>
> On the other hand, we can consider this situation as having a complexity
> penalty.
>
> As someone who has seen a lot of storage devices slowly fail in unique and
> interesting (and data-losing) ways, I am always going to assume that
> storage devices are going to fail at any time, including a few hours after
> installation.
>
> It would be preferable if HTLCs and PTLCs are not gifted.
> On the other hand, it might not be possible (as you note about PTLCs).
>
> >
> > > Using static-key channels (i.e. channel keys are our node keys) allows
> us to recover even the outgoing channel with outgoing HTLC that has been
> forgotten by the outgoing peer.
> >
> > Right. I think this doesn't work with PTLCs though.
>
> Yes, loss of the adaptor signature means we cannot recover in this case.
>
> >
> > > Using static-key channels does have slightly weaker privacy:
> > >
> > > - Published nodes reveal all their channels with other published
> nodes on the blockchain.
> > > - While it is true that published nodes already reveal their
> channels with published nodes, they are currently only revealed on the LN
> gossip network, which is not archived; historical channels that are now
> closed are not informed to current surveillors.
> > > - On the other hand, all it takes is one "LN wayback
> machine" to record all LN gossip, which are self-attesting and include a
> signature from the node.
> > > - Unpublished nodes risk revealing their channels with published
> nodes via the blockchain.
> > > - Invoices created by unpublished nodes currently reveal their
> public key.
> > > Payers can then uncover all the channels of that node.
> > >
> >
> > I don't think so? You need to know the private key of the node to
> > discover its channels! The points actually used in the channels would
> > be randomized with shared secret from Diffie-Hellman so are unlinkable
> > to the public keys of the two nodes under decisional Diffie-Hellman
> > assumption.
>
> Right, that would work.
>
> How about just using a multiplicative tweak of your own privkey and the
> pubkey of the other node (i.e. just use the "raw" ECDH point), that would
> work as 2-of-2 in 2p-ECDSA, and I believe (but do not know) should also be
> signable using MuSig/MuSig2 under taproot?
>
>
> >
> > There is more minor but still real concern of "deniability" of
> > unpublished closed channels if a large node operator later becomes
> > corrupted or coerced by a malicious actor. Since the node operator
> > still knows their secret key (obviously) they can still do a scan
> > (same as you would do in recovery) on the whole chain and find any
> > past channels they had with any nodes.
>
> "Peer selling private information" is always going to be an issue with
> unpublished channels, and this seems to be an inherent issue with that
> model.
>
> Note that due to the existence of proof-of-discrete-log-equivalence, a
> node operator can *prove* to someone buying private information that a
> particular outpoint onchain is actually an unpublished channel.
> If I have privkey `z` and you have pubkey `L`, I can show `z * G` (my node
> pubkey), `L` (your "unpublished" (ha, ha) node pubkey), and `z * L` (our
> ECDH secret), plus a proof-of-discrete-log-equivalence that the `z` in `z *
> G` is the same `z` in `z * L`, in order to convice them of the ECDH secret.
> I suspect part of the proof-of-discrete-log-equivalance can be gated as
> well by a ZKCP on payment point+scalar the proof is provided only on
> payment.
> The selling node operator does not even need to reveal `z`.
>
> As the ECDH secret is what tweaks the channel keys, that is enough to
> convince any surveilling buyer.
> Further, `z` is not revealed, and channel funds cannot be stolen by just
> knowledge of the ECDH secret, thus protecting the interests of the selling
> forwarding node.
>
> Now of course, I could just be making up `L` (i.e. LL could be a
> sockpuppet of mine).
> However, between these two choices:
>
> * I lock up a set number of millisatoshi in a Z + L channel where L is a
> sockpuppet, and sell this fake information to surveillors.
> * I lock up a set number of millisatoshi in a Z + L channel where L is a
> genuine user node that thinks unpublished channels are private, and sell
> this genuine information to surveillors.
>
> Which is more lucrative for me?
> The latter case would be more lucrative for me, as I not only earn from
> selling your data to surveillors, I also earn routing fees.
> The former case can only earn me selling fake data to surveillors, with no
> opportunity to earn forwarding fees.
>
> > A mitigation of this problem
> > would be for users who want unpublished channels to turn the
> > use-node-key-as-channel-key feature off for their keys in the channel
> > so they would still be able to do a backup-free channel scan but the
> > well-established node would lose the ability to do so.
>
> If the user has all channels unpublished, it is not (normally) gossiped.
> So the well-established node would not have the ability to recover *all*
> channels by backup-free scans of published nodes in the first place, only
> those that are to published nodes.
>
> Or do you refer to something else?
>
> It might be easier for the "client" here to make up different node IDs for
> each "server" it connects to, by e.g. hashing its base privkey with the
> server pubkey and using the hash as the privkey for its fake node ID with
> that server.
>
>
> > This means that
> > after the channel is closed there would be no way for the large node
> > to find the channel again assuming they honestly delete the data.
>
> If forwarding nodes are expected to have storage redundancy, deletion of
> data could be difficult as well --- there may be lots of replicas of that
> data in various places (including obsolete replicas that the node operator
> might not particularly care about, being obsolete), and deletion might not
> catch them all.
> "Honestly delete" seems like a best-effort to me.
>
> On the other hand, if the model is that privacy is to be trusted to your
> peers, then this is no worse than unpublished channels, which has the same
> model.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201218/d47a1446/attachment-0001.html>;