On Mon, Dec 14, 2020 at 04:31:23PM +1100, Lloyd Fournier wrote: > To be clear: The goal is to offer a cooperative settlement transaction up > front to the (possibly) recovering party -- *not a commitment transaction*.
Ah, what BOLT0 calls a "mutual close". That makes a lot more sense and
makes the protocol even cooler than I thought. Thanks for clarifying!
> The idea I'm working with in revocable signature based channels [1] is
> to make the node lose its static secret key if it posts a revoked
> commitment tx. This means they could lose ALL funds from ALL their
> channels with ALL their peers if they ever broadcast a single revoked
> commitment transaction. This would be a very bad thing to happen while
> you're trying to recover funds.
Yikes! A very bad thing indeed. I'll have to re-read about witness
asymmetric channels; I don't think I realized that was a consequence of
using them.
> What is the story with option_static_remotekey? I am interested to know how
> the negotiation of that option has a security issue but I don't see how it
> could.
Whoops, I got myself confused. I meant option_data_loss_protect, which
LND calls "static channel backups". I just git greped the bolts for
"static" and copied the first plausible seeming result. :facepalm:
On Mon, Dec 14, 2020 at 12:08:27AM -0800, Ariel Lorenzo-Luaces wrote:
> I don't think it's so clear that any party refusing to go go first can
> be assumed to have lost data.
Oh, I agree, it's definitely not clear. I just said they could "be
*suspected* of having lost data".
On Mon, Dec 14, 2020 at 12:08:27AM -0800, Ariel Lorenzo-Luaces wrote:
> If the rule is that the party receiving the connection is the one that
> must send the oblivious signatures then a party that has both lost
> data and is receiving a connection can just ignore the connection
> request.
>
> There is plausible denyability because knowingly not answering a
> request can't be distinguished from just having connection issues or
> distinguished from a machine is just turned off.
In many cases, the network does behave differently in different
cases:
$ nmap -p 80 dtrt.org ## online and port available
80/tcp open http
$ nmap -p 80 newmail.dtrt.org ## online but no service listening
80/tcp closed http
$ nmap -p 22 10.0.0.1 ## online but connection refused
22/tcp filtered ssh
$ nmap -p 80 10.0.0.200 ## not online
Note: Host seems down. If it is really up, but blocking our ping probes,
try -Pn
Moreover, there's the case where Bob tries to open a connection with
Mallory, but Mallory immediately turns around and tries to open a
connection with Bob. In that case, Bob's unavailability might look
suspicious (although it could just be NAT or something else innocuous).
However, beyond IP network activity, there's potentially a lot of
evidence a dishonest counterparty can gather about a
recently-reconnected node to evaluate the probability that it suffered a
data loss. Perhaps most persuasive would be seeing what happened to
that node's other channels. Were they all closed? Did the node fail to
promptly broadcast a transaction with preimages trying to claim any
pending HTLCs (which can be especially strong evidence if the dishonest
counterparty was along the routing path for any of those HTLCs and so
knows that the preimage was disclosed).
The reason option_data_loss_protects works in theory is that the only
way attacker Mallory can test her hypothesis that victim Bob lost data
is by Mallory broadcasting an old state that Bob, if he didn't actually
lose data, can use to penalize Mallory in a way that may profit Bob. In
an ideal world, for every victim node that actually lost data there'd be
several honeypot nodes that faked losing data in order to profit from
dishonest counterparties. Unfortunately, I doubt that's the case, for
two reasons:
1. You can only operate a data loss honeypot by causing a channel to
be closed onchain, which is going to waste someone's fees.
2. A dishonest node may only try broadcasting an old state when their
channel balance is low, near the minimum allowed by the channel
reserve. The guidelines for channel reserve amounts were chosen
(I believe) under the assumption that Mallory can be highly
confident that Bob has the latest state, so the reserve is just
the bare amount needed to prevent some annoying griefing. The
reserve is probably not large enough to compensate for the work and
fee-paying costs of operating data loss honeypots.
That said, most nodes seem to be honest and hopefully the nodes playing
with high-value channels are using some sort of live replication, so I
don't think there have been any issues so far.
-Dave
signature.asc
Description: PGP signature
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
