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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
