4 ms·

One powerful feature for the "Bitcoin transaction as a packet" approach is that it can be extended to facilitate extra input and output scripts. Basically you

One powerful feature for the "Bitcoin transaction as a packet" approach is that it can be extended to facilitate extra input and output scripts. Basically you can encode not just vanilla HTTP requests but also payment in a single Vapor request. By default you can already build web apps with Vapor by simply using the base protocol. But by structuring everything as Bitcoin transaction, you can for example implement monetized APIs and money programmed routing (Implement routing and authorization based on Bitcoin script payments and/or resolution) More on this here: https://vapor.network/#62solution https://vapor.network/#62solution

duskwuff 6y ago
But what's the upside of specifically using the format of a Bitcoin transaction here, as opposed to (for example) using a signed HTTP message (a la https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/ https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-...)? 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.

duskwuff 6y ago

But what's the upside of specifically using the format of a Bitcoin transaction here, as opposed to (for example) using a signed HTTP message (a la https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/ https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-...)? 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.