The inventor of Hashcash and Ceo of Blockstream talks to Atlas21 about how Greenlight can simplify self-custody on the Lightning Network. BitVM is “an interesting way in which you can verify some basic things with the Bitcoin script.”
In recent months so much has been said about the Lightning Network. The difficulty of using Lightning in a non-custodial way and the prospects for network scalability have been the focus of debate. The first problem is being tried to be answered by Blockstream, among others, with a service called Greenlight.
To talk about this and more, Atlas21 turned to the company’s CEO and creator of Hashcash, Adam Back.
How does Greenlight work?
Greenlight is a lighter way for applications with integrated Lightning wallets to interact with the Lightning Network. It’s non-custodial – so you have the keys and you sign in the wallet or in the integrated wallet inside the app – but the network states (like the nodes, the gossip states, etc.) is all managed by a hosted node, and Blockstream provides a service to operate them for you.
What the client does is making a remote request to pay a particular lightning invoice, it sends it to the server, and the server gives instructions on how to sign this block of data. It also provides extra data, which is enough for the client to verify that what they are signing is safe: that it will pay the right person only. It’s a bit like the interaction between a hardware wallet and the network. Hardware wallets receive informations, they verify some specific things enough to be safe and then they sign, and the network enforces the rest.
The main tradeoff is that you lose a bit of privacy because you are revealing to the network where you’re intending to pay. One advantage is that there’s less network traffic. If you’re offline for days or weeks and you come back online, you can normally transact. While normally, if you bring other lightning wallets online they sync the full node, the gossip network, they have a less up-to-date view of which Lightning nodes in the network are reliable – because Lightning nodes are doing some kind of probing to see what’s reliable and what’s not. In Greenlight that’s done by the server, so it’s always up-to-date. Greenlight also helps you with the backups, because it has some kind of redundant backup in the cloud.
Does Greenlight offer the possibility to migrate from it and autonomously manage your own node?
Yes, Greenlight helps you start with the Lightning Network in a non-custodial, trustless, but still assisted way, but you can also migrate to a direct full node. You can migrate your states and history, Greenlight helps you upgrade to your physical node.
It also has the capability to use LSP (Lightning Service Provider) services, we work with Breez for example. The Breeze wallet is now using Greenlight and Breeze’s LSP. We’ve also added Greenlight to the Green wallet in closed beta, which is also using Breeze’s LSP. The Green system is also for developers to help them integrate embedded Lightning wallets into, say, a Nostr application or a game, where embedding a full Lightning wallet is a bit heavy for an embedded wallet.
Do you think that this kind of model, Greenlight, or maybe future competing services, along with LSPs, might be the ultimate solution for Layer 2 non-custodial services? Or do other solutions have to be thought about in order to make the non-custodial use of the Layer 2 popular?
I think it makes it a lot easier because doing a custodial Lightning wallet is easy on the client side, as it doesn’t have any keys or state, so it’s really just API calls. This is a bit in between. You still have the keys, you still have to sign things, and verify things, but there’s much less network interaction, much less client state. So, it’s really a much easier thing for an application or a wallet to use.
If you look at the other Lightning wallets out there, you have some custodial ones like Wallet of Satoshi. And then you have the so-called full-node-wallets like Phoenix, which, if I understand correctly, is actually syncing a pruned Bitcoin full node, receiving the gossip information, doing the routing calculation all on the mobile. You have LDK and BDK, so the Block/Square toolkit, and that is intended to help application developers build a wallet that functions somewhat like Phoenix: so it’s the full node from BDK and the LDK part is going to consume the gossip data, do the network interaction. So, as I said before, it’s a bit like the way a hardware wallet interacts with the main chain. It doesn’t receive all the data, it’s not a full node, but nevertheless, it can be secure and know that it won’t be stolen from.With a hardware wallet you have the same problem: the index server operated by Ledger or Trezor learns who you’re trying to pay, because their node sends the transaction typically.
This year we had a lot of new proposals, such as ARK, PRIME and recently BitVM, which Federico Tenga explained here on Atlas21. Do you have an opinion on BitVM?
It’s fairly new, people are still trying to understand the limits, including the proposals about how far that outlined design can be stretched. For the moment, it seems like it’s doing something different compared to other proof systems. The proposal is by the same people who did ZeroSync, which is a way to download a UTXO snapshot up to an assumed valid height and then receive a big Zero-knowledge proof. You verify it, and the verification tells you that all the transactions from the genesis, up to this hash and block height, are valid formatted Bitcoin transactions, without verifying the signatures.
It’s a kind of proactive proof, but with BitVM it’s simplified. The prover puts some funds in escrow, and a verifier can engage in an interactive protocol, like a game of chess or some application game – where they’re betting on the outcome or doing some commercial activity – and they’re exchanging Zero-Knowledge Proofs about the state of the game. to prove that the move was valid, for example. When the game is concluded – like with Lightning, where they can do a collaborative close – they can both just sign. But if there’s a dispute – where the prover says “I won the game” and the verifier feels cheated – the verifier should have enough information to disprove. And it turns out that the disproof is a lot more compact than the proof. The idea here is that if the prover makes a claim that’s false, he’ll be forced to reveal inconsistent things which should be out of proof. It’s an interesting way where you can have today’s Bitcoin script verify some basic things where it’d be far too expensive to verify a whole proof.
The title of the white paper is quite ambitious: ‘Compute Anything on Bitcoin’. Do you think that this kind of function may take some of the altcoin functions into Bitcoin in the future?
Well, so far it’s not directly proving anything. You’re proving it offline, but you’re escrowing some funds so that you can get compensated if a false claim is made. The initial proposal is actually a game between two parties, kind of like a lightning channel. There’s escrowed funds, time locks, and if somebody walks away, you can get the funds back. At the moment, it’s a two-party protocol.
The question of general applicability, like: “Can you use it for everything?” is whether you can go beyond two parties. One possibility mentioned by Robin Linus is having it between the prover and dozens or ‘n’ verifiers such that if any one verifier can disprove it, then you know it’s not correct. You can make the verification open to more people. Of course that adds some risk, which is that one of the verifiers falsely agrees the channel close correctly and takes the money through collusion. It’s not a free lunch and the real open question is whether you can have it be between a prover with escrowed funds and everybody, and rely on miners to claim the fraud proof. That’s a more powerful possibility but it has some miner front run risks, and open questions. That’s where it gets more ambitious.
