Lightning Addresses for EVERYONE on Hive!


I think it's all back to normal.... whatever normal actually is....

Earlier today 2022-05-20:

Coingeck's @coingecko 's API is still not working and I can't restart without it. Following this I will obviously work on adding another price service so I'm better prepared for this kind of thing.... living and learning!

Overnight Coingecko's API started going wrong and so I've got to clean up some stuff, all should be working again soon I hope.

You know that thing on Twitter where people (mostly) in the US can receive BTC Lightning tips direct through Twitter?

Well now literally EVERY ACCOUNT ON HIVE can receive Lightning tips!


If you like my work on bridging Lightning and Hive, please vote for my continuation proposal:

Support Proposal 222 on PeakD
Support Proposal 222 with Hivesigner
Support Proposal 222 on Ecency

You heard it right. Your very own human memorable Lightning Address looks just like this (yes it does look just like an email address):

Just replace brianoflondon with your own Hive account name. Any BTC lightning sent to that address will end up as Hive in your Hive account.

You can also get yourself a QR code like the one I have at the bottom of the page.

This link will give you a QR code: just replace my hive account name with your own.

You can save that image and put it anywhere.

And a special shout out to all Hive Devs: you can add "tip with Lightning" buttons to any Hive UI. You just need to call the api to generate the QR code (you can even cache this, it doesn't change!).


Hive Lightning Address demo

I've sped up the typing part but the rest of this is real speed. The wallet I'm using here is Breez which is a non-custodial wallet (meaning I really do hold the keys). There are custodial wallets which might shave a few seconds off the Lightning sending time.

How it works

Behind the scenes there is quite a lot going on to make this happen.

As I've written extensively before, Lightning is not a blockchain based crypto system. Lightning can only be received by a Lightning Node which is online and working 24/7 and which has "channels" open to the rest of the Lightning Network.

So in order for you to "receive" Lightning on a static address, just as you can receive Hive on your username or BTC on an address you can generate, things get interesting.


What Lightning needed was a way to have a pointer to something on the web which could then generate a Lightning Invoice as a way to receive funds. I kind of built this from scratch myself in order for my system to receive Hive and send Lightning: behind the scenes I don't really just receive Lightning, I generate an invoice which a mobile wallet can pay.

DIY was the way I learned

Having built this all from scratch myself, I then realised I had built most of the components I would need to implement something which has been growing in adoption on the Lightning Side: Lightning Addresses. There's a fancy website to tell you all about this and it gives you dozens of ways to grab a Lightning Address but almost all are custodial.

There is a way to set this up with your own node but it's seriously tedious work (here's a 20 min video for you to plough through.

The Flow

Part 1 flow

The background for what is going on here is in this Github repo: LNURL RFC. I'm specifically making use of LUD-01, LUD-06 and LUD-12

  • LUD-01: Base LNURL encoding and decoding
  • LUD-06: payRequest base spec
  • LUD-12: Comments in payRequest.

Zeus Wallet Lightning Address Payment screen

When a compatible Lightning wallet scans the QR Code I produce or a user types an address like into a compatible wallet they are presented with a screen like this screen from Zeus. There's a visual reminder of the destination (my avatar), space to enter an amount between 1,000 and 100,000 Sats and space for an optional comment.

Part 1 technical

The Lightning Address is encoded in the QR Code as a BECH32 string and actually looks like this:


The lightning: prefix is mostly to help Mobile apps route these strings. On my iPhone, the Breez app grabs these strings automatically if the camera sees a QR code with this encoding. On Android the same thing happens but I believe you have the option to chose which app takes over.

The Lightning app then sends a GET request to the URL encoded in that string which is actually this: (you can click on it, you'll get some JSON).

If you manually type into a Lightning wallet as an address it just reorganizes that to make the same call.

That GET request returns a JSON which looks like something like this:

  "tag": "payRequest",
  "callback": "",
  "minSendable": 1000000,
  "maxSendable": 100000000,
  "metadata": "[[\"text/plain\", \" Lightning to Hive @brianoflondon\"], [\"text/identifier\", \"\"], [\"text/long-desc\", \"Sending Lightning to Hive account: @brianoflondon\"]]",
  "commentAllowed": 1000

However I've actually excluded a big chunk of data from the "metadata" field because an encoded version of the Hive avatar is sent in there as well.

Part 2 flow

The user can now be shown a range for the amount to send and an image to help identify where the payment is going: that's where I use the Hive avatar. The user can then add a comment and hit send, there will be one more confirmation and then the sats will be sent.

Part 2 technical

The wallet app can now call the "callback" address with the parameters set by the user. When that happens my API generates a unique invoice specifically for this payment in the form of another BECH32 encoded string. This is the "regular" Lightning way of making exchanges of value.

Once the Wallet receives that invoice, it pays it.

Part 3 Hive

From here on in the rest of my @v4vapp apparatus takes over. It watches incoming payments to my Lightning node and acts on them based on various metadata in the comment field and embedded in the Invoice itself (which my software generated in part 2 above). I receive the sats and immediately make a conversion to Hive and send the Hive out. That bit is generally quicker than the Lightning side.

And the final result....

You Got Hive!

Support Proposal 222 on PeakD
Support Proposal 222 with Hivesigner
Support Proposal 222 on Ecency

Send Lightning to Me!

3 columns
2 columns
1 column