Dear David,

Thank you very much for your time reading and analyzing the work.


You are correct that the design relies on the honest majority assumption.
However, I disagree that it restricts the usability of the proposal,
due to the following considerations.


1. Any distributed system consensus, including bitcoin PoW consensus,
relies on the same (honest majority) or a stronger (hones 2/3) assumption;
and for some cases even 1/3 can break the consensus conditions (like with
selfish mining); so the untrusted peer networks are not something which
by definition requires stronger guarantees.


2. In the case of the proposed protocol, the only thing that relies on the
the honest majority is the safety of funds that a peer _has received_ during
the operations when some of the peers were unresponsive. This risk is
fully controllable by the peer (he may not accept such transfers or limit
their volume to some accepted risk level) and is just a different tradeoff
to the risks of the existing lightning network (like the possibility of the loss
of funds when going offline and revealing an invalid state).


3. These risks can be further efficiently mitigated by a reputation system or
a stake put by the peers joining multipeer channel - which can be a topic
of a further protocol development.


Regarding your second argument that the exclusion of a peer takes three
onchain transactions, it is not correct: nonvoluntary exclusion takes just
two transactions: current allocation and new funding. No other protocol
proposes cheaper (in terms of transaction size) non-voluntary exclusion.
Finally, the proposal can be combined with the original channel factories
idea where Nucleus channels can be created via a channel factory,
avoiding and onchain footprint for a non-voluntary exclusion process.


Thank you for the reference to the previous John Law research, I was
aware that it is a different form of approach with different tradeoffs
compared to the approach taken in the proposed Nucleus protocol.


Kind regards,
the author of the proposal
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to