Re: [Lightning-dev] Stale Factory (and channel) problem

2019-04-20 Thread Alejandro Ranchal Pedrosa
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

Re: [Lightning-dev] Stale Factory (and channel) problem

2019-04-16 Thread ZmnSCPxj via Lightning-dev
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

Re: [Lightning-dev] Stale Factory (and channel) problem

2019-04-16 Thread ZmnSCPxj via Lightning-dev
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

Re: [Lightning-dev] Stale Factory (and channel) problem

2019-04-16 Thread Alejandro Ranchal Pedrosa
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

Re: [Lightning-dev] Stale Factory (and channel) problem

2019-04-16 Thread ZmnSCPxj via Lightning-dev
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