John Newbery [ARCHIVE] on Nostr: 📅 Original date posted:2015-12-23 📝 Original message: Hi all, I've created a ...
📅 Original date posted:2015-12-23
📝 Original message:
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:
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:
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:
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:
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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151223/2f9e7486/attachment.html>;
📝 Original message:
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:
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:
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:
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:
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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151223/2f9e7486/attachment.html>;