Alejandro Ranchal Pedrosa [ARCHIVE] on Nostr: 📅 Original date posted:2019-04-15 📝 Original message: Hi all, This is the first ...
📅 Original date posted:2019-04-15
📝 Original message:
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
📝 Original message:
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