Why Nostr? What is Njump?
2023-06-09 13:01:44
in reply to

Lloyd Fournier [ARCHIVE] on Nostr: 📅 Original date posted:2020-12-15 📝 Original message: > It seems difficult to ...

📅 Original date posted:2020-12-15
📝 Original message:
> It seems difficult to recommend YOLO commitment transactions becoming
the standard way to recover funds. It could be preferable to the current
system but even that is up for debate I guess.
> I feel like I can recommend oblivious settlements because (i) it's covert
(like YOLO commitments txs unlike current system) and (ii) it's "what you
see is what you get" -- you are guaranteed to recover the funds that you
are presented with once you finally trigger the recovery

Off list Dave correctly pointed out to me that this wasn't a very clear
picture of the situation.
After some thought, I came up with these claims that I think I can make
strongly:

1. Before you reveal that you are doing recovery you are guaranteed to have
a tx in hand that:
i. You can broadcast first
ii. You can choose the fee to be as high as you like
iii. Is not replaceable.
2. If the malicious party is *not* willing to risk broadcasting a revoked
tx then you are guaranteed to recover the face value of the transaction(s)
you have in hand.
3. An honest party is never at risk of broadcasting a revoked commitment tx.
4. You never have to reveal that you were doing a recovery i.e. the channel
can continue (strictly preferable to 1)

Current system has: 3
Oblivious mutual close has: 1,2,3
YOLO commitments has: 1,5

So I think the question of YOLO commitments vs oblivious mutual close is
whether paying the price of losing (2,3) is worth the upgrade from (1) to
(5).
The concern with (1) is that once you broadcast to the network the
obliviously transferred "mutual close" transaction, the malicious party
then has a hint that you have lost data and they can try and broadcast a
favourable revoked transaction.
This should be very hard since in (1) you broadcast first, can choose as
large a fee as you like and the tx does not signal replaceability whereas
the revoked tx *will* signal replaceability.
I'm also personally trying to avoid losing (3) because to keep [1]
applicable.

As a side note: in YOLO commitment transactions you have to recover some
additional metadata from the other party -- in particular the compressed
revocation keys that you *should* know otherwise the channel cannot
continue to operate. So a signature on the compressed revocation keys must
be given to the other party before you lose data and returned to you when
you are given the commitment transaction upon reconnection.
This should be easy enough to do though.

[1]
https://github.com/LLFourn/witness-asymmetric-channel#scorched-earth-punishments

On Tue, Dec 15, 2020 at 12:13 AM David A. Harding <dave at dtrt.org> wrote:

> > 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.
>

It's an optional feature -- see link[1] above where I just added an
explanation of it.
I actually see no reason why you couldn't apply revocable signatures to
transaction asymmetric channels (LN as it is today) you just have to
overhaul the revocation mechanism.

In general I agree with your points that side-channels may be effective
tools to reveal whether a node has had data loss or not.
I think in both YOLO commitments and oblivious mutual close it is easy
enough to simulate data-loss up to a point to try and catch malicious peers
using side channels.
At least you don't have to ask the peer to broadcast a tx to find out!

Cheers,

LL
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20201215/7b1e9210/attachment.html>;
Author Public Key
npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05yp