l0k1 [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2023-02-19 to 2023-02-23
💬 Posted a total of 2 messages
📚 Participated in the following categories: Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 13:12:44

- reply

📅 Original date posted:2023-02-23
🗒️ Summary of this message: Indranet will use low-sized channels to transport small payments and maintain channel balance. The LN instance will be part of the Indra service.
📝 Original message:
The use case is related to my work on Indranet, where channel sizes are going to be a lot lower than normal because they only have to transport very small payments (in the hundreds of sats at a time) and maintaining balance of the channels to keep them as much available as possible, the LN instance itself will be part and parcel of the indra service (as well as a node, either neutrino or probably bitcoind).
The semi-automated creation of channels between relays on the network requires 3 an optimal 3 channels so as to optimise for ensuring that messages are at least 3 layers, 4 layers including our special nodes we are calling "seeds" that clients open zero conf, one way channels to for, again, very small balances, in the tens of thousands of sats kinda size. Ideally, they are always 4 layers deep and may need to be given hints based on network topology that can be provided by Indra itself.
It is not a concern if a peer out of the 3 is not available temporarily, the path will just be retried with a different path, the chances of cheating are pretty low and this element of our network's LN mesh is going to be very large - hopefully, and with all nodes having at least 3 peers with channels to them. The payments need to be relatively low latency, and the proportion of nodes that might be congested or fallen offline compared to the whole network is usually going to be very small because relays that are not running are not making the relay operator money - the payments between peers are not going to have fees to further simplify route selection, and because the real income of the relay is not from routing the tiny payments but from users requesting relay services, and premium services that have a higher cost than network-internal.
My aim in opening up this discussion relates not to the general use case of routing payments but the use of LN as an anti-spam anti-sybil rate limiting scheme, as an adjunct and integral part of a separate peer to peer network system, in this case an anonymising relay system that creates source routed onions, similar to LN payments, but with more advanced structures that enable bidirectional traffic to act as a network tunnel that enables client side anonymity directly, and I'm currently working on adding a scheme for rendezvous-free bidirectional anonymity.
This kind of application couldbe relevant for many different kinds of monetised p2p networks, Nostr, for example, could use something like this to create a general mechanism for users to anonymously pay other relays to host and deliver content for designated user identities, and would enable this to become a distributed service rather than having users need to depend on the trustworthiness of relays.
~ l0k1
------- Original Message -------
On Thursday, February 23rd, 2023 at 10:55, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - stalker.loki at protonmail.ch - 0x0AC723EB.asc
Type: application/pgp-keys
Size: 665 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230223/5541d843/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230223/5541d843/attachment.sig>

2023-06-09 13:12:44

- reply

📅 Original date posted:2023-02-19
🗒️ Summary of this message: Opening Lightning Network channels between three nodes instead of two could have advantages such as better balance and liquidity, more efficient routing, and easier pathfinding. A negotiation protocol for pre-arranging a not-yet-mined opening transaction for a three-way channel could also be possible.
📝 Original message:
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 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.
~ l0k1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - stalker.loki at protonmail.ch - 0x0AC723EB.asc
Type: application/pgp-keys
Size: 665 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230219/0ae8526b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230219/0ae8526b/attachment.sig>

2023-06-09 13:12:44

- reply

2023-06-09 13:12:44

- reply

2023-06-09 13:08:11

- reply

📅 Original date posted:2023-02-23
📝 Original message:
The use case is related to my work on Indranet, where channel sizes are going to be a lot lower than normal because they only have to transport very small payments (in the hundreds of sats at a time) and maintaining balance of the channels to keep them as much available as possible, the LN instance itself will be part and parcel of the indra service (as well as a node, either neutrino or probably bitcoind).
The semi-automated creation of channels between relays on the network requires 3 an optimal 3 channels so as to optimise for ensuring that messages are at least 3 layers, 4 layers including our special nodes we are calling "seeds" that clients open zero conf, one way channels to for, again, very small balances, in the tens of thousands of sats kinda size. Ideally, they are always 4 layers deep and may need to be given hints based on network topology that can be provided by Indra itself.
It is not a concern if a peer out of the 3 is not available temporarily, the path will just be retried with a different path, the chances of cheating are pretty low and this element of our network's LN mesh is going to be very large - hopefully, and with all nodes having at least 3 peers with channels to them. The payments need to be relatively low latency, and the proportion of nodes that might be congested or fallen offline compared to the whole network is usually going to be very small because relays that are not running are not making the relay operator money - the payments between peers are not going to have fees to further simplify route selection, and because the real income of the relay is not from routing the tiny payments but from users requesting relay services, and premium services that have a higher cost than network-internal.
My aim in opening up this discussion relates not to the general use case of routing payments but the use of LN as an anti-spam anti-sybil rate limiting scheme, as an adjunct and integral part of a separate peer to peer network system, in this case an anonymising relay system that creates source routed onions, similar to LN payments, but with more advanced structures that enable bidirectional traffic to act as a network tunnel that enables client side anonymity directly, and I'm currently working on adding a scheme for rendezvous-free bidirectional anonymity.
This kind of application couldbe relevant for many different kinds of monetised p2p networks, Nostr, for example, could use something like this to create a general mechanism for users to anonymously pay other relays to host and deliver content for designated user identities, and would enable this to become a distributed service rather than having users need to depend on the trustworthiness of relays.
~ l0k1
------- Original Message -------
On Thursday, February 23rd, 2023 at 10:55, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - stalker.loki at protonmail.ch - 0x0AC723EB.asc
Type: application/pgp-keys
Size: 665 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230223/5541d843/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230223/5541d843/attachment.sig>

2023-06-09 13:08:11

- reply

2023-06-09 13:08:10

- reply

📅 Original date posted:2023-02-19
📝 Original message:
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 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.
~ l0k1
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publickey - stalker.loki at protonmail.ch - 0x0AC723EB.asc
Type: application/pgp-keys
Size: 665 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230219/0ae8526b/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230219/0ae8526b/attachment.sig>

2023-06-09 13:08:10

- reply