Good morning Bastien,
> Hey Zman, > > I'm a bit confused because you use a different mechanism than the one > specified in the latest schnorr multi-hop locks proposal that I know of, > which can be found in [1]. It seems to me that my proposal is simply a restatement of the same scheme. > > If we use the construction from [1], it seems straightforward that using > trampoline doesn't have any impact on the protocol: the sender follows > the exact steps of that protocol and sends the left/right locks in the > trampoline onion. I am surprised it needs to send the left and right locks. I would expect that, since the PTLC arrives at the trampoline node and serves as the left lock, the trampoline node would only need to be sent the delta scalar between its left and right locks. My scheme, as stated, allows implementations to internally define a function of the following signature: ```Haskell buildPath :: RandomSource -> GossipMap -> Secp256k1.Point -> Node -> Secp256k1.Scalar -> Path buildPath prng -- :: RandomSource gossipMap -- :: GossipMap finalOrNextTrampolinePaymentPoint -- :: Point finalHopOrNextTrampolineHop -- :: Node deltaScalar -- :: Scalar = undefined ``` The function would use a pathfinding algorithm to generate a raw path (i.e. one that is just a set of nodes to pass through) and then for each hop, generate a new scalar from the given random source. Then the function decorates that path with the generated scalars, takes the sum, and subtracts that sum from its input `deltaScalar`, to generate the first hop scalar that it adds to its input `finalOrNextTrampolinePaymentPoint` (after multiplication by `G`) to get the output PTLC point. It would decorate the last hop with the `deltaScalar`. For a flat payment function, the payment function can just generate its own `deltaScalar` for each attempt (and each part in a multipart attempt) and then pass the paths as-is to the onion encoder. The same `buildPath` can be reused by a trampoline node. The trampoline node would simply pass in the `deltaScalar` it received from the input onion. Similarly, a payment function through trampoline nodes can reuse the same function, as it would simply assign individual deltas to be sent to each trampoline node selected by the pathfinding algorithm. (Or a more basic function can be defined which accepts a set of nodes through which to pass a route, those nodes being either direct-hop nodes or trampoline nodes) Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
