From jonnynewbs at gmail.com Wed Dec 23 11:41:02 2015 From: jonnynewbs at gmail.com (John Newbery) Date: Wed, 23 Dec 2015 22:41:02 +1100 Subject: [Lightning-dev] Lightning hubs and pooled reserves Message-ID: Hi all, I've created a gist describing this idea here: https://gist.github.com/jonnynewbs/a8ac4d7d27cb74c5b486 with images. I recently watched Joseph Poon's presentation at the scaling bitcoin HK conference. He argued that there's a natural tendency *away* from hubs and centralization in lightning network, because a hub needs to hold bitcoin in reserve for each payment channel: image 1: https://gist.githubusercontent.com/jonnynewbs/a8ac4d7d27cb74c5b486/raw/839cf9152630ee8c5596b55e206b6f7f42121c61/zHub1.jpg In this example Hector has tied up 40 bitcoin in order to open channels with 4 nodes. He needs to place his bitcoin in those channels in order to have enough liquidity to route payments through the channels. If all the bitcoin in the channel had been fronted by the nodes, he wouldn't be able to route payments. In this example Alice tries to pay Bob through Hector, but Hector's channel to Bob is depleted on Hector's side so he can't pay: image 2: https://gist.githubusercontent.com/jonnynewbs/a8ac4d7d27cb74c5b486/raw/839cf9152630ee8c5596b55e206b6f7f42121c61/zHub2.jpg The velocity of money through each of those channels is going to be low, so Hector's profit opportunity to charge transfer fees on those channels is low compared to the time that he's tying up his assets. I started thinking about why it was that Hector would actually need to tie up those funds. A properly-functioning hub should always have a net balance of zero - all outflows from the hub are matched by inflows from another node, so if the hub is working properly, it should always be solvent. Why then does it necessarily need to hold a reserve for each node it connects to? Imagine someone wanted to create a hub in lightning *without* tying up funds in lots of channels. One way he might start thinking about it: 1. Create some metatoken/coloured coin on top of bitcoin. Lets call it Hectorcoin. 2. Open channels to different nodes, where the node provides the bitcoin for the channel, and the hub provides Hectorcoins in the other direction. The hub would only need to provide a negligable amount of actual bitcoin value with Hectorcoins encoded on top of that small input. 3. If the channel gets closed and the node is net positive (ie in the channel the bitcoin they initially provided plus some Hectorcoin), the node can 'sell' the Hectorcoin back to the hub for bitcoin. Hector's network would initially look like this. Bitcoin are in black, Hectorcoin are in bold green: image 3: https://gist.githubusercontent.com/jonnynewbs/a8ac4d7d27cb74c5b486/raw/839cf9152630ee8c5596b55e206b6f7f42121c61/zHub3.jpg Transactions flow through the hub, and eventually Alice is 10 'bitcoin' up. Hector hasn't sent her 10 real bitcoin through the channel, but 10 Hectorcoin. The network now might look like this: image 4: https://gist.githubusercontent.com/jonnynewbs/a8ac4d7d27cb74c5b486/raw/839cf9152630ee8c5596b55e206b6f7f42121c61/zHub4.jpg Note that Hector's balace of (Bitcoin + Hectorcoin) always remains 40. Alice now wants to cash out her channel. She closes the channel as normal, and then presents the Hectorcoin to Hector in exchange for actual bitcoin. At this point either: - Hector is holding enough bitcoin in reserve to pay out to Alice; or - Hector doesn't hold enough bitcoin in reserve (In this scenario Hector has a temporary *liquidity* issue, but remains *solvent*). He therefore needs to close down his channels to Dan and Claire to free up his bitcoin tied up in those channels. This basic example requires counterparty trust in Hector. That's because there's no way to prove that he actually holds enough bitcoin in his reserves/channels to pay out in exchange for Hectorcoin *unless* those coins are provable locked up somewhere (eg a multisig), which defeats the whole purpose - he's trying to avoid tying up value. However, many people might consider the efficiency and connectedness of dealing with a hub to be a worthwhile trade-off on balance. Hector might think about improving his hub by: - somehow providing a proof that his net position is zero and so he's provably solvent. That would eliminate the risk of a hub going rogue, extracting coins from the network and becoming insolvent - Having some way for Alice to automatically exchange Hectorcoin for that value without asking Hector's permission. Both of those things feel like they're possible, but perhaps someone smarter than I am can comment on whether they actually are. I'm not suggesting that this is the way we want to go, but thought it was interesting enough to share. Interested to hear people's thoughts. John -------------- next part -------------- An HTML attachment was scrubbed... URL: