Atomic Mr Nuclear [ARCHIVE] on Nostr: š Original date posted:2023-08-26 šļø Summary of this message: The author ...
š
Original date posted:2023-08-26
šļø Summary of this message: The author disagrees that the proposed protocol restricts usability and argues that the risks can be mitigated through control and reputation systems. They also address the argument about exclusion of a peer and propose combining the protocol with channel factories.
š Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230826/f57e2b24/attachment.html>;
šļø Summary of this message: The author disagrees that the proposed protocol restricts usability and argues that the risks can be mitigated through control and reputation systems. They also address the argument about exclusion of a peer and propose combining the protocol with channel factories.
š Original message:
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230826/f57e2b24/attachment.html>;