pull down to refresh
1 sat \ 3 replies \ @TonyGiorgio 19 Sep 2022 \ parent \ on: SN Scoop: Strike plans to pay open source wallet devs in a sustainable model meta
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.
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