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