Hi ZmnSCPxj,
I also thought about the possibility of using 'SIGHASH_NOINPUT', it
certainly offers a functionality very similar to the one I suggest in
the paper.
The problem with 'SIGHASH_NOINPUT' as it is now is that, if I am not
mistaken, in the example you are showing, seems like A,D and
Good morning Alejandro and list,
Let me characterize the problem in detail.
* Stale offchain system is the issue where one participant of a
multiparticipant offchain system sends a signature that advances the protocol,
but is unable to receive further signatures from one or more of the other
p
Good morning Alejandro,
> 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.
I understand.
Unfortunately I am not a mathematician and cannot comment on no
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 g
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 c
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-Pedr