[Lightning-dev] Lightning Factories & Non-interactive aggregation signature schemes for Bitcoin

[Alejandro Ranchal Pedrosa]

Hi all,

This is the last 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.

Having shown the stale factory and broken factory situation, it remains 
clear one thing: Every time an update attempt starts and does not end up 
in a fully signed transactions, it is safest (and possibly even the only 
option) to close the factory (or channel), in order to finish the 
ambiguity in the factory.

Considering this, seems fair to look at how fast can one do that with 
the current proposal for a DMC factory[1]. Given a lifetime l_f, defined 
in a number of blocks at the creation of the factory, if a stale factory 
arrives at state k, the time to close the factory remains l_f-k (in the 
worst-case that one of the members of the factory is in fact 
unresponsive, either because of not being online, or being malicious). 
This is a big trade-off: the bigger l_f is, the more time one can 
potentially use the factory, but the more time one has to potentially 
wait before being able to keep using its money.

This is why we propose a Lightning Factory[2]. Lightning channels have 
constant time to close themselves, and the lifetime is potentially 
unlimited, it is not even defined as it isn't required by the protocol. 
We extend this idea to factories.

The problem of a construction like this is, in order to account for the 
multiple amount of nested frauds possible in an attempt to close the 
so-called Lightning Factory, one would require a protocol that stores 
off-chain n! transactions (being n the amount of users in the factory).

This is where the biggest element of discussion lies from the series of 
emails above-mentioned: if the Bitcoin community is already considering 
Schnorr-based signature schemes, that allow for interactive aggregation 
of messages, I think we should at least consider as seriously other 
signature schemes that allow for *NON*-interactive aggregation of messages.

In such way, instead of requiring n! transactions, one could have just 
O(n) fragments of a transaction, that can be aggregated 
non-interactively depending on the particular nested fraud attempts 
(more details in the paper [2]) to generate a specific proof-of-fraudS.

Another motivation for such schemes is the aggregation of independent 
transactions in Blocks, which has already been proposed, but could 
actually never take place under an interactive aggregation scheme. 
Current literature suggests BGLS as probably the best option to 
consider, but virtually any non-interactive aggregation scheme should 
work (even one based on schnorr signatures, should that even be 
potentially possible).

This discussion must be held in the community if we seriously want to 
scale Bitcoin, since DMC Factories are just too dangerous to be used 
with a big amount of users being part of the Factory, and better 
approaches can be applied under non-interactive aggregation schemes.

-- 
Alejandro Ranchal Pedrosa


[1]:  Scalable Funding of Bitcoin Micropayment Channel Networks
[2]:  Scalable Lightning Factories for Bitcoin