ZmnSCPxj <zmnsc...@protonmail.com> writes: >> Not necessarily. If we have an escape hatch in the scripts that allows >> to spend any output attached to the settlement transaction by n-1 >> participants we could reclaim these into a new open right away. > > This would have to be very very carefully designed. > The entire point of requiring an n-of-n signature is: > > * By using an n-of-n signatory where *you* are a signer, you are completely > immune to Sybil attacks: even if everybody other than *you* in the signatory > set is secretly just one entity, this is no different from doing a 2-of-2 > bog-standard boring sleepy Zzzzzz Poon-Dryja Lightning Network channel. > * Any m-of-n signatory where strictly m < n allows anybody with the ability > to run m nodes to outright steal money from you. > * As processing power is cheap nowadays, there is no m that can be > considered safe. > Your alternative is to fall back on proof-of-work, but that just means > going onchain, so you might as well just do things onchain. > * This is why 2-of-2 channels work so well, it's the minimum useable > construction and any multiparty construction, when Sybilled, devolves to a > 2-of-2 channel. > > So the n-1 participants would have to be very very very carefully limited in > what they can do. > And if the only "right" the n-1 participants can do is to force the nth > participant to claim its funds onchain, then that is implementable with a > transaction doing just that, which is pre-signed by the nth participant and > given to participants 1..n-1.
Just to be clear, I do *not* want to support uncooperative splice-outs. This is due to their need to either pre-sign a splice-out of the party like I explained further down, or it requires encumbering whatever we build on top in order to do a fast-reopen. But I do think there is value in exploring what the options are :-) >> Notice that we are negotiating whether or not to apply generic >> transactions to a shared state. This also means that there is no direct >> relationship between the ownership of an output and the ID signing off >> on a change. >> >> The privacy guarantees are identical to Bitcoin on-chain, with the one >> caveat that we may identify the proposing participant, but we can defend >> against this by mixing as you propose. > > Yes, but if we later combine this with allowing multiilateral kick-out > of a member that is unresponsive (i.e. we splice out the outputs it > has at least partial ownership of, and keep only those that are owned > only by the remaining members), then each member would have to > honestly claim which UTXOs it is interested in keeping after it is > kicked out of the membership set, defeating this point entirely. I > believe this is roughly what you propose in the next point, and > roughly what you would want with the "n-1 participants" earlier. That is indeed the issue I explained further down: > It also adds the complexity of having to identify which participant is > the co-owner of an output, otherwise I can claim ownership of an > unrelated output and force that to move on-chain by including it in my > fallback and then becoming unresponsive (added rounds of communication > can help here, but are cumbersome). Claiming ownership would then involve providing a valid input script (disregarding any timelocks) that could spend the output under some condition. Others would have to verify this proof-of-ownership before accepting the node's self-splice-out before accepting it. >> It may be a bit much added complexity for a small complexity to be >> honest, hopefully this won't be needed too often :-) > > Statement makes no sense, unless you meant to say "It may be a bit > much complexity for a small benefit" or similar? Indeed, that was a weird sentence :-) I did mean that it is a lot of complexity for very little benefit :-) Cheers, Christian _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
