#like ok the idea of the episode is they have this migration route right | Explore Tumblr Posts and Blogs

damonbation · 5 years

Text

Let's Talk BItcoin! #390 Revisiting Lightning (Part 2)

On Todays Episode of Let's Talk Bitcoin...

Stephanie Murphy, Andreas Antonopoulos, and Adam B. Levine sit down for part two of our fresh look at the nascent but rapidly improving Lightning Network.

Excerpted Selections from Episode 390 Curated and Transcribed provided by https://twitter.com/Sesame4Bitcoins

Lightning Network Capacity

Adam B. Levine: Right now in the Lightning Network, you can only make transactions and hold value up to a certain size. Andreas, why is that?

Andreas Antonopolous: It's to discourage people from putting too much money into something that was experimental, and also trying to do payments that are too big for most routes. The limit per payment is 4 million Satoshis (0.04 Bitcoin). The channel capacity maximum is 16.7 million Satoshis. You can create a channel for 16 million Satoshis and you can transmit payments of about 1/4 its total capacity at a time in each direction. That just prevents people from trying to use Lightning today for the types of payments that are probably best kept on-chain.

Adam B. Levine: Do you see the Lightning Network being used for larger transactions like the traditional Bitcoin network?

Andreas Antonopolous: Eventually yes. Eventually there's no reason why you wouldn't have your entire hot wallet in Lightning channels, and the only funds that are not in Lightning channels are cold storage funds. I see it eventually having much bigger transactions - it can span the entire range from tiny to very big.

Lightning Network Development

Adam B. Levine: How do you determine at what rate [channel capacity] should increase and who gets to decide if that should increase?

Andreas Antonopolous: The way lightning collaboration and interoperability happens is through a series of standards called BOLT (Basics of Lightning Technology). These are constantly under negotiation. The first iteration of BOLT standards is what created today's production Lightning Network, and allows three or four different software clients to interoperate very successfully.

Stephanie Murphy: Can we draw any parallels to the way that changes happen [on the Lightning Network], and in Bitcoin [base protocol layer]?

Andreas Antonopolous: This isn't a consensus rule. The difficulty with Bitcoin [base layer] is that everyone has to agree, because if one party doesn't agree, they can no longer maintain synchronization with the network. In Lightning, the scripts are part of the consensus because you need to be able to secure the transactions - everything else is up for negotiation. If some clients don't do big payments and other clients do big payments, it's OK, they can both coexist on the network quite happily. You don't need this rigid lockstep coordination on layer 2 as you do in layer 1. It's one of the reasons why layer 2 can move much faster in terms of innovation, because you don't need everybody to agree on all of the changes.

Next week is the second semi-annual meeting of the various teams that are working on Lightning development, so that they can continue the discussion on developing the BOLT standard and creating new interoperable standards.

All of the things we are talking about: Wumbology, Eltoo, AMP, Sphinx-routing, Rendezvous-routing, etc; all of these were decided and standardized in terms of roadmap in the last semi-annual meeting of the Lightning developers. The next one is next week in Argentina. There's a lot more happening on the mailing list, and there's a lot more things in discussion that we didn't even touch on. We scratched the surface - we talked about the things that were agreed on 6 months ago, that now have names, and are proceeding towards production with specific standards. Next week in their meeting in Argentina, they're probably going to create a whole bunch of new things that we haven't even talked about. Once again this is a space that moves incredibly fast. Lightning is moving at 3 or 4 times the speed of Bitcoin's base blockchain development, because innovation can move a lot faster at higher layers. You don't need as much coordination and conservatism because you get the security from the base layer. This is really interesting. Things are really speeding up and heating up in the Lightning development space.

Dual Funded Channels

Andreas Antonopolous: Imagine that Adam and I are sitting across from a table. We have a PVC tube between us, and that PVC tube between us is our channel. Let's say this is funded entirely in peanuts. I have a bowl full of peanuts on my end. If I want to send peanuts to Adam, I can send them, but he doesn't have any on his end. I can send peanuts to him, and once he has some on his end, he can send them back to me. He can make payments in my direction once he has some peanuts on his end of the pipe. But until he does, I have all the peanuts on my end, he has nothing on his end; there's only one way they can flow, and that's from me to him.

That's what a channel normally looks like today. Channels are these two ended things and you have two balances. You have a local balance and a remote balance. Local balance is what you have on your side of the channel. Remote balance is what the other party has put on their side of the channel. Today when I set up a node, if I open channels to other people, I put funds on my end. If they open channels to me they put funds on their end. But when we start, all of those channels have zero on one side - they're only funded in one direction. Until payments start flowing through that means they're unbalanced - they can only flow through in one direction until there's a bit of balance on both sides, then they can flow in both directions.

The proposal here is to be able to set up a channel with another party, but rather than funding it only on your end, you negotiate in advance. You say, "hey, I'm willing to fund it on my end but only if, and only if you fund it on your end. Do we have a deal?" Sure okay, so I'll put a tenth of a Bitcoin on this end, and you put a tenth of a Bitcoin on that end. Now we have a channel that can flow in both directions from the very beginning.

The double funding of transactions involves us coin-joining a transaction where we spend inputs from both of our wallets in order to fund a 2-of-2 [multisig] where both of us have balance. It removes some of the risk of you blindly opening channels to other people.

Adam B. Levine: Do you think this [collaboratively signing with someone else] solution is becoming more prevalent? You're effectively using coin-join as a way to create composite transactions for a purpose that goes beyond privacy.

Andreas Antonopolous: Yes absolutely. I believe in the long term we're going to see the vast majority of transactions migrate to Lightning channels. Therefore every transaction you do on-chain, you're using the opportunity to bootstrap a channel, fund a channel, increase the funding of a channel, rebalance a channel, whatever you're doing. We're going to see a lot more complex transactions that involve multiple different steps.

Bitcoin's dumb contracts are dumb-as-rocks contracts, which is why they can deliver more security, as there is not much room to do fancy things. It's really interesting how even with a simple scripting language you can build some very sophisticated operations.

Sphinx and Rendezvous Routing

Adam B. Levine: Unlike a traditional Bitcoin transaction, I can't just send money to someone [on Lightning]. In the current state of this technology, I can't just send a payment to Andreas because Andreas doesn't have an address on the Lightning Network.

There's this idea called Sphinx send, which aims to solve that problem by removing the need for preemptively generated invoices before a payment could be made. There are also some interesting privacy implications.

Andreas Antonopolous: Lightning today predominantly uses a source-routed mechanism, whereby the sender of the payments decides how the payments will be routed to the recipient. In order to do that, [the sender] gets an invoice from the recipient, and that invoice tells the sender how much to pay and who to pay. Who to pay in Lightning Network is your node's public key. How much to pay is an amount in milli-Satoshis, and then with that information the sender can construct a route. The problem is that the recipient has to request a specific amount with an invoice.

Sphinx routing together with another technique called rendezvous routing is basically an evolution of this routing mechanism that allows the two parties to build the route together. Couple of things emerge from that - one is that you can route to an intermediary node. This called rendezvous routing. With rendezvous, the sender creates a series of encrypted blobs that gets to the rendezvous point, then they take an encrypted blob with the rest of the route from the recipient.

That allows you to hide behind a public node and have private unpublished channels with that node. Everybody who wants to route to you, they know how to get there (intermediary node), but they don't know from there (intermediary node), how it gets to you.

With Sphinx routing, you can do this trick whereby the "secret" that's part of the invoice is sent to the recipient as part of the routing, so that the recipient doesn't need to create an invoice in the first place. That way you can send an arbitrary amount to a recipient address which will look similar to a Lightning address. [The address] identifies a destination node, or even a rendezvous point, without an invoice and without having to communicate with the recipient.

Eltoo

Andreas Antonopolous: Eltoo channels are officially called Decker-Russell-Osuntokun channels. Eltoo uses a very interesting formulation which is a new type of signature called a SIG_HASH_NO_INPUT. This has not been implemented in Bitcoin. It will be implemented as part of the Segwit upgrade for Schnorr signatures and other things, which is scheduled for the end of this year to mid-2020. Once that new signature hash type is added to Bitcoin's blockchain, we can implement Eltoo channels. They're much more efficient. You don't need to keep all of the penalty transactions in revoke commitment states. You can just keep the latest, and that latest allows you to close a channel and prevent someone from cheating. It massively increases the efficiency of the system.

Channel Factories

Andreas Antonopolous: A payment channel (today) is a two-of-two multi-sig. You're locking funds into a [2/2 multi-sig], and then you're deciding how to allocate the balances by swapping transactions off-chain.

But there's no limitation that we only have to do 2/2. What if we do 5/5, and now the channel isn't like a pipe that is connecting two points, but instead it's like a pool that's in the middle of five different nodes.

The example where you would use this is where you have some very critical centralized nodes that are doing a lot of traffic with each other. These are: very large merchants, very large wallets, exchange nodes that are on the Lightning Network - they need to do a lot of volume, a lot of liquidity. But they mostly need to do that with a handful of other nodes. Lightning Network will have many parts of it that are very decentralized, but it will also have some parts that are a bit more centralized. Just like you have very large wallets on the Bitcoin blockchain that are controlled by exchanges, you're likely going to have very large nodes on the Lightning Network.

Adam B. Levine: That kind of sounds like the Lightning Network version of the Liquid side-chain project that blockstreams was working on.

Andreas Antonopolous: It is. Channel factories in the long term will obsolete the need for Liquid.

Stephanie Murphy: Does that kind of create a fractionation or a splintering of the Lightning Network into little clusters?

Andreas Antonopolous: It does. We have to keep thinking of the Lightning Network is in its essence and design an internetwork. It's a network of networks, just like the Internet is. It will have different degrees of clustering and hierarchy. Effectively channel factories are almost like a VPN - it's almost like creating an overlay network on top of the Lightning Network.

Stephanie Murphy: Will there be a way to visualize the hotspots or the different clusters within the Lightning Network?

Andreas Antonopolous: Only the public ones, and only at first. Meaning that the bigger Lightning gets, the less visibility we have into its operation. When there's only a handful of nodes and you can see the traffic flowing from the perspective of one of them, then you're seeing a pretty big percentage of the network. You're seeing the flows and you can make some educated guesses about what's happening in the rest of the network that you're not seeing. When there's five thousand nodes and you control ten of them, now you're seeing a very small percentage of what's happening - most of it is invisible to you. When there's five million nodes, then you're seeing even a smaller fraction. As lightning gets bigger, more and more of these transactions effectively disappear from view. More and more of the channels are private, not advertised public channels, more of the routing happens with rendezvous, and things like that. You have channel factories in the background that are invisible to the outside. You're going to end up with a network that becomes more and more opaque which actually improves privacy.

Lightning Stats: https://1ml.com/

Article quoted: https://www.theblockcrypto.com/2019/01/18/from-reckless-to-wumbology-lightning-networks-infrastructural-build-out/

Eclair (https://acinq.co/) ZAP (https://zap.jackmallers.com/) Blue Wallet (https://bluewallet.io/) Casa Node (https://store.casa/lightning-node/)

Tip LTB:1FZGD64BA7B9GdwDhGGGF92amt9X6VH38K

or Via the Lightning Network at tipltb.tokenly.com/

Thanks for listening to this episode of Let's Talk Bitcoin, content for today's show was provided by Andreas Antonopoulos, Stephanie Murphy, Jonathan Mohan, and Adam B. Levine.

This episode was edited by Dave/Adam and featured music by Jared Rubens.

Send questions or comments to [email protected]

from Money 101 https://letstalkbitcoin.com/blog/post/lets-talk-bitcoin-390-revisiting-lightning-part-2 via http://www.rssmix.com/

0 notes

danielmarkharrison · 5 years