Latest nanopayment News

Wait what? OK, let’s start with some differentiators because those of us who are paying attention might be asking if this is just a sneaky way to start talking about micro-payments or micro-transactions again. Is a Bitcoin nano-service the Pontiac Firebird to the micro-transaction’s Chevy Camaro? No. But it is kind of like a side-car connected to a motorcycle! But we will get there in a moment. The crash course on micropayments: Satoshi penned the Bitcoin white paper in 2008 to solve a few problems. He noted in the introduction, “The cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions...” before going on to explain some of the conceptual micropayment abilities of Bitcoin. In the world of 2008, anything under $5.00 or maybe $1.00 was impractical to transmit over the internet due to the fees inherent in the fiat economy, but Satoshi was kind enough to explain some of the use cases that he envisioned, and he clearly was talking about tiny payments in the penny or sub-cent range. “While I don't think Bitcoin is practical for smaller micropayments right now, it will eventually be as storage and bandwidth costs continue to fall. If Bitcoin catches on on a big scale, it may already be the case by that time. Another way they can become more practical is if I implement client-only mode and the number of network nodes consolidates into a smaller number of professional server farms. Whatever size micropayments you need will eventually be practical. I think in 5 or 10 years, the bandwidth and storage will seem trivial.” -Satoshi Nakamoto, August 05, 2010 “It could get started in a narrow niche like reward points, donation tokens, currency for a game or micropayments for adult sites. Initially it can be used in proof-of-work applications for services that could almost be free but not quite.” -Satoshi Nakamoto, January 16, 2009 Micropayments: covered. So, what’s a nano-service? The sidecar analogy was perfect, unless you aren’t a motorhead, and that’s not fair to expect of my readers—yet. Think of a nano-payment similarly to how you might think of OP_Return data: something going along for the ride. Picture a motorcycle driving from one place to another (in this case, one wallet to another across the bitcoin highway.) The nano-service is like a sidecar on the trip! It cannot do anything without the transaction because it does not have any ability to generate thrust on its own, but when it is connected, it allows the transaction to carry more utility along with it as it makes its way across the ledger. Some practical applications deployed by single satoshi (a one hundred millionth of a single bitcoin ) payments were defined succinctly in the release notes of the “Rails” update: Paying a specific miner a few satoshis to return you a Merkle proof when a transaction is mined (regardless of whether they mine it). Paying a specific miner to watch for double spends and notify you. Payments to a paymail host. Paying a channels server to store and forward your messages while you’re offline (more on that later). Paying for insurance or countersigning by a specialist multisig custodian. One obvious way this can be implemented is with payment channels where a micropayment’s transaction fee would be too high, but opening up a direct channel to an honest node to process single satoshi data-service transactions many times before it is settled can be a great tool. While that might be obvious, some of the less obvious things that could come of this includes things like live-streaming audio, video or something like a price ticker feed that gets settled only when done streaming. I’m sure, a year from now there will be other ideas that none of us would have thought of! What is Rails? The aforementioned nano-services are made possible by the new software update to Bitcoin SV called “Rails” which is named for new efficiencies as BSV becomes a business payments rail. nChain CTO, Steve Shadders, had this to say about the debut of the update: “Bitcoin SV 1.0.5 Rails release is focused on opening up a new frontier of nano-services on Bitcoin. A world of innovation opportunities is enabled simply by eliminating artificial constraints and allowing Bitcoin to be Bitcoin. With scaling improvements to address the expected growth in demand, the Rails release represents the visible results of much of the invisible work done by the Bitcoin SV node team over the last year. And it is just the tip of the iceberg with further game changing enhancements planned for the rest of 2020.” https://twitter.com/shadders333/status/1306259151287443456?s20 While the new nano-services might seem a little ethereal, Steve also likened the step to the opening up of Op_Return back in the “unfuckening era,” and I agree with his thoughts. It wasn’t immediately clear what would come of the new big data opportunities of bigger Op_Return limits, but then new business ideas started trickling in on chain to make use of the new feature over the next couple of months, and today this is a cornerstone of the BSV economy. Over time, I expect to see similar things with these new efficiencies in Rails. Dust in the wind In my opinion, the most important part of the new update is the concept of the consolidation transaction. This is something that has been discussed in bitcoin circles for years, especially as fees began to get out of control on BTC around 2015-16. As fees go up, increasingly large quantities of small amounts of bitcoin get stuck in wallets. Over time, more and more of these “dust” transactions become unusable. This is far less of an issue on BSV with the low fees, but it does still exist. The solution implemented in the update is to allow miners to voluntarily accept low or zero-fee transactions if they reduce the total UTXO set and consolidate dust into more usable sizes. Basically, it’s like taking ten thousand pennies and trading them out for a $100 bill. It all becomes so much more usable to the economy that way, so honest nodes should generally accept the consolidations. There was also a concordant update to the Merchant API to allow for more efficiency between users and their relationship with individual miners, which is not insignificant, but also won’t instantly change the universe either. Much like the other updates, it allows more elegant use of the network, and more efficiency at scale, but of course, we need these tools to be used in order to highlight the wisdom in these upgrades. In summary: new efficiency added to the software, which will unlock various new business opportunities! The mAPI allows more batching, the honest nodes are more able to easily consolidate dust, and absurdly small fees are much easier to purpose toward data-driven entrepreneurialism!