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 🫡

ahem

which covenants do you speak lady?

what i speak against on it is that it is source routed and that's baked into the HTLC payment transfer design and that's the reason it has weak liveness

no, lightning does not need a consensus algorithm, it is pure two party, peer to peer

on which planet do you live milady?

have you ever studied distributed systems theory?

i guess not, you worked for Blockstream

Reply to this note

Please Login to reply.

Discussion

No replies yet.