Alejandro Ranchal Pedrosa [ARCHIVE] on Nostr: 📅 Original date posted:2019-04-16 📝 Original message: Hi ZmnScpXj, that's ...
📅 Original date posted:2019-04-16
📝 Original message:
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, <ZmnSCPxj <zmnscpxj at protonmail.com>> 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
<a.ranchalpedrosa at gmail.com> 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 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 possibletransactions. 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190416/324ed866/attachment.html>;
📝 Original message:
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, <ZmnSCPxj <zmnscpxj at protonmail.com>> 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
<a.ranchalpedrosa at gmail.com> 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 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 possibletransactions. 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190416/324ed866/attachment.html>;