Posts

Hive is better than Lightning for receiving Value 4 Value in Podcasting 2.0

avatar of @brianoflondon
25
@brianoflondon
·
0 views
·
9 min read

Bitcoin Maxis and Lightning Lovers: your systems have their uses, but combined they are not suitable for widespread adoption by people wishing to receive a continuous stream of very small payments through Podcasting 2.0 TODAY.

You might be working on stuff to fix this problem, but right now you haven't solved the problem.

And if any Bitcoin Maxis would like to comment on this, please leave a comment below.

I'll just highlight where this is going:

Already today Hive is Better for Receiving Podcasting Streaming Sats

I'm still NOT promoting this as much as I could even though it works. Right now if you're a podcaster and you want value for value payments on your podcast the best way is via Hive, and I'm going to make this even easier.

The steps are laid out here: ANYONE can Start Receiving Value 4 Value Streaming Sats for your PODCAST! and when I'm done with my current work allowing super easy swaps from Lightning to Hive (to mirror the Hive to Lightning I already have at lnd.v4v.app) I'll make this process of onboarding podcasters far easier.

Background

Last week, for some reason almost certainly connected to the quiet success of @podping on Hive, a few Bitcoin maximalists were engulfed in a rage of jealousy and anger toward me and Adam Curry over at PodcastIndex. I wrote about this from the Podping point of view here in "Living on the edge!".

But what I didn't do in that post was poke the bear and tell the Lightning guys exactly why their present systems aren't even very good for a very important part of the flagship Value for Value system of streaming sats and sending Boostograms to Podcasters.

They throw around the term "shitcoin" with abandon, I don't care I grew up in the "sticks and stones may break my bones but words can never hurt me" era. This came up on the Podcasting 2.0 Podcast with Adam Curry talking to Roy Sheinfeld of Breez. Adam Curry again had some very kind words toward me for which I'm hugely appreciative and he is definitely starting to understand the utility of Hive.

I propose what they've built in Lightning right now is a "shit-network" until they sort out some fundamental problems and develop some missing tools.

The good news for Lightning

First the good news: for relatively small value wallets on phones and making most payments to common destinations, Lightning works well and they've nailed the UI and onboarding. That's very admirable and I'm glad. In fact I'm happy to be integrating it with Hive. There are even some solutions on mobile where you truly own the keys for the crypto on your phone.

Tied up in Channels

However, unless you own and run either a rented Lightning node in the cloud (do you really own a cloud based node?) or a physical device of your own, your Bitcoin sats as Lightning are not fully under your control.

Unlike a public blockchain system (such as Bitcoin or Hive) your actual Lightning (denominated in sats like Bitcoin) truly resides in a contract tied up between your node and a partner node (called a channel). You open up these channels by locking up Bitcoin and then you shuffle sats like beads on an abacus back and forth to your partner. It isn't truly in your own self custody until you close the channel.

If you open enough of these channels, and other people open channels to you, your abacus beads can shuttle back and forth and payments can flow, like waves, through the whole system. If you're trying to run a routing node, if you set your fees just right, other people's payments will route through you and you can take a fee.

Try listening to this hour of discussion on channel routing and you'll get some idea of how complex it is to

The Receiving Problem

You can only receive Lightning when you have a computer connected to the internet and running properly with good connections to the rest of the Lightning network and the correct distribution of capital in those connections. If you have 5,000,000 sats in channels but all the sats are on your side of the channels, you can't receive anything.

Imagine if you could only receive email if both you and the sender were online at the same time and you had anticipated that sender trying to send you a mail and lined up the right pipes to connect you both. This is the Lightning network liquidity issue.

Failed Payments Problem

While talking to Adam, Roy Sheinfeld discussed his latest post (on the VC funded, Web 2.0 exploitative shit-site called Medium): Lightning is a Liquidity Network. That title is being kind, I find it to be a Viscosity Network.

Lightning payments are failing mainly because the network lacks liquidity, and the liquidity we have is not allocated correctly. This inhibits our growth in two ways. First, users get frustrated and slow their own adoption until Lightning becomes at least as good as fiat in completing payments. Second, we node operators lose revenue whenever a payment fails. Routing fees are our income, and allowing payments to fail is leaving money on the table, which deprives us of capital and deprives the network of reinvestment.

Setting aside the issue that it is absolutely impossible to receive payments direct to you if you're not online, making payments from one point to another across the network is not guaranteed. There is a complex dance of finding paths and liquidity across the network which depends on how much you're trying to send and the connectivity of the sending and receiving nodes.

From my point of view, running a node and trying to make payments when people use lnd.v4v.app to turn Hive into Lightning, I am seeing a number of failed payments. Fortunately I can immediately send Hive back at zero cost (free transactions on Hive obviously) but that doesn't help me figure out how to make people happy. It is taking me a significant amount of effort every day to keep this working.

I'm not even trying to run a profitable routing node to make money so I'm much more interested in just getting all transactions to work. I really don't need to make money on routing because of the generosity of the proposal grants I've had from the DHF and because the return on Bitcoin invested is paltry.

Paying for the network

Which all comes down to the incentive problem which I feel we have solved here on Hive. If you can't make money running Lightning Nodes why do people do it? I know running Hive Witness nodes, other infrastructure and dapps on Hive makes money, so I understand why people do it.

If you invest hundreds of Bitcoin in your Lightning node and then manage the pants off it watching every failed routing attempt and opening and closing channels (and paying the full on-chain Bitcoin fees) maybe you can make some money. The Lightning "community" is remarkably tight lipped on how to do this and how much you can make. There are some fledgling tools to automate this but they're incredibly nerdy to set up and you're always one keystroke away from losing 10,000 sats and messing up your channels.

This is the first comment under Roy's Medium post:

I run a node and it's incredibly manual and time-consuming for the low yield that is possible. Having tools that auto-manage the node would help a lot (open channels, rebalance etc.). Maybe there are some out there that do that?

I know exactly what he means.

Fee Tension

For Podcasting 2.0's use for millions of micropayments, Lightning needs to adopt a very low base fee and higher proportional cost (measured in parts per million sats). It's not clear the wider network is going that way. Podcasting can (and largely has) its own network to route very small single digit sat payments, but this is fragile and mostly only possible because MOST of the podcast listening apps and a great majority of the podcaster receiving wallets are centered on a tiny number of bulk wallets (i.e. very centralised).

Roy writes:

The idea that Lightning would always and automatically have lower fees than on-chain transactions is a misconception. Lightning is faster and payments are settled instantly. When deciding which medium to use for which transaction, fees are only one consideration among several. (To take an analogy from fiat, checking accounts, savings accounts, credit cards, and PayPal all coexist because they all have their uses.)

If Lightning fees across the wider network rise to a few cents per transaction, this destroys the idea of streaming 20 sats per minute.

Maintaining and running a semi segregated network for this micro payment system will be architecturally complex and prone to having its liquidity pushed around by the wider network finding cheap routes through it.

Chaos

Years ago, just before I went to University to study Physics I read "Chaos: Making a New Science" by James Gleick. What Lightning has created is a fundamentally chaotic system. 1000's of distributed nodes all able to adjust pricing and routing in real time leads to a non deterministic system where any given payment or transfer can succeed one minute and fail the next.

Will it scale? From a point of view of transactions per second, absolutely. Will it make your transaction work? The only way to know is to try.

Where is the "community"?

There isn't a place for the community to gather. They're all across Twitter, Telegram, Medium, Discord and lord knows where else. They actively avoid decentralised solutions like Hive or LeoFinance (because shitcoins remember?). Then there's the internecine fighting. Like all open source projects, and especially ones where a vast influx of VC money has been dumped on a very few number of participants, jealousy and arguments over direction take hold.

The last couple of years of enforced isolation without conferences to meet up at, Roy Sheinfeld proposes, has led to the current round of bickering. I'm sure that's part of it, but I'd point to huge VC involvement in some projects but not others as a bigger source of friction.

I want Lightning to Work

I want to be able to get on a bus and use an NFT transaction to pay with Lightning. Scrub that, I don't like buses but I could pay for my petrol (gas) perhaps. Lightning has the power to replace any contactless transaction right now but only if the network develops a lot better tools for internally managing itself.

Distributed systems, filled with people with competing and often diametrically opposed, interests is really hard! The more one knows about it, the more one can see that Bitcoin was an absolutely astonishing thing to take off. I put Hive in a similar category for a whole load of different reasons.

One of the complaints thrown at me about Hive for @podping was that it won't be around for the long term. Of course I don't know if it will, but I can say absolutely that Lightning is not a sure thing at this stage either.

Today Hive is Better for Receiving Podcasting streaming sats

I'm still NOT promoting this much even though it's ready. Right now if you're a podcaster and you want value for value payments on your podcast the best way is via Hive, and I'm going to make this even easier.

The steps are laid out here: ANYONE can Start Receiving Value 4 Value Streaming Sats for your PODCAST! and when I'm done with my current work allowing super easy swaps from Lightning to Hive (to mirror the Hive to Lightning I already have at lnd.v4v.app) I'll make this process of onboarding podcasters far easier.

Short version: go to https://podcasterwallet.com/ and claim your podcast by getting an email sent to the address in your podcast's public feed. Then put in the following Public Key:

IMPORTANT UPDATE: THIS IS A NEW NODE ADDRESS - MARCH 2022 - IGNORE THE ONE IN THE SCREEN SHOT, USE THIS ONE STARTING 0266

0266ad2656c7a19a219d37e82b280046660f4d7f3ae0c00b64a1629de4ea567668

And add the customKey of 818818 and the customValue should be your Hive name.

Then tell your audience to get a better podcasting app from http://newpodcastingapps.com/ and steam you some sats which will magically show up as HBD. Boostagrams will come in with message.

Thank You

I end as always by expressing gratitude for the ongoing DHF funding which powers all of this and without which I'd be going a heck of a lot slower!


Support Proposal 201 on PeakD Support Proposal 201 with Hivesigner Support Proposal 201 on Ecency