1065 sats \ 3 replies \ @niftynei OP 9 Mar 2022 freebie \ parent \ on: @niftynei AMA: lightning, FOSS, bitcoin, leveling up the next 100 btc devs at Base58 bitcoin
world peace, aka eltoo.
people make a lot of noise about how great the penalty system is for keeping nodes honest on lightning, but the burden of that penalty data is actually enormous. it weighs down every single lightning node, especially the most "productive" or routing heavy ones. you end up paying on-chain fees to close channels to be able to compact your database to a manageable size -- there's a real world cost to the ability to enforce penalties in those extra onchain fees.
eltoo fixes this by bounding the required state storage per channel update to 1, rather than n.
doesn't getting rid of state work with just AJ's proposal from https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003278.html
should everyone be focused on that?
w.r.t. musig being the barrier, could we just start using Taproot with a NUMS point and a traditional multisig & still get this benefit?
reply
i feel like you're using this as an opportunity to propose your own solutions rather than asking my insight about something i actually have good context for
reply
i think you're presuming bad faith -- i asked an open ended question, and asked a follow up. you could have responded with anything -- you said eltoo, and said for the purposes of state compaction being the issue. in the ranking of all problems i didn't think that was so severe. i'm mostly an outsider to lightning development, and AJ's proposal has nothing to do with anything i work on. but if it's a solution for state compaction you didn't know about, that's groovy and i hope useful information. if it's not, i'd love to learn why you don't think so.
reply