Tier Nolan [ARCHIVE] on Nostr: 📅 Original date posted:2016-05-27 📝 Original message: Hubs on the Lightning ...
📅 Original date posted:2016-05-27
📝 Original message:
Hubs on the Lightning network require a large amount of capital. If a hub
wants to be able to send 1 BTC to N customers, then it needs to create N
channels and lock 1BTC in each of them.
This creates an economy of scale effect for hubs. Hubs with more capital
can support larger channels and/or more customers. If the de facto barrier
to entry for hubs is high enough, then the number of hubs will be small,
making cartel formation easier.
With multi-party channels, a hub could share its capital between multiple
customers.
I think it should be possible to shoehorn multi-party channels as a soft
fork, but makes it harder to explain the concept. For this post, I will
assume a hard-fork and any rule change can be used.
*** Basic Multiparty Channels ***
A basic multi-party channel requires all participants to sign each state
update.
Each state update would incorporate the index number of the state. This
allows states to be ordered. They would also have a unique channel id.
Assuming everyone is honest, a channel would operate as follows.
<channel established by multiple participants and timeout agreed>
<state update 1, signed by all participants>
<state update 2, signed by all participants>
<state update M, signed by all participants>
<channel times out - closes are now allowed>
<someone publishes a state update, signed by all but signed again (twice)
by the broadcaster>
<outputs unspendable for 24 hours>
If the broadcaster didn't publish the most recent state update, then
another participant is allowed to broadcast a later update. If this is
included in a block within the 24 hour window, then it overwrites the
original state update (and starts another 24 hour timeout).
This is the main hard fork bit, the state update is a transaction that is
included in the block chain. Unlike normal transactions, state updates can
be overwritten within 24 hours. Locking the transaction outputs during
that time means that this is safe.
Since each broadcaster has to sign their broadcast, it is possible to
determine who is to blame for broadcasting an expired state update.
They could lose their contribution to the channel as with normal lightning
network channels.
This creates an incentive for all parties to broadcast only the most recent
state.
This system require signatures from all the parties for all state updates
and updates are impossible while any of the parties are offline (or
uncooperative).
*** Flexible Multiparty Channels ***
A better system is that state updates require the signatures of parties who
lose out due to the state update only. Unless a state update decreases a
participant's holdings, that participant is not required to sign the update.
For efficiency, the hub could be a special member that must sign all
updates. It is assumed that the hub is online all the time.
Until the channel times out, only the hub can broadcast the final state of
the channel. After that point, any of the participants would be allowed to
broadcast to close the channel. This prevents a participant from closing a
channel that everyone else wants to keep open.
As before the outputs from the channel would be locked for 24 hours to give
participants a chance to challenge the final state.
Participants would have the option of broadcasting the latest state that
they signed. A challenge is only allowed if the participant has less
holdings in the final state than in the latest one that they signed.
The hub could then respond with a later state that the participant signed.
If the hub broadcasts that proof of fraud, then the participant would lose
their money (or vice versa, if the hub tried to steal their money).
Since each fraud step causes a participant to be kicked from the channel,
eventually, it should settle on the actual honest final state and in most
cases, hubs would be honest anyway.
The state updates could work like a blockchain with previous pointers.
This means that if a participant signs state n, it is also signing all
states below state n.
Parties would download the entire state chain from the hub whenever they
come online and verify that it is a valid history. If the hub signs states
on more than than 1 fork, then the hub would lose its deposit.
If the hub is honest, then the close step should be reasonably fast. Fraud
claim timeouts could be handled in parallel too.
It should be possible to set things up so that the channel is mostly
eternal. Parties could be added and removed from the channel without it
having to be closed. This would require some kind of on-chain activity
though unless the withdrawal is handled by moving to another channel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160527/ce86e199/attachment.html>;
📝 Original message:
Hubs on the Lightning network require a large amount of capital. If a hub
wants to be able to send 1 BTC to N customers, then it needs to create N
channels and lock 1BTC in each of them.
This creates an economy of scale effect for hubs. Hubs with more capital
can support larger channels and/or more customers. If the de facto barrier
to entry for hubs is high enough, then the number of hubs will be small,
making cartel formation easier.
With multi-party channels, a hub could share its capital between multiple
customers.
I think it should be possible to shoehorn multi-party channels as a soft
fork, but makes it harder to explain the concept. For this post, I will
assume a hard-fork and any rule change can be used.
*** Basic Multiparty Channels ***
A basic multi-party channel requires all participants to sign each state
update.
Each state update would incorporate the index number of the state. This
allows states to be ordered. They would also have a unique channel id.
Assuming everyone is honest, a channel would operate as follows.
<channel established by multiple participants and timeout agreed>
<state update 1, signed by all participants>
<state update 2, signed by all participants>
<state update M, signed by all participants>
<channel times out - closes are now allowed>
<someone publishes a state update, signed by all but signed again (twice)
by the broadcaster>
<outputs unspendable for 24 hours>
If the broadcaster didn't publish the most recent state update, then
another participant is allowed to broadcast a later update. If this is
included in a block within the 24 hour window, then it overwrites the
original state update (and starts another 24 hour timeout).
This is the main hard fork bit, the state update is a transaction that is
included in the block chain. Unlike normal transactions, state updates can
be overwritten within 24 hours. Locking the transaction outputs during
that time means that this is safe.
Since each broadcaster has to sign their broadcast, it is possible to
determine who is to blame for broadcasting an expired state update.
They could lose their contribution to the channel as with normal lightning
network channels.
This creates an incentive for all parties to broadcast only the most recent
state.
This system require signatures from all the parties for all state updates
and updates are impossible while any of the parties are offline (or
uncooperative).
*** Flexible Multiparty Channels ***
A better system is that state updates require the signatures of parties who
lose out due to the state update only. Unless a state update decreases a
participant's holdings, that participant is not required to sign the update.
For efficiency, the hub could be a special member that must sign all
updates. It is assumed that the hub is online all the time.
Until the channel times out, only the hub can broadcast the final state of
the channel. After that point, any of the participants would be allowed to
broadcast to close the channel. This prevents a participant from closing a
channel that everyone else wants to keep open.
As before the outputs from the channel would be locked for 24 hours to give
participants a chance to challenge the final state.
Participants would have the option of broadcasting the latest state that
they signed. A challenge is only allowed if the participant has less
holdings in the final state than in the latest one that they signed.
The hub could then respond with a later state that the participant signed.
If the hub broadcasts that proof of fraud, then the participant would lose
their money (or vice versa, if the hub tried to steal their money).
Since each fraud step causes a participant to be kicked from the channel,
eventually, it should settle on the actual honest final state and in most
cases, hubs would be honest anyway.
The state updates could work like a blockchain with previous pointers.
This means that if a participant signs state n, it is also signing all
states below state n.
Parties would download the entire state chain from the hub whenever they
come online and verify that it is a valid history. If the hub signs states
on more than than 1 fork, then the hub would lose its deposit.
If the hub is honest, then the close step should be reasonably fast. Fraud
claim timeouts could be handled in parallel too.
It should be possible to set things up so that the channel is mostly
eternal. Parties could be added and removed from the channel without it
having to be closed. This would require some kind of on-chain activity
though unless the withdrawal is handled by moving to another channel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160527/ce86e199/attachment.html>;