2023-09-07T11:17:18Z https://njump.me Atomic Mr Nuclear [ARCHIVE] https://njump.me/npub1qs7weanztacgcfymp0rl82zykkd0uec5wruj40pp36eyy5wlmtrqet6jpm https://njump.me/nevent1qqsp36jujm3k6em0xkwu7cywsqdqakzg89kllhwe9nlja98hyld8zpqzyqzrem8kvf0hprpynv9u0uaggj6e4ln8z3c0j24uyx8tysj3mldvvxqjjmp In reply to <a href='/nevent1qqsgw7awnytntjspceguqn0w6gdwf8x57jxn8r2x60mgjkg9ul8ckxspp4qmc'>nevent1q…4qmc</a><br/>_________________________<br/><br/>📅 Original date posted:2023-08-26<br/>🗒️ 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.<br/>📝 Original message:<br/>Dear David,<br/><br/>Thank you very much for your time reading and analyzing the work.<br/><br/><br/>You are correct that the design relies on the honest majority assumption.<br/>However, I disagree that it restricts the usability of the proposal,<br/>due to the following considerations.<br/><br/><br/>1. Any distributed system consensus, including bitcoin PoW consensus,<br/>relies on the same (honest majority) or a stronger (hones 2/3) assumption;<br/>and for some cases even 1/3 can break the consensus conditions (like with<br/>selfish mining); so the untrusted peer networks are not something which<br/>by definition requires stronger guarantees.<br/><br/><br/>2. In the case of the proposed protocol, the only thing that relies on the<br/>the honest majority is the safety of funds that a peer _has received_ during<br/>the operations when some of the peers were unresponsive. This risk is<br/>fully controllable by the peer (he may not accept such transfers or limit<br/>their volume to some accepted risk level) and is just a different tradeoff<br/>to the risks of the existing lightning network (like the possibility of the loss<br/>of funds when going offline and revealing an invalid state).<br/><br/><br/>3. These risks can be further efficiently mitigated by a reputation system or<br/>a stake put by the peers joining multipeer channel - which can be a topic<br/>of a further protocol development.<br/><br/><br/>Regarding your second argument that the exclusion of a peer takes three<br/>onchain transactions, it is not correct: nonvoluntary exclusion takes just<br/>two transactions: current allocation and new funding. No other protocol<br/>proposes cheaper (in terms of transaction size) non-voluntary exclusion.<br/>Finally, the proposal can be combined with the original channel factories<br/>idea where Nucleus channels can be created via a channel factory,<br/>avoiding and onchain footprint for a non-voluntary exclusion process.<br/><br/><br/>Thank you for the reference to the previous John Law research, I was<br/>aware that it is a different form of approach with different tradeoffs<br/>compared to the approach taken in the proposed Nucleus protocol.<br/><br/><br/>Kind regards,<br/>the author of the proposal<br/>-------------- next part --------------<br/>An HTML attachment was scrubbed...<br/>URL: &lt;<a href="http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230826/f57e2b24/attachment.html&gt">http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230826/f57e2b24/attachment.html&gt</a>; 2023-09-07T11:17:26Z