rich1.0Anthony Towns [ARCHIVE] (npub17r…x9l2h)https://yabu.me/npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hnjumphttps://yabu.me📅 Original date posted:2021-10-12 📝 Original message: On Mon, Oct 11, 2021 at 05:05:05PM +1100, Lloyd Fournier wrote: > ### Scorched earth punishment > Another thing that I'd like to mention is that using revocable signatures > enables scorched earth punishments [2]. I kind-of think it'd be more interesting to simulate eltoo's behaviour. If Alice's current state has balances (A, B) and P in in-flight payments, and Bob posts an earlier state with (A', B') and P' (so A+B+P = A'+B'+P'), then maybe Alice's justice transaction should pay: A+P + max(0, B'-B)*0.1 to Alice B-f - max(0, B'-B)*0.1 to Bob (where "f" is the justice transaction fees) Idea being that in an ideal world there wouldn't be a hole in your pocket that lets all your coins fall out, but in the event that there is such a hole, it's a *nicer* world if the people who find your coins give them back to you out of the kindness of their heart. > Note that we number each currently inflight transaction by "k", > starting at 0. The same htlc/ptlc may have a different value for k > between different inflight transactions. > Can you expand on why "k" is needed in addition to "n" and "i". k sounds like > the same thing as i to me. "k" is used to distinguish the inflight payments (htlcs/ptlcs), not the inflight state (which is "i"). > Also what does RP/2/k notation imply given the definition of RP you gave above? I defined earlier that if P=musig(A,B) then P/x/y = musig(A/x/y,B/x/y); so RP/2/k = musig(A/2/n/i/2/k,RB2(n,i)/2/k). >  * if the inflight transaction contains a ptlc output, [...] > What about just doing a scriptless PTLC to avoid this (just CSV input of > presigned tx)? The cost is pre-sharing more nonces per PTLC message. Precisely that reason. Means you have to share "k+1" nonce pairs in advance of every inflight tx update. Not a show stopper, just seemed like a headache. (It's already a scriptless-script, this would let you use a key path spend instead of a script path spend) > This does not support option_static_remotekey, but compensates for that > by allowing balances to be recovered with only the channel setup data > even if all revocation data is lost. > This is rather big drawback but is this really the case? Can't "in-flight" > transactions send the balance of the remote party to their unencumbered static > remote key? They could, but there's no guarantee that there is an inflight transaction, or that the other party will post it for you. In those case, you have to be able to redeem your output from the balance tx directly, and if you can do that, might as well have every possible address be derived differently to minimise the amount of information any third parties could glean. Cheers, aj