Timeline for Is Bitcoin-lightning still not scalable?
Current License: CC BY-SA 4.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 24, 2021 at 5:01 | comment | added | Martin Schwarz | Aren't such huge n-of-n channels more likely to fail to update assuming O(1) failure rate of each user? If each user fails (loses key, gets hacked) with probability p, 0<p<1, then the success probability for a channel update is (1-p)^n which is exponentially decaying with growing n. Thus, the probability of forced closures (on-chain) for fund recovery is 1-(1-p)^n, very likely. Thus, IMHO, such large channels will cause many on-chain transactions. There might be an optimal trade-off in terms of n between 2-party channels with high dependability and n-party channels with low dependability. | |
| May 22, 2021 at 23:47 | comment | added | Murch♦ | Sorry to sound pessimistic, but even setting up channel factories and then having smaller subgroups of users be able to update their substates bilaterally seems like a major challenge for 40 new users, let alone 480—even with Eltoo, but with LN-penalty it sounds nigh impossible. | |
| May 22, 2021 at 23:22 | comment | added | Rene Pickhardt | As far as I know Eltoo channels would most certainly make communication and handling of multiparty channel state easier. So yes this additional upgrade would come in handy but I believe ln-penalty would work for multiparty channels if it had to. | |
| May 22, 2021 at 22:49 | comment | added | Murch♦ | Isn't that severely difficult under the ln-penalty paradigm? Wouldn't we need SIGHASH_ANYPREVOUT? | |
| May 22, 2021 at 13:40 | history | answered | Rene Pickhardt | CC BY-SA 4.0 |