110 sats \ 8 replies \ @andy 23 Aug 2023 \ on: Lightning-over-Wireguard bitcoin
Some questions:
- Could you clarify the purpose of the LSAT?
- What is the definition of "protected endpoint"?
- Why does the "protected endpoint" return a macaroon with the invoice?
- Why do you say "To run on multiple devices without user intervention, the client requires a userspace Wireguard implementation"? Do you mean a userspace tool or a userspace implementation? Seems like a userspace implementation is going to be a lot slower than the kernel based implementation.
- What do you mean by "As attenuation is not needed, macaroons are not necessary."?
Hell yeah Andy
- The LSAT is the 'contract', so to speak. It contains the service details, such as how much time it's good for, what server(s) it's valid at, etc. Upon invoice completion, the client adds the preimage to the token, which effectively signs the contract. I found this to be a preferable approach than having the server listen for invoice completion because it makes the client flexible and the server dumb.
- 'Protected' is just referring to an endpoint that's behind a paywall
- Same as (1). The endpoint returns a 402 with the macaroon which contains the contract details and the invoice whose preimage authorizes the contract
- Yes, the kernel implementation is preferable, but most users won't be running Linux. The userspace implementation allows clients to run on any device.
- Attenuation is a primary feature of macaroons that allows them to be delegated with reduced permission. In this case, the security token is meant to be single-use, so I don't see a reason to attenuate.
reply
- How much data and what kind of structure can be stored in the LSAT? I'm trying to understand the benefit of storing the contract data in there as opposed to JSON. Why is it a problem to listen for invoice completion? What is the benefit of adding the preimage to the LSAT if they are just going to have that inside of the LND node after the invoice is paid? Seems like this locks the service down to LND implementations that do the LSAT stuff. Do any other implementations beside LND do LSAT?
- Okay, because an LSAT is just a macaroon? You're not talking about a macaroon that authorizes the LND grpc?
- I'm still confused why the LSAT is needed if it is not re-used.
reply
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
reply
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.