pull down to refresh
0 sats \ 3 replies \ @brh28 OP 24 Aug 2023 \ parent \ on: Lightning-over-Wireguard bitcoin
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
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