Topic: Integrating Bitcoin payments directly into network protocols (Read 197 times)

Actually closely related; having to pay to send an email was one of the first ideas that came up when the discourse started about state channel networks on top of Bitcoin. What you describe does sound like it would require some way of Lightning integration into SMTP or SMTP on top of Lightning. We shall be careful not to craft a solution for which no problem exists, though. Because that's how you start a project that is deemed from the start..

You can definitely build another layer on top of L2 (Lightning), which is the idea behind the RGB protocol which was recently 'reimplemented' in a way by the company Lightning Labs. It's all still early and I'm not sure what you can do with it as of today, but it's the closest we have to what you described there.

A pretty high level overview about RGB: https://github.com/LNP-BP/presentations/blob/master/Presentation%20slides/RGB%20%26%20Spectrum%20explanation%20for%20business.pdf

I don't think this will be happening, but maybe 'email over LN' through RGB smart contracts or so could work.

Yes, makes sense. Would be an interesting experiment, but not compatible with current internet architecture. Though I suppose Internet routing could be augmented with lightning channel information, meaning links with a parallel lightning channel could take advantage of that fact, and those without such a channel, would not---but that's way above my pay grade.

I actually think SMTP postage over Lightning would be worth trying. Imagine getting paid to read (or at least receive) marketing emails! Sorting emails by postage would be an alternative to all the machine learning spam filtering. It would also reward email users for the cost to their attention, and provide a natural funding mechanism for mail servers.

The main difficulty would seem to be establishing enough of a network effect that it could get traction. If receiving mailservers could tap into lightning and get paid to receive emails they're already receiving---that could be an enticement to participate.

The issue with this idea is that it stems from an oversimplification in basic explanations of the Bitcoin and Lightning networks. You could add a signed transaction or a channel state commitment in a low-layer protocol, but it won't be possible to 'combine' it the way you think.
I ignore Bitcoin on-chain payments in this context, because you'd need to wait for a few minutes to at least get one confirmation; by then, the HTTP request (or TCP connection, whatever protocol you like to integrate with) will already have timed out.

Lightning payments aren't 'routed' like IP packets; they're actually sequences of channel state updates in a series of channels that connects a sender to a receiver. Therefore, you can't integrate the 'routing of payments' into the 'traffic delivering the protocol itself', unless all network devices that pass along the 'low-level protocol traffic' have Lightning channels between each other.

Hence, what you propose is not possible, and I'm not aware of any work trying to make it possible, by forcing network devices to own Bitcoin and open a channel to each other network device they're connected to. Does this make sense?

Now that I think about it, there wouldn't even be a practical (and portable) way to pass the transaction info of such a payment to a JSONRPC (or some other kind of protocol) service. Because these kinds of protocols are made by standards bodies, and for something like this request I don't see themextending their standards for that.

I actually do not believe that there has been any progress made in this area in particular. I am also against the conventional solution of creating a web service to handle payment requests since such services will inevitably become centralized, and then you have the second issue of how to get people to use the web service in addition to using Bitcoin technology.
So, it seems that the most practical way to handle this situation is using, as you said, the Lightning Network.
A few months ago I was contemplating the feasibility of creating a smart contract in a similar form to the HLTC kinds. It would be for emulating "subscriptions" that you can make with CCs and Paypal and it would arrange for a certain amount of BTC to be sent to a particular address every X days for a period of time or until some party receives an "unlocked" contract that was previously locked (how LN contracts are broken, if my memory serves me right). I think it's possible to at least make a design for this.
The advantage of such a service would mean that its adoption is synonymous with LN adoption, so no need to advertise a separate 3rd party service.

The ability to attach payments to IP packets, or web API calls, would be a great improvement over the status quo. This would be a strong spam prevention measure, and allow prioritization of higher-value traffic. It would also allow direct monetization of APIs without complex user management and accounting.

I keep trying to envision how this would be implemented in practice. Waiting for a new Bitcoin block is obviously prohibitively slow. The Lightning Network comes to mind as an alternative. However, separately routing payments over the Lightning Network, in parallel to operation of an IP network or web API stack, is inefficient---why establish a route in the Lightning network when a route already exists in the form of the Internet itself?

Instead, I would like the ability to combine the routing of payments, with the traffic delivering the protocol itself.

A concrete example would be an extension of SMTP that allows a Bitcoin-based postage to be attached to every email sent.

A route already exists between the payer and the payee, or else the SMTP request could not be initiated.

Ideally, the SMTP server could indicate that postage is required, and give an address (a Lightning address?) to which payment should be addressed. While it is possible to separately make the payment over lightning or (I suppose) directly on the blockchain, it would be much more efficient if the payment could be encoded directly within the SMTP session currently running.

Moreover, integration of such payments into lower-level protocols such as IP itself would be infeasible if separate Lightning or base layer payments are required---in such a case, direct integration with the protocol seems to be essentially mandatory.

Has any work been done toward making such things possible?