On Thu, Dec 17, 2020 at 1:56 AM ZmnSCPxj 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
