pull down to refresh

The wallet would have to share the payment hash with Strike before the payment is made, then the preimage once it is made.*
Ah, this solves the problem with routing nodes pretending to be the wallet since the payment hash is not send to routing nodes during payment as described in the image here: https://docs.lightning.engineering/the-lightning-network/multihop-payments
Right?
reply
Ah, no the payment hash is also the same thing as the preimage hash. They're also used interchangeably a lot. The routers would know the preimage hash as the payment is being routed and if successful, the routers would then know preimage.
However, originally only the sender would know the preimage hash first. So before the payment is made, they could go ahead and claim the potential payment. First to claim would be the sender. Then after payment completes, submit the preimage to finalize the claim. This would prohibit routers (or anyone that isn't the first successful payer) from redeeming.
reply
Ah, haha, I see I missed the next images. There, it shows H is sent to the routing nodes.
However, originally only the sender would know the preimage hash first.
Mhh, I don't see this in the images: Doesn't Dave (the receiver) generate R (the preimage) and H (preimage hash) before any payment is done?
So the receiver could claim the potential payment as the first one by sending H to Strike before sending H to the sender. Strike could respond with some kind of token the receiver can then use together with the preimage after payment to proof he was paid. But since he already has the preimage, he can immediately proof he was paid.
So I am still confused.
Also, the sender should get paid, no?
reply
Yeah sorry by saying "sender would know the preimage hash first" I meant first besides the receiver. You're right in your understanding there. But it's assumed the reciever is strike (on behalf of merchant), so they wouldn't redeem the kickback themselves.
reply
Mhhh, okay. Thanks for responding!
reply