Matt Corallo proposed a little more than a week ago a BIP for the coordination of making Bitcoin payments. Making bitcoin payments has always presented something of a challenge in terms of coordination, both on-chain and off-chain with protocols like Lightning, for different reasons. When it comes to digital systems like email or payment systems like Paypal, Cashapp, etc. people are very used to the concept of a single static identifier. If you want to send John an email, you just email “john@[insert domain].” If you want to send John some money on Cashapp, you just send a payment to @John on Cashapp.

This is the user experience that people are familiar with, and when it comes to entrenched user behavior and expectations with things it is incredibly difficult to push them into a substantial or sharp change in their behavior. If you present them with a tool that requires that, it presents a large degree of friction and more than likely is simply going to disincentivize most people from using that tool.

On-chain payments run into a problem with this expectation, not because of an inability to have a static identifier (a single address), but because of the privacy implications of posting a single on-chain address and having everyone you interact with use that to pay you. It puts your entire payment history and coin ownership in the public view of everyone. If you are only rarely receiving money now and again, i.e. when being paid for work or settling bar tabs with people, it’s not a burden at all to simply open your wallet and generate a fresh address to receive to. If you are frequently receiving money however, specifically in instances where you do not directly solicit the payment, that presents a serious burden.

This is why tools like BTCPay Server were created, in order to lower the barrier to entry for people to spin up the needed infrastructure to automate receiving funds without doing something naive like posting a single address for everyone paying you to reuse. However, this necessitates running a server that is constantly available online. While the project has drastically lowered the bar of understanding required, it is still a high burden for a user who simply wants to be able to passively receive money.

The same holds true for Lightning except worse. An invoice is only good for a single payment. Unlike an on-chain address, which can be reused even though it’s horrible practice, a Lightning invoice cannot be used. Once the invoice has either been paid or expires the Lightning node in question will deny any attempt to pay it. This dynamic led to the creation of the LNURL specification, as well as Lightning Addresses built on top of it. LNURL is a protocol for connecting to an HTTP server through a static IP that can be shared once in order to grab an actual Lightning invoice to pay from the server. Building on top of that, Lightning Addresses are a naming scheme on top of LNURL structured similarly to email addresses: John@[domain of LNURL server].

All of these solutions have downsides. The requirement to run an extra piece of software (an HTTP server) that remains online all the time in addition to your Bitcoin wallet or Lightning node; making a request to the BTCPay/LNURL server leaks the sender’s IP address to the recipient; relying on TLS Certificate Authorities.

Just Use DNS

HTTP server tooling like LNURL when paired with Lightning Address use domains to resolve the connection to the HTTP server. Similarly BTCPay Servers are all configured with domains rather than using raw IP addresses. Matt’s insight is why not just cut out the dependence on HTTP and use the Domain Name System itself?

DNS allows you to associate TXT records with a given domain name, creating small human (or machine) readable records that can be queried from DNS servers. In combination with Domain Name System Security Extensions (DNSSEC) DNS TXT records provide a mechanism that can be used in order to query payment information without the overhead and burden of running an HTTP server, as well as offer a bit more flexibility and openness. DNSSEC provides a number of tools for cryptographically signing DNS entries, including TXT records, with the DNS keys inherent in the hierarchical structure of DNS. This provides a guarantee that the TXT record you are querying is the record signed by and distributed to lower level DNS servers from the local root server/key.

This gets to the real benefit of DNS as a means for fetching payment data: say goodbye to the requirement of having to run an HTTP server. A TXT record can encode an on-chain Bitcoin address (though the BIP specifically recommends AGAINST doing this if you are not capable of regularly rotating new addresses to prevent address reuse), but more importantly it can also contain a BOLT 12 Lightning Offer.

These records can be fetched from any DNS server, your own local one, your ISP, even a public server like Google or Cloudflare. From this basic point, one shortcoming of HTTP based solutions is solved; you are no longer leaking your IP address to the person you are trying to pay. Now, in the case of using your ISP’s DNS or a public server like Google or Cloudflare without a VPN or Tor you are revealing your IP address to them; the BIP clearly encourages support for DNS resolution over a VPN or Tor for specifically this reason.

Combining this proposal with BOLT 12 removes the need for running ancillary software that presents a very real security concern for unsophisticated users, and allows the ownership of a domain alone to give users everything they need to have a mechanism to locate payment information with a simple human readable identifier. BOLT 12 requires no HTTP server, handling the actual invoice delivery over onion routed connections directly through the Lightning Network, and supports Offers, a static identifier that can be used to find an onion route to that Lightning node. The problem is the Offer is encoded as a massive random seeming string like an invoice itself, making it a horrible human readable/usable identifier except through the use of QR codes or copy and pasting.

By storing an Offer in a DNS TXT record, all a user needs in order to make a payment is someone’s domain to type into their wallet so it can fetch the TXT record, fetch the BOLT 12 Offer, and then make the payment. They don’t need to host any server or run any software other than their Lightning node, the DNS system handles everything for them as far as hosting their BOLT 12 Offer someone that users wanting to pay them can find.

Is this a perfectly trustless system? No. Is it much better than HTTP based systems? Absolutely. The problem with issues like this is that there is a certain expectation of UX and behavior that most people have as far as digital systems are supposed to work in their minds. Without replicating that UX, large groups of people will simply use alternatives that do meet that UX expectation. Given that reality, in attempting to fit Bitcoin into the box of those UX expectations, the design goal should be to meet those user needs with the minimal amount of trust interjected, the minimal amount of burden placed on the users, and the minimal potential for loss of privacy in new ways. I think Matt’s BIP checks all of those boxes in comparison with existing solutions. 

Source link

Streaming services, like other industries, grapple with the limitations of the fiat payment system. The burden of fees and the absence of suitable technology for streaming payments have compelled them to adopt similar mitigations as other industries. This translates to charging users on a monthly basis.

With the Lightning Network, we have the technology to stream sats for content. No longer confined to monthly subscriptions, you pay for what you consume in real time. Whether you watch sporadically or binge extensively, streaming payments allow for a more personalized and efficient payment model. This way the creator of the content and the user have a direct connection for each minute the content is broadcasted. With streaming payments now you can say goodbye to subscription payments.

Unveiling A New Era Of Fair Compensation And Accountability In Movie Production

Imagine you’ve created a movie or documentary. Traditionally, you’d charge people for a ticket, essentially asking them to pay upfront for future value, creating a slight disconnect. Now, with streaming payments using sats, consumers can pay as they watch. If your movie sucks, they might only pay for the first 30 minutes. However, you still receive value, and viewers won’t feel overcharged for something they didn’t enjoy. If your movie is great they not only stream sats the whole time but at the end, they leave a tip.

On the receiving side of the movie most people involved in it received a salary for doing their job. As we already know this is not aligning the whole structure in the same direction. Some people do not care at all how good the movie is if they have already been paid and do not receive a bonus further. Some people might care about reputation in the market but very few just want to do the best job. Again, we went through this, and as you are guessing you just do a split payment in the backend where all the people in the credits actually receive sats or even milisatoshis based on their contribution. This was something I did not expect that Bitcoin would disrupt. This way the reputation is directly linked to the payment and a lot more people will fight to have the best movie. You can be someone who contributed to a project and wants to stay anonymous for whatever reason but still receive money – Lightning instant settlement is the way to do it.

These concepts should not be new if you read through the last 3 articles. In addition, people in the Bitcoin space are familiar with the Value for Value (V4V) podcasting and that is very close to what I am describing above. While the technology for podcasting is already in place, it’s surprising how few podcasts leverage this technology to implement split payments effectively. They give that responsibility to some hosting service that decides to take a 5% split for themselves and the other 95% goes to the wallet of the show. Why not do the split the proper way? The hosting service provides value so they should get a percentage but if you are 3 people involved in the production of the podcast you should have that 95% split so it goes to those individuals. There’s no excuse, especially for Bitcoin podcasts, not to make this effort and implement split payments appropriately.

The Dynamic Future Of Pay-as-you-go In Content Consumption

In this example, the pay-as-you-go model holds true for continuous experiences, like streaming. Now, let’s revisit the movie example. If you’re a theater, you are essentially the hosting provider for the movie. The quality of the theater experience can vary; one theater might have uncomfortable chairs, while another boasts luxurious massage chairs. The theater with subpar seating might receive a 3% share of the movie’s streaming sats revenue, while the one with comfortable massage chairs might earn 5% for each sat stream paying for the movie. Furthermore, if a viewer activates the massage function of the chair, additional sats are streamed for each second that the function is on. I do not know the exact payment dynamics between theaters and movie studios but I bet there are prepayments and funds held at multiple points in the fiat payment process. With the adoption of the Lightning Network, theaters no longer have to prepay for movies to be projected on their screens. They can now observe which movies are most popular in real time and adjust their projections accordingly to optimize revenues. This benefits the consumer and optimizes profits for themselves and the creators of the movie.

Now you see the content gets its value stream for the continuous experience and everyone in the film industry will fight to give the best experience for the most amount of time. The better the experience the more sats flow their way. Due to the highly subjective nature of content, where one person might deem a movie subpar, another might label it as their favorite. This subjectivity is why I believe most content streaming will not have a predetermined price. Even movies may adopt the V4V model, similar to what Adam Curry is pioneering in podcasting. For instance, you watch a movie, and during the credits, a prominent QR code appears, allowing you to decide how much you want to send to the creators of the movie. You will listen to a song or a podcast the same way. Whether you predefine a streaming rate per minute or request payment at the end, both options are technically possible. However, the market will ultimately determine which option prevails as the better one.

Also, why not have a bidding competition for any event that has assigned seats? The person who bids the most for a ticket gets to be in the first row of the concert or a sports stadium. This way the subjectivity is left for all the viewers to decide how valuable it really is. This way it ensures a full stadium also because if there is no value in attending the event people are not going to bid for the seats or just pay 1 sat for it.

Revolutionizing Taxi Transactions For Drivers And Passengers Alike

The continuous experience or service for streaming could be anything in the physical realm. I will take a look at how instant settlement could look like in transportation services. One such transportation service is the taxi service. Even though Uber decentralized the taxi companies which is great they did nothing about decentralizing the payment process. Lightning Network fixes that and more.

With a streaming payment option for each meter of movement, taxi drivers no longer need to wait until the end destination to receive their payment. In a world of instant settlement, payment occurs as you go, eliminating the risk for the taxi driver regarding whether the passenger will pay at the end of the journey. While this might not be a groundbreaking improvement, there are several additional benefits to consider.

Why do most taxis operate with cash? Taxi drivers in most places need a POS device for the customers to be able to pay for a better user experience (UX). It may be a better UX but on the other hand, it creates problems for the drivers either way:

1. They have to acquire clunky devices.
2. They must pay payment processing fees, negatively impacting their margins.
3. Operating solely with cash exposes them to the honeypot problem, carrying a substantial amount of money, and making them vulnerable to theft.

With an app tailored for the taxi experience and integrated with the Lightning Network, these issues become irrelevant. There is no need for additional equipment, no payment processing fees for receiving money, and no exposure to visible cash, reducing the risk of being a target for theft. Now you can have a better UX with better security and better margins – an additional benefit is that it will be paid with Bitcoin. Not only that but just like the example with the movie theater chairs drivers will be incentivized to make the travel experience even better. They can offer – to watch a movie, video games like PlayStation, or massage chair. If you choose to use those extra experiences on top of the travel experience you have to increase the sats streaming their way.

An additional benefit for the travel experience of customers arises when multiple passengers in a taxi have different destinations. Traditionally, the taxi meter ticks for the entire journey, and when the first person is dropped off, determining a fair amount for their portion becomes complex. However, with the Lightning Network, it’s conceivable to streamline this process. Imagine a scenario where three passengers enter a taxi, each with distinct destinations. Each person scans a QR code upon entering, linking their streaming sats to the taxi app. The app manages split-receiving, dynamically adjusting the distribution of streaming payments based on how many people are in the taxi. As passengers are dropped off one by one, the app seamlessly adjusts the split-receiving, providing a fair and efficient payment solution for each individual’s share of the journey.

Optimizing City Transportation With Streaming Sats

The proposed model of split-receiving through QR codes and streaming sats can extend beyond taxi services to other modes of transportation, such as buses. The idea is to calculate the average cost per mile (or meter/foot) for providing the transportation service, including factors like fuel, maintenance, and driver salary, and add a margin for profit. Passengers entering the vehicle scan a QR code, and the app dynamically adjusts the streaming payments based on the number of people on board.

For buses, this model allows for real-time adjustment of streaming payments as passengers enter and exit. If there are 30 people on the bus the split is between them. At the next stop, 10 people are dropped off and 5 people get on board – now the sats stream is divided by 25 people. As the number of people on the bus changes at each stop, the streaming sats are proportionally divided among the passengers. This approach can lead to more efficient and flexible city transportation. Late-night buses will be more expensive for the passengers because of the fewer riders, while buses during peak hours may offer a more cost-effective traveling experience as payments are shared among more passengers.

This system encourages transportation optimization around events, such as concerts or sports games, where private buses or minivans wait to fill up before departing. Routes can be dynamically adjusted because you will have a system tracking how many people are in the vehicles at what time and at what location on the map. Importantly, this data remains anonymous, as no KYC information is required for the Lightning Network payments.

The Streamlined Pay-from-a-distance

Now with this streaming money feature, it can be applied differently. Let’s go back to the taxi service for a moment. The pay-from-a-distance feature that is available in the Lightning Network can significantly enhance the experience of ordering a taxi. Instead of the traditional model where drivers wait patiently and charge fixed fees when passengers enter the car, this model introduces streaming sats from the moment the passenger accepts the ride. Here’s how it works:

1. The passenger places an order in the app, specifying the destination. Nothing new here.
2. Drivers see the order and can apply for it, similar to platforms like Uber.
3. Streaming sats start the moment the passenger accepts the driver, and streaming payments commence. This fee will be less than the actual transportation but the user is still paying for the service of the car coming to him and not the other way around.
4. The taxi arrives at the passenger’s door, and the streaming payments continue. There is a fee for waiting at the door per minute.

By shifting the waiting cost to the passenger, there’s a strong incentive for both parties to be prompt, and the system becomes more efficient. Additionally, the passenger’s responsibility to follow the car reduces operational costs related to alerting passengers via message or a call. Any inefficient time management becomes a cost for the passenger. This model aligns incentives for both drivers and passengers, creating a more seamless cost and time-effective taxi experience.

The concept of paying from a distance can be creatively applied to various scenarios, providing convenience and peace of mind. For instance, when it comes to sending your child somewhere with a taxi, traditional concerns about trusting them with money or the driver’s reliability may arise. However, with the ability to stream sats for the ride, you gain real-time visibility on your device, tracking your child’s journey and ensuring they reach the intended destination safely. This pay-from-a-distance feature extends beyond transportation and can be applied to other continuous services. For example, daycare services charge per minute, allowing you to stream payments in real-time, ensuring accurate and fair compensation for the duration your child spends there. Additionally, you can send a present to a friend, such as a massage session, and pay for it in a streaming fashion, covering the cost continuously based on the duration of the service. The flexibility of streaming payments not only offers real-time tracking and control but also opens up new possibilities for various services where charging per minute or duration is relevant. Those services can be paid on the spot or from a distance.

I know that now it looks like we are going backwards from the original point of never paying money for time. The key distinction here is that you may be paying for time past for the service but in that time you get a continuous stream of value (work done) so you are streaming value back to pay for it. In some cases the time spent is actually an accurate measure of the work done.

It’s true that developing apps with such functionalities is technically feasible, and there might be entrepreneurs and developers willing to explore these possibilities. However, a significant challenge arises when considering custodial control over users’ funds. Small startups might find it financially burdensome and complex to operate as custodians, potentially steering away from such responsibilities. This will take not only high responsibility but also a very big financial wall and expertise to obtain the licenses that comply with the ever-changing regulations. On the other hand, large tech companies with substantial resources could afford to take on the role of custodians, presenting both a business opportunity for them and a risk for the users. The move by some tech giants, like X(formerly Twitter), to obtain such licenses can be seen as a strategic measure for self-preservation over their own finances. This is also an opportunity to consolidate control over not only user data but user finances within their platforms.

The Breez SDK offers a powerful solution, empowering developers to create diverse applications without having to worry about payment intricacies. Its non-custodial nature is a key advantage, eliminating the need for licenses. The infrastructure of it is made in such a way that it is peer-to-peer so no one is holding money for someone else. The app developers focus on the experience within the app and just plug in the code. This combination of features gives startups a competitive edge and reverses the advantage held by large tech companies. While they go through the complex process of getting a license the startup can integrate the global payment network (the Lightning Network) in one day. Even if certain tech giants choose to lock users’ funds within their applications, alternative options will continue to be developed, and users will have the freedom to opt-out. Just like people are choosing Bitcoin over fiat.

Now who is ready to give all of us those experiences in their app?

This is a guest post by Ivan Makedonski. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.

Source link