You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 17, 2021. It is now read-only.
Just brainstorming here, but one way to constrain access to the server (which in turn somewhat reduces DOS risk), is to demand proof that the user controls a key, any key, relevant to the asset. E.g. the issuer can prove they have the key the spend the issuing UTXO, anyone who's ever received the asset can prove they have the key to spend that output (whether or not it's already been spent).
This could be a one-off thing, where the server checks the proof and then returns a token that's valid forever, for subsequent requests.
One obvious potential downside is that this authentication mechanism itself it a bigger DDOS risk than the one it's trying to prevent.
Could also just require Lightning payments :-)
The text was updated successfully, but these errors were encountered:
Just brainstorming here, but one way to constrain access to the server (which in turn somewhat reduces DOS risk), is to demand proof that the user controls a key, any key, relevant to the asset. E.g. the issuer can prove they have the key the spend the issuing UTXO, anyone who's ever received the asset can prove they have the key to spend that output (whether or not it's already been spent).
This could be a one-off thing, where the server checks the proof and then returns a token that's valid forever, for subsequent requests.
One obvious potential downside is that this authentication mechanism itself it a bigger DDOS risk than the one it's trying to prevent.
Could also just require Lightning payments :-)
The text was updated successfully, but these errors were encountered: