Re: [Lightning-dev] Stale Factory (and channel) problem
Good morning Alejandro and list,
Let me characterize the problem in detail.
* Stale offchain system is the issue where one participant of a
multiparticipant offchain system sends a signature that advances the protocol,
but is unable to receive further signatures from one or more of the other
participants to continue the protocol.
* Often, such a stall in the protocol requires some timeout and a backoff path,
aborting the protocol and performing some corrective action onchain.
* More participants means more chances of this kind of stale offchain system
disruption.
* For two-participant offchain systems ("payment channels"), this disruption is
indistinguishable from the other participant going offline.
* For payment channels, the other participant going offline implies that future
updates of the channel will not occur, thus it is always possible for
participants to insist on redoing the signature exchange before performing
further updates.
* Thus, for payment channels, this issue can be fixed by allowing the
exchange of signatures (including those you believe to have sent previously) of
the most recent state upon re-establishing a communication channel.
* BOLT already requires this.
* For multiparticipant offchain systems that host other offchain systems
("channel factories"), this disruption is also indistinguishable from one of
the participants going offline.
* For channel factories, the remaining participants might wish to continue
participating in hosted offchain systems ("on-factory channels") that do not
involve the dropped participant.
* However, it is unknown if the dropped participant is able to construct the
new state or not.
* Thus it is ambiguous if on-factory channels should be rooted from the old
state or the new state.
--
A thought comes to mind: would `SIGHASH_NOINPUT` help?
On-factory channels not affected by a channel reorganization operation at the
factory level can continue to operate, by use of `SIGHASH_NOINPUT`.
For instance, suppose the current factory state is the channels: (A, B) 1; (B,
C) 1; (A, D) 1; (C, D) 1
Suppose A, C, and D propose a reorganization to the new state: (A, B) 1; (B, C)
1; (A, C) 0.5; (C, D) 1.5
If channel states use `SIGHASH_NOINPUT` in signatures, then (A, B) and (B, C)
channels can be trivially re-rooted in both the old or the new factory state,
At the same time, (A, D) 1 and (C, D) 1 are both closed until the new state is
completely signed, so their continued operation is stopped.
And the channels (A, C) 0.5 and (C, D) 1.5 are not yet opened until the new
state is completely signed, so their operation cannot be begun.
This allows unaffected channels to continue operation even if a factory-level
operation is in an indterminate state.
Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Stale Factory (and channel) problem
Good morning Alejandro,
> that's correct, Lightning Factories require support for "transaction
> fragments" to be added dynamically, which are only possible when using
> non-interactive aggregation signature schemes.
I understand.
Unfortunately I am not a mathematician and cannot comment on non-interactive
aggregation signature schemes.
But it seems good to point this to bitcoin-dev.
>
> The proposal of having a factory operator is in fact quite interesting, and
> it is true it would give some scalability while the community discusses other
> more long-lasting options. Is there a more in-depth proposal of the protocol
> you suggest, or any of the like?
I have been mulling this over as a possible intermediate step since the release
of the original Burchert-Decker-Wattenhofer channel factories paper.
However, I have only now actually published it to anybody.
(the basic genesis of this idea was to consider a `fundmultichannel` command
for C-lightning, which I have not been able to implement anyway, hence the base
idea that a factory could be created from a single node doing the funding; in
essence, before this kind of factory could be standardized, this would be a
single transaction funding multiple channels, with the switchover to factories
being "seamless" to users of the C-lightning API once this kind of factory is
standardized)
In particular the tremendous CSV delays in the base Decker-Wattenhofer
construction was too expensive by my opinion.
Alternately, it would be possible to have a Decker-Wattenhofer factory host
Poon-Dryja channels, for instance, with a small number of updates at the
factory level keeping the CSV delay down.
The logic being that channels would need large number of updates, but the
factory could remain useful even with fewer supported updates.
Still need to adjust the CLTV of every HTLC on a route by the largest CSV-delta
of the channels in the route, with plain Poon-Dryja channels having 0 CSV-delta
(the CSV is after the transported contract, not before as in
Decker-Wattenhofer).
After the release of the Decker-Russell-Osuntokun ("eltoo") paper, I pretty
much kept such alternative constructions in the back of my mind as I thought
that a Decker-Russell-Osuntokun channel within a Decker-Russell-Osuntokun
factory would be sufficient.
CSV-delta would double, but still be manageable especially with the smaller CSV
needed in Decker-Russell-Osuntokun.
However, stale factory at least seems to be a "close your factory" kind of
error.
Unfortunately it seems to be easy to trigger by specifically disconnecting
after receiving a message containing a signature.
Thus updates at the factory level are potentially breaking.
Thus, I revived this thought, which requires not this kind of issue.
It also avoids the broken factory by the simple expedient of not allowing a
broken factory by not allowing factory-level operations other than cooperative
closes.
--
A thought occurs: could it be possible to distribute the signatures via node
gossip?
Factory-level operations change the channel-level topology, thus require some
gossip message anyway.
(in particular, closure of a channel inside a factory is not visible, unlike
channel closures onchain which are visible onchain, thus need to have some
message to attest to the destruction of the channel inside a factory)
This may mitigate the effect of stale factory by allowing the receipt of the
next factory state signatures via other means than direct message sending.
Of course, if some factory participant becomes completely unresponsive before
it broadcasts its signature, the factory operation cannot proceed, but the
broken factory problem means that is not possible to perform factory operations
without all factory participants anyway.
(it would also be helpful since participants in the same factory may not have
direct communication channels with each other, and nodes are allowed to not
broadcast any method of direct contact, so we *do* need some other way to
perform a one-to-many send)
Basically, third parties would not consider a "change in channels in factory"
gossip message as complete until it receives all signatures from all factory
members, but would still gossip such fragments around.
The "change in channels in factory" gossip might contain the sighash of the
transaction, plus the actual signatures unencrypted.
Third parties would be able to verify the signatures as valid, and could check
that the signatures match the n-of-n onchain, but would not be able to force a
unilateral factory closure as they would not know the contents of the actual
transaction.
The factory participants could lie and use a random sighash, but anything
happening inside a factory is their say-so anyway and cannot be verified in
detail unless one is also a participant.
And if the other participants are lying about the intended next state of the
factory, one need only refuse to release such a signature, which would keep the
Re: [Lightning-dev] Stale Factory (and channel) problem
Hi ZmnScpXj,
that's correct, Lightning Factories require support for "transaction
fragments" to be added dynamically, which are only possible when using
non-interactive aggregation signature schemes.
The proposal of having a factory operator is in fact quite interesting, and
it is true it would give some scalability while the community discusses
other more long-lasting options. Is there a more in-depth proposal of the
protocol you suggest, or any of the like?
Best,
Alejandro.
Alejandro Ranchal Pedrosa
On 16 Apr 2019 at 17:39, > wrote:
Good morning Alejandro,
Your analyses seem to be quite spot on.
It does seem that factories need some work to be done further.
As I understand it, the proposal in "Scalable Lightning Factories for
Bitcoin" require a new signature scheme at the blockchain layer, is
that correct?
I observe that current Lightning uses single-funded channels.
This was to initially simplify the protocol.
Although dual-funded channels are being proposed, various issues came up.
Perhaps some simplification of factories is possible.
* Suppose we initially insist that factories be single-funded.
In this mechanism, a node may open multiple channels to multiple
other nodes using a single onchain UTXO.
* The funder of the factory is the factory operator.
* If the other nodes on the factory wish to create some change at the
factory level, they contact the factory operator only.
If the factory operator allows it, only will the factory-level
operation be allowed.
* The only factory-level operation allowed is a cooperative close.
Each channel in the factory must be in a quiescent state (no HTLCs)
and the factory operator requests signatures from all nodes.
What happens is that the factory operator requests and distributes
signatures for each individual channel closure first, before
corodinating to request and distribute signatures for the factory
close.
The operation completes on publication of the factory close.
* The factory close is the cut-through of the allocation transaction
and the individual channel close transaction, with the mining fee for
the factory close transaction equal to the total mining fees on the
allocation transaction and individual channel close transactions.
It may have fewer total outputs as the channel outputs of the
factory operator can be merged into a single output.
If both allocation and factory close are marked as RBF, then the
factory close will dominate over the allocation transaction in
feerate.
Miners would strongly prefer the factory close, and even if the
allocation transaction gets through, it does not degrade security (but
unnecessarily spends block space, meaning rational miners would not
prefer it especially since the factory close gives the same fee and is
smaller).
* This construction requires a simple n-of-n at the factory level, as
there is no update.
This is still a "factory", of a sort, but with only one known-safe operation.
The intent is simply to provide some of the scaling boost for now,
until we can determine how best to implement factory-level changes.
Regards,
ZmnSCPxj
‐‐‐ Original Message ‐‐‐
On Tuesday, April 16, 2019 7:59 AM, Alejandro Ranchal Pedrosa
wrote:
> Hi all,
>
> This is the first of three related different emails on the topic,
> through which I will explain what, to my understanding, is the state of
> the construction of channel factories.
>
> First let's have a look at a situation known as a stale factory, or
> channel [1], as defined by Ranchal-Pedrosa et al.. For simplicity, let's
> consider a channel first. Suppose a DMC channel Alice between Alice and
> Bob. This channel must be updated through so-called refunding
> transactions R^k_{AB}, where k refers to the state (so initial state
> R^0_{AB}, after one payment R^1_{AB}, etc.) and {AB} refers to both A
> and B having already signed the transaction (if a dot appears instead of
> A or B, it means there's a signature missing.
> The stale channel derives from the fact that either Alice or Bob needs
> to sign before their counterparty. Suppose a situation like this:
> Alice Bob
> | |
> |<--R^1{.B}<--|
>
> |-->R^1_{AB}-->|
>
> ......
>
> |<--R^k_{.B}<--|
>
> | |
>
> In this situation, Bob does not have a fully signed transaction for the
> last state k, whereas Alice may have it (from the point of view of Bob).
> That is, even if the message was lost, all Bob knows in the trustless
> model is that he signed for something that he did not get a fully signed
> transaction back for. So he should believe Alice has the fully signed
> transaction and may enforce it if necessary. At the same time though,
> Bob can enforce transaction R^{k-1}{AB}, which he must have, and
> therefore finish with the ambiguity by publishing on-chain such state,
> should he not be able to communicate with Alice and perform updates anymore.
> The stale factory is the same situation, but affecting a new allocation
>
Re: [Lightning-dev] Stale Factory (and channel) problem
Good morning Alejandro,
Your analyses seem to be quite spot on.
It does seem that factories need some work to be done further.
As I understand it, the proposal in "Scalable Lightning Factories for Bitcoin"
require a new signature scheme at the blockchain layer, is that correct?
I observe that current Lightning uses single-funded channels.
This was to initially simplify the protocol.
Although dual-funded channels are being proposed, various issues came up.
Perhaps some simplification of factories is possible.
* Suppose we initially insist that factories be single-funded.
In this mechanism, a node may open multiple channels to multiple other nodes
using a single onchain UTXO.
* The funder of the factory is the factory operator.
* If the other nodes on the factory wish to create some change at the factory
level, they contact the factory operator only.
If the factory operator allows it, only will the factory-level operation be
allowed.
* The only factory-level operation allowed is a cooperative close.
Each channel in the factory must be in a quiescent state (no HTLCs) and the
factory operator requests signatures from all nodes.
What happens is that the factory operator requests and distributes signatures
for each individual channel closure first, before corodinating to request and
distribute signatures for the factory close.
The operation completes on publication of the factory close.
* The factory close is the cut-through of the allocation transaction and the
individual channel close transaction, with the mining fee for the factory close
transaction equal to the total mining fees on the allocation transaction and
individual channel close transactions.
It may have fewer total outputs as the channel outputs of the factory
operator can be merged into a single output.
If both allocation and factory close are marked as RBF, then the factory
close will dominate over the allocation transaction in feerate.
Miners would strongly prefer the factory close, and even if the allocation
transaction gets through, it does not degrade security (but unnecessarily
spends block space, meaning rational miners would not prefer it especially
since the factory close gives the same fee and is smaller).
* This construction requires a simple n-of-n at the factory level, as there is
no update.
This is still a "factory", of a sort, but with only one known-safe operation.
The intent is simply to provide some of the scaling boost for now, until we can
determine how best to implement factory-level changes.
Regards,
ZmnSCPxj
‐‐‐ Original Message ‐‐‐
On Tuesday, April 16, 2019 7:59 AM, Alejandro Ranchal Pedrosa
wrote:
> Hi all,
>
> This is the first of three related different emails on the topic,
> through which I will explain what, to my understanding, is the state of
> the construction of channel factories.
>
> First let's have a look at a situation known as a stale factory, or
> channel [1], as defined by Ranchal-Pedrosa et al.. For simplicity, let's
> consider a channel first. Suppose a DMC channel Alice between Alice and
> Bob. This channel must be updated through so-called refunding
> transactions R^k_{AB}, where k refers to the state (so initial state
> R^0_{AB}, after one payment R^1_{AB}, etc.) and {AB} refers to both A
> and B having already signed the transaction (if a dot appears instead of
> A or B, it means there's a signature missing.
> The stale channel derives from the fact that either Alice or Bob needs
> to sign before their counterparty. Suppose a situation like this:
> Alice Bob
> | |
> |<--R^1{.B}<--|
>
> |-->R^1_{AB}-->|
>
> ... ...
>
> |<--R^k_{.B}<--|
>
> | |
>
> In this situation, Bob does not have a fully signed transaction for the
> last state k, whereas Alice may have it (from the point of view of Bob).
> That is, even if the message was lost, all Bob knows in the trustless
> model is that he signed for something that he did not get a fully signed
> transaction back for. So he should believe Alice has the fully signed
> transaction and may enforce it if necessary. At the same time though,
> Bob can enforce transaction R^{k-1}{AB}, which he must have, and
> therefore finish with the ambiguity by publishing on-chain such state,
> should he not be able to communicate with Alice and perform updates anymore.
> The stale factory is the same situation, but affecting a new allocation
> transaction, as defined by Decker et al.[2], rather than a new refunding
> transaction. There are two major differences between a stale factory and
> a stale channel:
> - In a stale factory, only one user (out of n) can already cause
> this situation. That is, even if the remaining n-1 users are active and
> online, with one of them not replying back, is enough for Alice to
> believe that there's a possibility that one of its counterparties might
> have the fully signed new allocation transaction.
> - The new allocation
[Lightning-dev] Stale Factory (and channel) problem
Hi all,
This is the first of three related different emails on the topic,
through which I will explain what, to my understanding, is the state of
the construction of channel factories.
First let's have a look at a situation known as a stale factory, or
channel [1], as defined by Ranchal-Pedrosa et al.. For simplicity, let's
consider a channel first. Suppose a DMC channel Alice between Alice and
Bob. This channel must be updated through so-called refunding
transactions R^k_{AB}, where k refers to the state (so initial state
R^0_{AB}, after one payment R^1_{AB}, etc.) and _{AB} refers to both A
and B having already signed the transaction (if a dot appears instead of
A or B, it means there's a signature missing.
The stale channel derives from the fact that either Alice or Bob needs
to sign before their counterparty. Suppose a situation like this:
Alice Bob
| |
|<--R^1_{.B}<--|
|-->R^1_{AB}-->|
... ...
|<--R^k_{.B}<--|
| |
In this situation, Bob does not have a fully signed transaction for the
last state k, whereas Alice may have it (from the point of view of Bob).
That is, even if the message was lost, all Bob knows in the trustless
model is that he signed for something that he did not get a fully signed
transaction back for. So he should believe Alice has the fully signed
transaction and may enforce it if necessary. At the same time though,
Bob can enforce transaction R^{k-1}_{AB}, which he must have, and
therefore finish with the ambiguity by publishing on-chain such state,
should he not be able to communicate with Alice and perform updates anymore.
The stale factory is the same situation, but affecting a new allocation
transaction, as defined by Decker et al.[2], rather than a new refunding
transaction. There are two major differences between a stale factory and
a stale channel:
- In a stale factory, only one user (out of n) can already cause
this situation. That is, even if the remaining n-1 users are active and
online, with one of them not replying back, is enough for Alice to
believe that there's a possibility that one of its counterparties might
have the fully signed new allocation transaction.
- The new allocation transaction may or may not affect a particular
channel in the factory, but if it does then users do not even know in
which channel they have their funds.
Ways to go around these are:
- Try to create a new refunding (or allocation) transaction
R^{k+1}_{AB}. If it fails though, now there are three possible
transactions. Besides, if the channel/factory follows the DMC
construction, the timer reduces yet again.
- Close the channel/factory by publishing it on the Blockchain.
Open for discussion about this situation and its implications. In an
upcoming email I will explain what, to my understanding, is the biggest
problem associated with this situation.
--
Alejandro Ranchal-Pedrosa
[1]: Scalable Lightning Factories for Bitcoin
[2]: Scalable Funding of Bitcoin MicropaymentChannel Networks
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
