ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2023-02-23 📝 Original message: Good morning 10k1, > The ...
📅 Original date posted:2023-02-23
📝 Original message:
Good morning 10k1,
> 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.
Well then, it looks like the seeds trust that clients do not double-spend zero-conf channels, and thus is largely not interesting to me personally, as I prefer trust-minimized systems myself.
Likely you do, or will be forced to eventually do, some kind of gathering and validation of client information that would allow physical threat (e.g. possibility of lawsuit and imprisonment) to be imposed in case trust fails, as is typical in such systems.
> 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.
So let me see if I get this straight: the intended setup is that the 3 participants are 1 client, and 2 relays.
The 3-participant construction uses a 3-of-3 address between all 3 participants (2-of-3 would allow two participants to collude to steal money from the third participant).
Relays may be motivated to increase their uptime to as close as 100% as possible, but there is simply no way to have 100% uptime: accidents and unknown unknowns exist.
Indeed, I would point out that forwarding nodes on the LN, where all channels are 2-participant, have the same incentive to have uptime be as close to 100% as possible, because they get routing fees.
However, this may be acceptable.
Generally, "high reliability" would be 6 nines, i.e 0.999999 uptime.
If you have 2 relays, and you need both to be up in order to operate a single 3-participant system, you would degrade to slightly better than 5 nines, which may be acceptable.
But basically there is that, random "relays" on the LN network will still sometimes disappear or become disoperational, if you allow random plebeian relays on your network rather than those that have been specifically been allowed by you or your organization, you cannot really control their uptime very much, and you would suffer worse uptime issues than what LN already has.
That is why I brought up channel factories, it is just an explicit tesselation of your 3-participant channel into 3x 2-participant channels, I suggest considering that instead.
That way, even if one relay disappears, a channel with the other relay is still operational.
> 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.
I am unsure about the anti-sybilness here.
It is easy to generate an arbitrary LN node ID, you just pick 32 bytes from `/dev/urandom`.
If you are referring to the fact that you have to back channels with actual onchain funds, and using that as your anti-sibyl protection, take note that a pseudonymous identity is now attached to onchain funds.
Onchain coin tracking can remove the privacy you tried to get on your network because you are now using channels (and the UTXOs that back them) to track psuedonyms.
> 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.
Oh, you could look up some of the work Tamas Blummer and I speculated on, in using onchain funds as an anti-sibyl mechanism in an information-sharing network, search stuff like "defiads".
Regards,
ZmnSCPxj
📝 Original message:
Good morning 10k1,
> 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.
Well then, it looks like the seeds trust that clients do not double-spend zero-conf channels, and thus is largely not interesting to me personally, as I prefer trust-minimized systems myself.
Likely you do, or will be forced to eventually do, some kind of gathering and validation of client information that would allow physical threat (e.g. possibility of lawsuit and imprisonment) to be imposed in case trust fails, as is typical in such systems.
> 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.
So let me see if I get this straight: the intended setup is that the 3 participants are 1 client, and 2 relays.
The 3-participant construction uses a 3-of-3 address between all 3 participants (2-of-3 would allow two participants to collude to steal money from the third participant).
Relays may be motivated to increase their uptime to as close as 100% as possible, but there is simply no way to have 100% uptime: accidents and unknown unknowns exist.
Indeed, I would point out that forwarding nodes on the LN, where all channels are 2-participant, have the same incentive to have uptime be as close to 100% as possible, because they get routing fees.
However, this may be acceptable.
Generally, "high reliability" would be 6 nines, i.e 0.999999 uptime.
If you have 2 relays, and you need both to be up in order to operate a single 3-participant system, you would degrade to slightly better than 5 nines, which may be acceptable.
But basically there is that, random "relays" on the LN network will still sometimes disappear or become disoperational, if you allow random plebeian relays on your network rather than those that have been specifically been allowed by you or your organization, you cannot really control their uptime very much, and you would suffer worse uptime issues than what LN already has.
That is why I brought up channel factories, it is just an explicit tesselation of your 3-participant channel into 3x 2-participant channels, I suggest considering that instead.
That way, even if one relay disappears, a channel with the other relay is still operational.
> 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.
I am unsure about the anti-sybilness here.
It is easy to generate an arbitrary LN node ID, you just pick 32 bytes from `/dev/urandom`.
If you are referring to the fact that you have to back channels with actual onchain funds, and using that as your anti-sibyl protection, take note that a pseudonymous identity is now attached to onchain funds.
Onchain coin tracking can remove the privacy you tried to get on your network because you are now using channels (and the UTXOs that back them) to track psuedonyms.
> 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.
Oh, you could look up some of the work Tamas Blummer and I speculated on, in using onchain funds as an anti-sibyl mechanism in an information-sharing network, search stuff like "defiads".
Regards,
ZmnSCPxj