First: Bitcoin wallet addresses are temporary keys, not identities. "Authenticating" against one isn't really appropriate, no more than it'd make sense to authenticate a user as the owner of a specific dollar bill.
Second: even if you wanted that, there's no reason you should need to encapsulate HTTP in a weird wrapper to accommodate it. A variety of schemes already exist for signing HTTP requests within the bounds of HTTP. Most of them even support ECDSA signatures.
> 2. Monetize through Bitcoin payment
Signing a message which isn't a valid Bitcoin transaction with a wallet private key doesn't turn that message into a transaction. Conversely, there's no way to make a Bitcoin transaction conditional on the completion of an off-chain operation.
> 3. Programmable HTTP requests
Do you have any examples of what a realistic use case for this would be? Keep in mind that the signed nature of a request doesn't guarantee that the request is processed in the requested manner.
> 4. Data portability
First: as noted previously, there are already plenty of non-proprietary schemes for signing HTTP requests.
Second: this entire point presumes that making HTTP requests publicly logged and visible is a benefit, which doesn't make any sense.
Addressing the points in your link:
> 1. Decentralized Authentication
First: Bitcoin wallet addresses are temporary keys, not identities. "Authenticating" against one isn't really appropriate, no more than it'd make sense to authenticate a user as the owner of a specific dollar bill.
Second: even if you wanted that, there's no reason you should need to encapsulate HTTP in a weird wrapper to accommodate it. A variety of schemes already exist for signing HTTP requests within the bounds of HTTP. Most of them even support ECDSA signatures.
> 2. Monetize through Bitcoin payment
Signing a message which isn't a valid Bitcoin transaction with a wallet private key doesn't turn that message into a transaction. Conversely, there's no way to make a Bitcoin transaction conditional on the completion of an off-chain operation.
> 3. Programmable HTTP requests
Do you have any examples of what a realistic use case for this would be? Keep in mind that the signed nature of a request doesn't guarantee that the request is processed in the requested manner.
> 4. Data portability
First: as noted previously, there are already plenty of non-proprietary schemes for signing HTTP requests.
Second: this entire point presumes that making HTTP requests publicly logged and visible is a benefit, which doesn't make any sense.