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: Errr please replace 5 ...

📅 Original date posted:2020-12-15
📝 Original message:
Errr please replace 5 with 4 in the previous post. Thanks to devrandom.

LL


On Tue, Dec 15, 2020 at 2:43 PM Lloyd Fournier <lloyd.fourn at gmail.com> wrote:
>
> > 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
Author Public Key
npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05yp