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