2023 Jan 31
Onion messages
Main question: so the point of route blinding is to conceal the recipient’s info right. What information is there to conceal when routing just a normal onion message, like an invoice request? To provide their half of the blinded route, the recipient has to directly communicate with the sender, so why does the sender have to route the onion message?
- However for something like an invoice request, what’s the point of routing that?
What is the point of routing a message if there is no state that needs to be kept (e.g. updating HTLCs) along the route?
They include a blinded route for the recipient to reply with??
If recipient reveals how many hops they are from the blinding point node, after a couple messages to the same person, would they reveal who they are? Knowing that you’re 2-3 hops from two distinct points could narrow down the options quite a bit if an attacker is looking for it? (I guess how would they know it’s from the same person?)
To discord: Confused about onion messages/blinded routes: what is the reason for creating a blinded route for a message when a recipient already has to directly communicate to the sender to send their blinded path? In that case why doesn’t the sender just send the message directly? I’m mainly thinking of something like an invoice request or some message that doesn’t really concern the nodes it’s routed through
Ok got some clarification:
blinded routes are communicated over a QR code or some other communication channel outside the lightning network, so the recipient is not directly communicating with the sender, and thus the recipient’s identity and nearby peers are concealed. note: “peers” here means just anyone a lightning node is connected to for communication is general, messages in general (i.e. gossip) are forwarded along these normally.
In the future, to prevent people spamming onion messages, these peers will likely be limited to channel peers + some sort of rate limiting.
Got some feedback from review on PR - rust macro pat identifier pretty cool
Played around with Phoenix wallet today. Really impressed with the UX. Besides having to understand a bit about lightning, the UX was honestly amazing.
Building with LDK:
Let’s just build a node and see what I run into.
For on-chain wallet, let’s use BDK, and for on-chain data let’s use bitcoin core + electrum server?
Build from scratch but have ldk-sample open for when you want to use default implementations such as
FileSystemLoggerStuff I’m running into
Rewatching this:
Always-online problem has a bunch of tricks but none really solve it completely because they usually rely on the fact that you end up being online fairly frequently, but that is not always going to work. Async payments basic description: node tells sender when they’re online. Look into PTLCs!
Watchtowers don’t work for HTLCs (i.e. if someone delays and broadcasts an HTLC to the chain, a watchtower would need to know about your upstream/downstream channels + any payments you’re routing in order to redeem the payments by watching on-chain for a preimage but they don’t do that) they are only for revocation punishment
The data required for a watchtower (or just node needing to punish revocation) grows unbounded as a channel continues forward. Eltoo solves this by only requiring a constant size piece to data.
Review: anchor outputs are to allow child-pays-for-parent to update fees when channel counterparty disappears.
Enter pinning attacks: your channel counterparty broadcasts their commitment transaction with CPFP but with low fees, and you’d like to broadcast your commitment transaction with higher fees but Bitcoin core isn’t smart enough to realize to replace this (yet…Gloria’s work fixes this!).
Sike! There’s another problem. As an anti-DoS limit, Bitcoin Core has a concept of “no free relay” meaning you have to pay 1 satoshi/vByte to replace a transaction, essentially paying for the validation compute you incurred. This means your counterparty can broadcast an enormous child transaction, screwing you over.
- Gloria’s work fixes this again! Special tx v3 basically says this package (connected txs) is able to be replaced if it’s in this specified format.
Lightning currently (and eltoo) relies on the fact that you will be able to broadcast a transaction on-chain within a certain period of time. But block space is scarce, what if everyone’s broadcasting at the same time? Some people must lose money. This is a long-term concern, no great solution for it currently. For the time being, don’t open/use channels with people you don’t somewhat trust.
Routing is hard. In discussion whether rebalancing is zero-sum (just pushes payment towards other people and makes it hard for them to route) and if payment flows are inevitably difficult and need some other solution.
- Good amount of nodes on the network (club net smth..?) are not well maintained and make routing hard as well.
Privacy is hard because clustering is probably going to beat everything you have, and even if many of your off-chain payments are unknown once you broadcast then clustering will find your utxos again and more.
Channel jamming is also a thing: someone sends a bunch of HTLCs, and just waits for their expiry - locks up liquidity to cause more difficulty routing (or even prevent entirely for some time). Great research done recently into this, but not resolved yet.