pull down to refresh
0 sats \ 5 replies \ @brh28 OP 24 Aug 2023 \ parent \ on: Lightning-over-Wireguard bitcoin
An LSAT (aka L402) is simply a macaroon (same type as LND but different context) plus an invoice.
I used LSATs in the prototype implementation because there are already NodeJS libraries (lsat-js + Boltwall) that made it easy to set up. However, as I mention in the article, I think something like Paseto would be more appropriate because macaroons are not necessary. Paseto is more similar to a JWT; it's basically JSON data signed by the server. One of the fields would be the payment hash (hash of preimage). Upon payment, the user provides the preimage which the server can verify locally.
For this use case at least, I prefer putting the logic on the client-side because it puts the user in the driver seat. The user has a cryptographic proof-of-purchase that ties their preimage to the service its expecting. Although an MVP would be limited, it also gives the user the ability to activate tokens when and where they choose.
On the other hand, the server is dumb. All the server needs to do is fetch/generate an invoice and verify the token locally, which makes it much easier for service providers to spin up and down instances. I'm not sure if it's possible but it would be cool to generate invoices without fetching from a remote Lightning Node
With StaticWire (https://github.com/AndySchroder/StaticWire) I plan to use the wireguard pubkeys to sign the JSON data. is Paseto able to let you choose the signature algorithm that you want to use?
Interesting approach about trying to use the preimage to reduce the amount of things the server needs to do. It would be really cool if that could somehow be embedded in the wireguard packets so that you can continuously prove payment.
However, everyone along the payment route knows the preimage, so that seems like an issue. It seems like we need to wait for BOLT12 to get secure proof of payment.
What type of roaming do you expect people to have with these tokens? Also, does your pricing model assume you pay per amount of data transferred, the rate at which data is transferred, or the time the that the endpoint reserves resources for you to ensure data can be transferred at some minimum bandwidth when you are ready to transfer data?
If a server can fetch an invoice, why is it harder for them to also verify payment of the invoice?
reply
JWT gives "algorithm agility" while Paseto is designed to be easy-to-use securely: https://github.com/paseto-standard/paseto-spec#key-differences-between-paseto-and-jwt
Only the client knows the preimage and holds the security token, so no risk of someone stealing a session. Also, PTLCs would further mitigate that risk if my understanding is correct.
For an MVP, I don't plan to build roaming for a single token. If a user changes locations, they would start a new session and buy new tokens. Eventually, might be cool to have longer term tokens, so that a user can initiate a session without making a payment on clearnet
The prototype is time-based. But wireguard tracks data throughput, so a preffered option would be data-use model.
Managing everything on the server requires more central processing. The server has to store the 'contract' details for every open invoice and respond to every settled invoice. How well does this scale? If the server misses an invoice completion, how does it know to re-initiate? By moving state to the client, the server is (almost) stateless, only needing to handle client requests
reply
It looks like PASETO uses the same signature algorithm as wireguard, so the wireguard pubkeys should be usable with it.
How are you saying nobody else knows the preimage? Are you talking about a preimage that is not the preimage for the invoice?
I don't think the server is going to be able to be completely stateless. You will be able to remove some state information from the server, but I don't see how you can remove all of it, especially with some more realistic pricing structures.
reply
Interesting, I hadn't thought about using wireguard keys for signing the token, though I'm not sure what exactly is gained by doing so.
I mean no one else knows the preimage and holds the token: both are required by the server.
You're right, the server has to manage wireguard sessions so it can't be completely stateless, but my goal is to make the server as simple as possible. Both approaches should work, but when considering the trade-offs, I like pushing the logic and control to the client.
reply
The benefit of using the wireguard keys to sign the JSON messages is that you don't need to have another key or key type. You need to secure this communication some way because it has to at least initially start outside of the tunnel, so it's best to keep it simple and common rather than need to trust multiple keys.
reply