ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2023-02-23 📝 Original message: Good morning 10k1, > ...
📅 Original date posted:2023-02-23
📝 Original message:
Good morning 10k1,
> Currently, LN primarily uses 2 of 2 multisig channel, though I have heard people talk about opening channels in more complex transactions than 2 of 2 multisigs.
>
> Thinking through all the topology and number theory aspects of it, I think that if channels were mostly between 3 nodes instead of 2, there could be some big advantages:
>
> - Channels can advertise which node has the lowest balance, helping with balance of channels, and overall liquidity. There would need to be vague enough thresholds to define when to even bother mentioning this, I imagine something like under 10% remaining on one versus the other two would be sufficiently anonymous.
>
> - A node with 3 channels attached to it can be considered as completely connected, and can basically route to 10 different next hops for only 3 opening transaction fees.
>
> - The time cost is basically doubled - two nodes for a channel means request and two messages between the peers to propagate their PSBT channel state, 3 nodes to a channel means 1 request and 6 messages to settle a new payment, which each node in the trio can more or less dispatch two messages at the same time, so, 3 message cycles, or average around 600ms from anywhere to anywhere on the internet.
>
> - The channel's lowest balance could be one-bit boolean value publicly broadcast, meaning that peers selecting hops for a payment route can easily avoid adding to a channel stuck on one side. Pathfinding is a real hassle in the current design of LN. It is hard to navigate in the dark, but if you can sense the distance to the nearest object you can orient easily.
>
> The magic of tesselation gave us lightning fast 3d raster based 3d modeling, and is based on the infinite tesselation of triangles. Oh, there is 4 points possible, but it really just complicates things. I'm pretty sure that the new Unreal 5 "nanite" engine only works with uniform 3 point surfaces, at least, it definitely looks like that based on the 4 color map versions that show the polygons. And anyhow, a "rectangle" is just two adjacent triangles, why bother with this extra, extraneous nonsense of calling two polygons with a common axis "squares".
The problem with N > 2 participants in an offchain updateable cryptocurrency system is that if any participant is offline, then the entire system cannot update and the online participants can only back out using an expensive onchain procedure, or wait until the missing participant is online again.
(Use of k-of-n here would allow any quorum of `k` to steal the funds of the `n - k` remaining participants, so security-wise you should really go for n-of-n multisignatures)
If any arbitrary participant has a probability `P` of being offline at any particular moment, then the probability of the entire system being not updateable is `1 - (1 - P)^N`.
Crucially, because of real-world considerations, the probability `P` cannot be 0 (though this can be made arbitrarily near 0, but then the cost of doing so would have to be paid by *somebody*).
Further, if the offchain updateable cryptocurrency system has N participants, if one participant is offline, then N - 1 participants have their funds forcibly locked.
Thus we should multiply the probability of an individual system (N-participant "channel") being non-operational with the number of participants who suffer having their funds locked.
With 2-participant channels, the probability of any single channel being non-operational is at its lowest and the number of affected counterparties is also at its lowest.
This is why Channel Factories are even a thing.
--
Basically:
* A channel is just a sub-class of offchain-updateable cryptocurrency systems.
* An offchain-updateable cryptocurrency system must be hosted by another cryptocurrency system, such as a blockchain.
* An offchain-updateable cryptocurrency system does *not* require activity on its hosting system in order to update its state.
* An offchain-updateable cryptocurrency system can be hosted inside another offchain-updateable cryptocurrency system.
* The outer offchain-updateable cryptocurrency system is hosted directly by a blockchain (a blockchain only requires a physics system with entropy in order to be instantiated).
* The inner offchain-updateable cryptocurrency system is hosted on the outer one.
The outer hosting system can host multiple inner systems.
* The outer offchain-updateable cryptocurrency system is N-of-N where N > 2.
* Each inner system is 2-of-2.
* The outer offchain-updateable cryptocurrency system is the "channel factory".
* Each inner offchain-updateable cryptocurrency system is a "channel".
This provides a good balance of availability and efficiency.
* When a participant is offline, the outer system is non-operational, but each inner system deos not care.
Each inner system can update without activity on its hosting system, that is the point of offchain protocols.
So each 2-of-2 channel can update even if the hosting N-of-N channel factory cannot be updated.
* The blockchain only hosts a single N-of-N UTXO for multiple channels.
>
> The only other issue that is on my mind lately relating to LN is 0 conf channels. I hadn't thought of "channels" as being 2 dimensional, since they represent a midpoint between two other points. But a midpoint is an abstract term, not just a word used for 1D lines but also 2D and nD shapes.
>
> It seems to me like there could be a negotiation protocol to pre-arrange a not yet mined opening tx for a 3 way lightning channel, that could effectively lock in every party such that it can't wriggle out of the commitment. This just wouldn't be possible with a 2 way. It then wouldn't matter a bit how big the fee was since the parties are already in consensus and have the ability to back out at any moment.
You first need to get the 3 committed, and that is the rub here: it requires onchain activity to commit funds to any N parties, whether N=2 or N=3.
And that onchain activity will always be subject to reversal / double-spending unless confirmed deeply enough that we believe reorganizing the chain would be unlikely.
Basically: what are the inputs to the transaction that backs your 3-participant channel?
If any input can be signed by just one participant, then that participant can sign a different transaction spending that input in another way, then bribe a miner to include it in a mined block.
Thus, this fixes nothing: in order to get funds committed to the 3 participants, you need *some* confirmed transaction to commit those funds in the first place, and everyone still has to wait for that transaction to confirm, thus you cannot sidestep the confirmation-or-trust requirement.
Regards,
ZmnSCPxj
📝 Original message:
Good morning 10k1,
> Currently, LN primarily uses 2 of 2 multisig channel, though I have heard people talk about opening channels in more complex transactions than 2 of 2 multisigs.
>
> Thinking through all the topology and number theory aspects of it, I think that if channels were mostly between 3 nodes instead of 2, there could be some big advantages:
>
> - Channels can advertise which node has the lowest balance, helping with balance of channels, and overall liquidity. There would need to be vague enough thresholds to define when to even bother mentioning this, I imagine something like under 10% remaining on one versus the other two would be sufficiently anonymous.
>
> - A node with 3 channels attached to it can be considered as completely connected, and can basically route to 10 different next hops for only 3 opening transaction fees.
>
> - The time cost is basically doubled - two nodes for a channel means request and two messages between the peers to propagate their PSBT channel state, 3 nodes to a channel means 1 request and 6 messages to settle a new payment, which each node in the trio can more or less dispatch two messages at the same time, so, 3 message cycles, or average around 600ms from anywhere to anywhere on the internet.
>
> - The channel's lowest balance could be one-bit boolean value publicly broadcast, meaning that peers selecting hops for a payment route can easily avoid adding to a channel stuck on one side. Pathfinding is a real hassle in the current design of LN. It is hard to navigate in the dark, but if you can sense the distance to the nearest object you can orient easily.
>
> The magic of tesselation gave us lightning fast 3d raster based 3d modeling, and is based on the infinite tesselation of triangles. Oh, there is 4 points possible, but it really just complicates things. I'm pretty sure that the new Unreal 5 "nanite" engine only works with uniform 3 point surfaces, at least, it definitely looks like that based on the 4 color map versions that show the polygons. And anyhow, a "rectangle" is just two adjacent triangles, why bother with this extra, extraneous nonsense of calling two polygons with a common axis "squares".
The problem with N > 2 participants in an offchain updateable cryptocurrency system is that if any participant is offline, then the entire system cannot update and the online participants can only back out using an expensive onchain procedure, or wait until the missing participant is online again.
(Use of k-of-n here would allow any quorum of `k` to steal the funds of the `n - k` remaining participants, so security-wise you should really go for n-of-n multisignatures)
If any arbitrary participant has a probability `P` of being offline at any particular moment, then the probability of the entire system being not updateable is `1 - (1 - P)^N`.
Crucially, because of real-world considerations, the probability `P` cannot be 0 (though this can be made arbitrarily near 0, but then the cost of doing so would have to be paid by *somebody*).
Further, if the offchain updateable cryptocurrency system has N participants, if one participant is offline, then N - 1 participants have their funds forcibly locked.
Thus we should multiply the probability of an individual system (N-participant "channel") being non-operational with the number of participants who suffer having their funds locked.
With 2-participant channels, the probability of any single channel being non-operational is at its lowest and the number of affected counterparties is also at its lowest.
This is why Channel Factories are even a thing.
--
Basically:
* A channel is just a sub-class of offchain-updateable cryptocurrency systems.
* An offchain-updateable cryptocurrency system must be hosted by another cryptocurrency system, such as a blockchain.
* An offchain-updateable cryptocurrency system does *not* require activity on its hosting system in order to update its state.
* An offchain-updateable cryptocurrency system can be hosted inside another offchain-updateable cryptocurrency system.
* The outer offchain-updateable cryptocurrency system is hosted directly by a blockchain (a blockchain only requires a physics system with entropy in order to be instantiated).
* The inner offchain-updateable cryptocurrency system is hosted on the outer one.
The outer hosting system can host multiple inner systems.
* The outer offchain-updateable cryptocurrency system is N-of-N where N > 2.
* Each inner system is 2-of-2.
* The outer offchain-updateable cryptocurrency system is the "channel factory".
* Each inner offchain-updateable cryptocurrency system is a "channel".
This provides a good balance of availability and efficiency.
* When a participant is offline, the outer system is non-operational, but each inner system deos not care.
Each inner system can update without activity on its hosting system, that is the point of offchain protocols.
So each 2-of-2 channel can update even if the hosting N-of-N channel factory cannot be updated.
* The blockchain only hosts a single N-of-N UTXO for multiple channels.
>
> The only other issue that is on my mind lately relating to LN is 0 conf channels. I hadn't thought of "channels" as being 2 dimensional, since they represent a midpoint between two other points. But a midpoint is an abstract term, not just a word used for 1D lines but also 2D and nD shapes.
>
> It seems to me like there could be a negotiation protocol to pre-arrange a not yet mined opening tx for a 3 way lightning channel, that could effectively lock in every party such that it can't wriggle out of the commitment. This just wouldn't be possible with a 2 way. It then wouldn't matter a bit how big the fee was since the parties are already in consensus and have the ability to back out at any moment.
You first need to get the 3 committed, and that is the rub here: it requires onchain activity to commit funds to any N parties, whether N=2 or N=3.
And that onchain activity will always be subject to reversal / double-spending unless confirmed deeply enough that we believe reorganizing the chain would be unlikely.
Basically: what are the inputs to the transaction that backs your 3-participant channel?
If any input can be signed by just one participant, then that participant can sign a different transaction spending that input in another way, then bribe a miner to include it in a mined block.
Thus, this fixes nothing: in order to get funds committed to the 3 participants, you need *some* confirmed transaction to commit those funds in the first place, and everyone still has to wait for that transaction to confirm, thus you cannot sidestep the confirmation-or-trust requirement.
Regards,
ZmnSCPxj