pull down to refresh
1 sat \ 3 replies \ @k00b 7 Oct 2021 \ on: [RFC] Shroom Node v0.1 released bitcoin
Awesome! Great to see an open source project doing lightning transport.
I haven't messed around much with lightning transport yet. What do you see as the benefits of using lightning as transport vs other things? What are the limitations of lightning as transport as it stands?
I'm particularly curious because I want to decentralize SN and the hard part is providing p2p Sybil resistance absent centralization - I have a high level design I think will work but I'm considering alternatives. One way would be to use lightning as transport which has a natural cost to message sending, but for programmatically generated p2p messages I suspect it'd be prohibitively expensive.
Thanks k00b, good questions.
LN as transport is something I'm exploring. I want to use it as much as possible, but I think for some use cases I might have to use it only for signalling and transfer actual data over something else, like a websocket.
On the one hand, it has some interesting benefits, like:
- you only need a pubkey to contact someone (they could change IPs, switch over to tor and back, etc -- still reachable via same pubkey)
- "data bound to payment" = cost of sending = native spam prevention
- "data bound to payment" = receiving data implies receiving a payment = economic incentive to offer services (for which the inbound messages can be "requests for service")
On the other hand, limitations:
- latency: you can't quite "stream data" over LN (maybe not yet? or maybe its not necessary, a side-channel can be used for low-latency requirements?)
- bandwidth: same as above
- payloads are persisted (indefinitely?) as invoice metadata in the LND DB = could eventually clog the DB
- makes one-to-many scenarios harder to implement (a chat group where each message = N payments, one to every other group participant, makes no sense)
- same for many-to-many
Will probably end up using it as a hybrid (transport in some cases, signalling in others).
Don't think this can help much with decentralizing SN though.
reply
Hey k00b, I hear BOLT12 plans to support messages without payments.
Onion Messages Using the same onion mechanism we use to send payments, without the actual payment part. You can (and people do!) use fake payments to send messages today, but it's 3x slower and consumes far more resources on each hop. https://bolt12.org
Might be useful for decentralizing SN.
reply
I didn’t realize that. Sounds like AMP/keysend I guess. Still, I’m not sure Lightning transport is the way but it’s interesting to consider.
reply