pull down to refresh
332 sats \ 9 replies \ @WeAreAllSatoshi 9 Nov 2023 \ on: deleted by author bitcoin
Yes, each LN Addr provider service specifies a limit of chars. SN is 1000, WoS is 32 IIRC.
As pointed out in the original thread, it's over HTTPS so it's encrypted, but it's not "End to End" encrypted. In other words, it's encrypted over the network, but it's stored in plaintext at the service provider. Admins of the provider could easily see the notes.
it looks like you're a little confused about the differences between LN address memos and keysend messages.
Sphinx and Juggernaut do not use LN address, they use keysend. Keysend is a type of lightning payment in which the sender creates a payment preimage, uses it to lock up a payment for a recipient, encrypts the whole package (including, optionally, a message), and sends the encrypted blob to the recipient over lightning.
To routing nodes, a keysend payment looks like an ordinary payment, but it's a little weird "under the hood" because of something called reverse flow. In most lightning payments, the recipient acts first: he creates an invoice for the sender, shows it to him, waits for a payment blob to come in on lightning, and accepts the payment by revealing the preimage (aka the proof of payment) that locks up the money.
With reverse flow, the sender acts first, there is no invoice, the sender already knows the preimage to the payment (because he created it), and therefore there is no proof of payment. And these weird "keysend" payments can also include a message. Which is, you know, neat.
Keysend messages are end to end encrypted. As the name suggests, they are encrypted to the recipient node's public key. Only the node with the private key to that public key can read them. (Though the sender also knows what the message says because he created the message. That's why there are 2 "ends" in the term "end-to-end encrypted.")
As for a character limit, the upper bound is 1300 bytes (i.e. 1300 characters), but it's never actually that high. Lightning nodes refuse to forward onion packets that are bigger than 1300 bytes, but a lot of that is "used up" by things other than the keysend message. E.g. every hop in the route adds more bytes to the size of the onion packet because you need to include instructions for that "hop" about who to forward the payment to.
So the "maximum" size limit is variable and never exceeds 1300. The "practical" size limit depends on how long your route to your destination is, but basically the smaller the message, the better. You can't even say something like "just stay under 500 bytes and you'll be good." It's possible for a lightning payment to have so many hops and so much extra payment data stuffed in that there is simply no room left for a keysend message. But the shorter your route, and the less complicated your payment is, the more room you have for a keysend message -- it can fill up however much room is "left over" in your payment.
reply
I'll take this opportunity to also answer the OP's questions.
Is there any limitation in terms of the amount of characters that can be included in these messages?
I answered this above. Several hundred characters fewer than 1300, but the exact amount is variable and can be as low as 0 if your payment is very complex.
Could LN potentially serve as a complete substitute for emailing and messaging apps such as WhatsApp or Signal?
Most things are possible if you try hard enough, including this. But I personally think it's a bad idea. Lightning is designed for sending a specific kind of message: instructions for creating and redeeming HTLCs off-chain. You can use this system to send other kinds of messages, but most tools don't do a job well if they weren't designed for it, and lightning wasn't designed for routing general-purpose text messages. So even though it can do it, I recommend using something that was designed for that.
Is any of you using the apps i mentioned above in the post?
No. IMO they are neat as technical demos but not smart to actually use. Sending messages over the internet is a solved problem with many, many excellent implementations. If you want to know one I am currently interested in, look into briarproject.org.
What are the drawbacks of using LN for messaging purposes?
Every message is "attached to" a lightning payment which adds a point of failure to each message: if your payment fails, your message fails too. If your wallet runs out of money, your messages won't send. If your recipient uses an LSP, and they are down, your message fails. If your recipient uses a phone wallet and isn't online when you send the message, your message fails. (Well...zaplocker sort of fixes this...but not all the way. And not very well. A "real" async payments spec might fix this someday though.) In my day to day payments, lightning payments fail all the time, and I often have to keep switching wallets til I find one that works. It sucks, but since it's basically the only decentralized option, we keep working to improve it.
But this would be terrible with text messaging, where there are hundreds of excellent alternative options. Also, though it depends on your threat model, for most people it's NBD if a text message they created passes through one or more centralized intermediaries, as long as the end users' client software is responsible for encrypting and decrypting the messages. For most people, a threat model that allows corporations to know who you are messaging is not so bad if that corporation doesn't know what you told them. So I am fine with recommending tools like Telegram and Signal as better alternatives to Sphinx and Juggernaut.
How reliable are this messages when it comes to security and privacy?
They suffer from the limitations of lightning's privacy model, which you can read about here. Here is a key sentence from that essay: "Some of the top nodes on the network are capable of analyzing the source and destination of 50 to 72% of payments." If lots of people used lightning for messaging, those nodes could probably identify senders and recipients 50 to 72% of the time. (Not, however, message contents.)
If your threat model is one where you feel it is important to hide message "metadata" (that is, who is messaging whom, and when), it's useful to compare that with alternatives like Signal and Telegram. On those platforms, the companies who host the servers can read your metadata, but not your message contents (assuming you use their encryption features). And they sometimes reveal your metadata to their business partners and to governments. Do you trust them? If so, use them. Do you feel like a personal target? If so, look for something better.
If you're looking to lightning as a possible replacement, consider this: a government or corporation can request information from "top nodes" just like they can request information from Telegram or Signal. But "top nodes" might not comply. If they do, that doesn't necessarily mean you're just as worse off. Telegram can give them reliable information on who you're messaging 100% of the time you use them.
If you use lightning, the best they could get is 72%, with some limitations and caveats due to the imperfection of the heuristics (read the whole analysis I linked to earlier for more details). Also, since you pick your route, you can opt not to route through top nodes, further limiting the information available to them.
But can you do better than 50 to 72%? Earlier I mentioned Briar, which relies on the tor network as a transport and encryption layer for user messages. Tor's sends all traffic through at least 3 hops and therefore assumes that at least 1/3 of nodes on the network are "honest," i.e. not run by malicious entities. These assumptions improve for tor hidden services, which pass through 6 hops and are end to end encrypted. If only 1/3 of nodes are run by dishonest people, as tor assumes, and if you select hops at random, the chance that your message will pass through 6 randomly selected dishonest nodes is very small 1/729. (3 to the 6th power is 729)
So yeah, consider using a tor hidden service for messaging if you really need to hide who you're talking to. Briar makes this easy.
reply
Can I just say how much I appreciate your detailed, thoughtful, and consistently kick-ass responses to questions like these? I learn so much from reading them. Gracias.
reply
super is really super
reply
I can: by counting the says he raked in 😂
reply
Does this mean that LN is somehow centralized? Or am I just confused? 🤦🏾♂️
reply
You sound a little confused
Lightning is highly decentralized, i.e. no one controls it
Nonetheless, it has imperfect privacy
Some of its privacy issues come from the popularity of large LSPs like Acinq and Voltage
Popularity and centralization are not the same thing
Centralization entails control but popularity does not
Acinq is popular and has a lot of insight into where many lightning payments come from and go to, because -- due to how popular their routing node is -- they are involved in a lot of those payments
But they do not control their users' funds, so they are not a central point of failure for lightning, i.e. they do not (and cannot) make lightning centralized
If Acinq stopped existing, lightning would continue as normal -- but a lot of people would be sad because they couldn't use Phoenix Wallet and the Acinq routing node anymore
reply
I haven’t read all of your response yet but thank you for clarifying, I was definitely referring to LUD-12 comments, not keysend messages. Thank you!
reply
This is too technical for me😂😂
I'll have to read 8x to fully understand a word you're saying😂😂, it's amazing how there's always something new to learn in Bitcoin💯
reply