buck on Nostr: Good walk-thru as well of how we as a community that are custodians of an open, ...

Good walk-thru as well of how we as a community that are custodians of an open, decentralized, and immensely valuable protocol need to have reasonable expectations. Lightning didn’t fix all of bitcoin’s problems, but it also was necessary to get the MVP out, in no small part b/c deploying proof of concept is how we learn.

We should look towards the future with the same clear-eyed practicality.

quoting note1nqr…2hjg

regular reminder that lightning *is* a “shared utxo” protocol that uses covenants (and multisig) to scale bitcoin payment tx thruput

most of the commentary against it points out that it does not scale number of holders in relation to # of utxos. in my mind this is a good sign of the protocol’s success (it shipped and people use it and they found drawbacks with the MVP). It’s also a sign of bad messaging around the applicability of 2-party accounts to certain payment situations (venmo for example)

sometimes it is useful to have multiparty channels; i’d argue that liquid is one such example of this.

federated mints are another one; note that both of these multiparty systems require consensus algorithms to function. fedimints were using BFS, (iiuc they just changed to a new one). liquid uses “nakamoto consensus” aka a blockchain to keep track and agree on shared balance states

Lightning was shipped as the minimum viable product to scale tx thru-put and it succeeded at that. it did this with minimalist, 2-party design as consensus from 2-parties is the simplest case. this meant it could avoid tricky consensus questions and focus on privacy + throughput instead

shipping multi-party utxos at scale will require a solutions for managing consensus amongst stakeholders in the “shared utxo”; see Ark and already existing federations for examples of contending with this problem 🫡