Good morning Joost,
> It could be something like this: > > payment_secret = random > preimage = H(node_secret | payment_secret | payment_amount | > encoded_order_details) > invoice_hash = H(preimage) > > The sender sends an htlc locked to invoice_hash for payment_amount and passes > along payment_secret and encoded_order_details in a custom tlv record. > > When the recipient receives the htlc, they reconstruct the preimage according > to the formula above. At this point, all data is available to do so. When > H(preimage) indeed matches the htlc hash, they can settle the payment knowing > that this is an order that they committed to earlier. Settling could be > implemented as a just-in-time inserted invoice to keep the diff small. > > The preimage is returned to the sender and serves as a proof of payment. Does this actually work? How does the sender know the `invoice_hash` to lock the HTLC(s) to? If the sender does not know the `node_secret` (from its name, I am guessing it is a secret known only by the recipient?) then it cannot compute `invoice_hash`, the `invoice_hash` has to be somehow learned by the sender from the recipient. And that is done in the BOLT12 protocol by having the sender send a message to the recipient and getting a reply back, included in the reply is a unique BOLT11 invoice for a single intended payment. Note that even using point shenanigans and PTLCs seems not to work. If you provide, say, a BIP32 nonhardened point / master pubkey, the sender could select an arbitrary `i` and ask for the scalar / privkey behind it, but that also lets the sender derive the master privete key used in the derivation. Hardening the derivation would prevent master public keys from being used in derivations in the first place. However, we can do "pay for signature" protocols using PTLCs, and rather than requesting for a scalar behind a point as the proof-of-payment, we can instead ask for a signature of a message that attests "this recipient got paid `payment_amount` with `encoded_order_details`" and have a recipient pubkey (not necessarily the node key, it might be best to reduce signing for node keys) as the signing key. So it seems to me that this cannot work with hashes, but *can* work with PTLCs if we use pay-for-signature and the proof-of-payment is a signature rather than a scalar. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
