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  

_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to