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.fo...@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 <d...@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 _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
