185 sats \ 8 replies \ @TonyGiorgio 19 Sep 2022 \ on: SN Scoop: Strike plans to pay open source wallet devs in a sustainable model meta
This won't work very well. Any LN node that routes the payment will know the preimage once the payment succeeds. The wallet would have to share it with Strike before the payment is made but regardless any LN node on the network would want to submit any successful payment they routed to Strike in order to redeem their share. I'm sure they could do something to battle the spam like blocking the dev account they are paying out to if there's too many false claims. But there's a privacy concern if this isn't communicated to the wallet user that this is happening without their consent. Is the user sharing all their payment data to the FOSS wallet? Or are they submitting it to Strike themselves and associating IP address information? Also I doubt they will provide this without KYC'ing the wallet dev.
This is also an analytics concern with them trying to aggregate as much proprietary knowledge about the network and who is using what. It's good they are trying something to pay open source wallet devs, but they could just like, pay open source wallet devs.
The wallet would have to share the payment hash with Strike before the payment is made, then the preimage once it is made.*
reply
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
Great analysis! Is there some other solution they could use instead of the payment hash and preimage?
reply
Yeah actually, I think bolt12 has the concept of payer proofs that are more provable in that only the sender can provide this.
Edit: it would also spur the adoption of bolt12 if they were only providing incentives for bolt12 wallets
reply