Good morning LL,

> Hey Z,
>
> Thanks for your analysis. I agree with your conclusion. I think the most 
> practical approach is the "ask first" 3 round protocol.
>
> Another option is to have `remote_penaltyclaimpubkey` owned by the node 
> instead of the hardware device.
> This allows funds to accrue in the fast forward state which can be swept into 
> the commit tx at the merchants discretion.
> If a fast forward state needs to be asserted on-chain it can then be done 
> automatically without the hardware device.
> Of course, the funds in the FF state are more vulnerable than the main 
> channel balance during that time because their keys are not in a secure 
> device but this seems ok.
> The obvious analogy is to having cash in the till (less secure) that you send 
> to your bank (more secure™) at the end of the day or week.


This seems a useful technique.

>
> > We ***need*** privkeys to be periodically online more often than 
> > `to_self_delay` anyway, ***in case of theft attempts***.
> >  So this is not an ***additional*** requirement at least.
>
> This is a really important point. I guess you have to actually do this 
> periodically, only when there is an actual attempt at theft. Quite annoying 
> to UX to require this.

If you mean "***not*** only when there is an actual attempt at theft", yes.

My thought that this would be useful for a "big"-ish merchant that primarily 
accepts payments, to mitigate its key exposure.
It would program a small low-power device such that it almost always has its 
network interface disabled, but periodically (at random times) it will enable 
its network interface and connect out to the node, presenting a proof that it 
holds the privkey.
It would have a firewall so that it cannot receive incoming connection requests 
and can only make outgoing connection requests (and as noted above, most of the 
time the network interface would be disabled outright).

Then the node could wait for this hardware to contact it, and proceed to "roll 
up" any fast-forwarded HTLCs.
This could also be an opportunity for the node to send out funds, for example 
to pay the salaries of employees or dividends to shareholders of the merchant.

Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to