rich1.0Lloyd Fournier [ARCHIVE] (npub1kh…y05yp)https://yabu.me/npub1khlhcuz0jrjwa0ayznq2q9agg4zvxfvx5x7jljrvwnpfzngrcf0q7y05ypnjumphttps://yabu.me📅 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