Good morning Subhra,
> > Can you describe this in more detail? > > Here is our proposal for mitigating reverse-griefing > https://gist.github.com/subhramazumdar/cf7b043a73db136f6a23091d20e51751 > Looking forward to your comments. Just to clarify my understanding, during the preprocessing stage no contracts are established yet? If so, note that the locking phase is not safe to perform from recipient to sender (which is how it seems to be described). * R and S are really the same entity (they can be the same node, the forwarding nodes A B and C would not be aware of this at all, or they could be two very cheaply generated pseudonyms of the same entity). * R and C establish the contract for 7 msat, using 1 msat from C and 6 msat from R: * R shows x such that h = h(x) is true, with R getting 7 msat. * R shows r such that y = h(r) is true, with C getting 1 msat and R getting 6 msat. * After one day, C gets 7 msat. * Similar contracts are established all the way to A. * When A contacts S, S suddenly pretends to be asleep. * R shows x (which it knows, because S and R are cooperating are the same and x is generated by S). * It thus gets 7 msat --- 6 msat originally from R, for a net gain of 1 msat. * A is left holding the bag. Initial contract establishment has to be done from S to R always, not R to S. Multi-stage contracts can be done from R to S (arguably the simple resolution of HTLC chains is "really' the second stage) for after the initial establishment, but initial establishment always has to be from S to R. There may be other issues as well with the overall setup, please wait, I am considering as well what would happen if we correctly establish the contracts from S to R. The onion packet can transfer secret data from S to R as well, there is no need for a separate communication from S to R. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
