At the end of the day of the Baltic Honeybadger 2022 conference, Jack Mallers, CEO of Strike, virtually took the stage and proposed an interesting model to create a sustainable model of paying the devs of open source wallets. Open-source projects are notoriously hard to fund, often relying only on donations of some form, or creating paid tier, but it sounds like Mallers is cooking a solution - video recording (explanation starting at 7:46:20).

With the explanation being somewhat cryptic, here's the decyphered version:

What?

Strike will pay any open-source wallet devs every time their wallet is used to make a payment to Strike enabled terminals.

Why?

This is the most interesting question and Mallers build up the arguments to this point throughout his talk.

Strike wants to incentivise devs to bring users to Strike enabled sellers.

Let's break the argument down:

  • Strike wants more people to use its terminals.
  • Sellers want more people to come in, plus sellers want to pay less fees on money stuff.
  • Sellers pay Strike to get the terminals & services - because it's cheaper in comparison with VISA/Mastercard networks.
  • Strike wants to incentivise open-source wallet devs and the whole community to bring more customers to it's point of sale terminals.
  • And therefore: Strike pays open source wallet devs.

It turns out, according to Mallers, the same situation is happening in the current banking system. Visa and Mastercard pay the bank (like Chase) on each transaction to bring in the customers to the merchants. That's where a big part of the ~3% card payment margin goes. To get more detail watch the video of Jack explaining the incentives.

How?

Mallers mentioned a solution where wallet can share the payment pre-image with Strike servers, Strike servers confirm that that was indeed payment they just received on one of the terminals and then the Strike server will immediately pay out some % sats to the wallet dev.

This was only painted in broad strokes, so we will have to wait for the actual solution. As you can imagine there are multiple ways to solve this technically and we should pay attention aspecially to the privacy aspects of the solution.

Final thoughts

The model that Jack Mallers hinted at actually provides incentives structure that's aligned to fund the open-source wallet projects. It's in the interest of Strike to do so. Strike will earn more money if they do. The best open-source wallets will earn the most money too. Strike wins, developer wins, Bitcoin wins.

The question this brings is - what about other projects? Do those have the same incentives? Does Stacker News have incentive to share some sats with wallet devs that encourage users to use Stacker News?

OFC we will have to wait and see.

nout out

wallet can share the payment pre-image with Strike servers, Strike servers confirm that that was indeed payment they just received on one of the terminals and then the Strike server will immediately pay out some % sats to the wallet dev.

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.*

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?

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?

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.

Mhhh, okay. Thanks for responding!

Great analysis! Is there some other solution they could use instead of the payment hash and preimage?

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

Love this.

Even if every single merchant in the world suddenly accepted lightning payments, there will still need to be either a FAR superior experience for people to pay using bitcoin, or incentives for the consumer to trade in their plastic cards for a lightning wallet.

I can see the wallets themselves giving 'satsback', at a variable rate, when customers use their wallet.

This is one reason why we've built Oshi. It's very exciting how the wallets themselves will be getting a kickback from Strike (and inevitably others), in addition to getting a kickback from Oshi when an Oshi user finds a deal and makes the purchase using that wallet's (or anyone else's for that matter) referral code.

So destroying the best property of Lightning (sender privacy) in exchange for some sats? ...

There are ways to do this in a way that respects privacy (Strike servers really need to just compare hashes of the secret material, they don't even need the secret material). But it's a big question whether the actual implementation will do that. If not, it will suck.

Good idea. I like it.