Good morning CJP,

> This, and the rest of your proposal, sounds like a lot of trouble,
> while it hardly solves anything.
>
> RM can have its node surrounded by other nodes also controlled by
> itself. So it is possible that RM controls all nodes that can possibly
> fulfill the 'G' role, and thereby stop any evidence being generated
> against the RM node. If you then want to build evidence against the G
> nodes, you end up recursively involving every single Lightning node in
> trying to solve your problem. Maybe it is possible, but I'd like not to
> do that. I like to see the exchange function as a higher layer (layer
> 3) on top of the Lightning layer, and have each layer solve its own
> problems in a clean and elegant way. I prefer that nodes that aren't
> involved in exchanging assets don't need to deal with its complexities
> either.

Which is why I later say:

> > Note that since the path from S to RM is selected by RM, though, S must 
> > serve as G, and every node in-between that is honestly not a sockpuppet of 
> > RM should be prepared to shut down their channels immediately in case of 
> > slow response from the next node.

Assuming S is a payee, it has every incentive to follow this protocol.

Of course, now OM needs to know G, and thus knows S, the payee, and now has the 
power to censor payments.
Heavy sigh.

Further, if S is not a payee, but is secretly a sockpuppet of F who is setting 
up an American Call Option, S can simply not forward to RM until much later.
Heavy sigh.

Regards,
ZmnSCPxj
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to