Atomic Multi-Path Payments and Private Channels - some thoughts \ stacker news ~bitcoin

Atomic Multi-Path Payments and Private Channels - some thoughts

4375 sats \ 8 comments \ @l0k18 13 Jan 2023 bitcoin

I am not sure how it came to be that I only hear people on social media talking about Bolt 12, and how AMP somehow isn't talked about very much, such that I never encountered a mention of it.

AMP provides both the common payee issued invoices as well as sender initiated payments in the case that the receiver has advertised their node public key.

AMP payments don't get stuck. They either go through, or they fail very quickly, and they can carry payments between two points so long as there is parallel paths that exceed the capacity required in sum.

I would appreciate it if someone would explain to me, why there is this idea you encounter in a lot of places that advertising your node's public key is supposedly a security risk.

The reason why I dispute this is because anyone can run a node and find this out, as well as the channels and channel sizes of the node. Aside from the channels that are not advertised, private channels.

Lightning wouldn't work at all if the p2p network wasn't gossiping these keys to everyone.

What kind of attacker doesn't know this???

It is possible to even not advertise your LN node at all, run private channels to nodes that are otherwise public channel connected, and issue invoices that contain routing hints to get back to your node.

I would suggest that if someone wants to really protect the security of their LN they run all their channels this way and issue invoices from an IP address that is not the same as the LN node, via proxy/VPN connections between the app server and the LN node.

In this way, only the node selected as the last hop that goes across the private channel to you reveals key and IP address, something buried deep under layers of onion encryption.

The thing that prompted me to make this post was this: Why is everyone talking about Bolt 12 and nobody seems to know about AMP? I already covered the false security of not allowing keysend/AMP payments above.

Are the majority of plebs really that clueless they have zero concept of threat models and attack surfaces in p2p networks? Seems like a deficiency that someone should be addressing. Saying a public p2p node identity key is a security risk to give to humans is just ridiculous. Security by obscurity is not secure to anyone motivated to poke around.

Besides this, the lack of general awareness of sender side initiated payments seems to me like you all are missing out on half of the utility of LN. Streaming payments. Recurring payments. Subscriptions.

We here at Indra are going to be using sender initiated AMPs as it's the only way for clients to spontaneously and anonymously pay relays for traffic sessions, and the beautiful thing is that it's so fast that it can be automated and in the same time as a Tor node opens channels - every time - Indra will be able to acquire enough sessions with relays that you never wait again.

I have a bit of a habit of seeing some technology and thinking of a way to use it that nobody else has, and for me it's the most natural use case but somehow thousands of people don't see it. And then almost always, not long after I start talking about it, everyone learns about it and then it finally starts to become normal.

I dunno about you but the number of business opportunities that involve recurring, fast, small payments are myriad. They allow accountless usage of services, you simply pay, and then reveal the preimage and they deliver.

view all related items

2435 sats \ 0 replies \ @Snyke 13 Jan 2023 freebie

AMP payments don't get stuck. They either go through, or they fail very quickly, and they can carry payments between two points so long as there is parallel paths that exceed the capacity required in sum.

I'm afraid this statement is wrong: HTLCs get stuck when the node currently processing it stops responding, independently of how the sender and recipient have negotiated the preimage / payment_hash.

What is true is that a part can be re-attempted without having to wait for the HTLC to settle, but only until the last part has been sent. The last part essentially being the XOR of all prior parts, leading to the preimage, and that can't be changed, since now both attempts could end up being claimed, causing the sender to overpay by the amount of that last part. The same is possible with sender-mixins (also called stuckless payments), but without that special case for the last part (each part requires the sender to reveal a secret after the recipient confirms receipt so no guessing if a part has arrived or not, and the sender will refuse to reveal more secrets than necessary to fulfill the payment, i.e., no extra parts that can still confirm).

That's all for the payment process however, the bigger problem is that channels with stuck HTLCs may end up being closed because the refund timeout is approaching. Neither AMP nor stuckless payments do anything for that situation.

400 sats \ 3 replies \ @TonyGiorgio 13 Jan 2023

The only thing AMP solves is the atomicity of spontaneous payments. Otherwise it's almost exactly like keysend. As another poster mentions, you're incorrect that they can't get stuck.

You're also confusing security with privacy re pubkeys. These resources explain in depth the lack of receiver privacy and what is and can be revealed.

https://abytesjourney.com/lightning-privacy/ https://lightningprivacy.com/en/introduction

you all are missing out on half of the utility of LN. Streaming payments.

Have you heard of v4v? You don't need AMP for it and it's quite popular.

10 sats \ 0 replies \ @l0k18 OP 13 Jan 2023

There is inherently no privacy for a Lightning node and their HTLCs, and all public nodes learn these things in the network gossip, and the protocol requires it. There can be privacy for nodes on either end running private channels - sending side can have privacy initiating over private channels and receiving side can have privacy if - and only if - they isolate their LN node from the place from where the users receive the invoices (this is why many nodes are using Tor I believe). The path hints are only in the deepest layers of the onion and are not visible to the sender, who only sees the first hop out from their position.

In my project, the state of channels will be largely automated, and it must be possible for the sender to initiate payments, and these payments are going to be quite small most of the time so stuck payments will resolve in most cases soon enough to not be a problem.

It is not necessary for these automatically created channels to charge fees, because the payment itself includes a margin on top to compensate the relay operators. Our gateway/seed nodes will charge routing fees as our mechanism for getting a small share of the fees that will go into development/maintenance costs.

I am unfamiliar with v4v, I see many words bandied around on the interwebs and the more I see them and the less clear their meaning the more I am suspicious. I am also sus on nostr, and just this evening learned about the identity of current and past funders of the LND project, which gives me definite pause for thought.

0 sats \ 1 reply \ @l0k18 OP 13 Jan 2023

AMP does enable payments where a single path would not be able to carry the payments though. Seems to me like this would go some way to increasing the maximum size of payments that can be carried on the network.

10 sats \ 0 replies \ @TonyGiorgio 13 Jan 2023

That's true, forgot that keysend doesn't do multiple paths.

12 sats \ 2 replies \ @DarthCoin 13 Jan 2023

It is possible to even not advertise your LN node at all, run private channels to nodes that are otherwise public channel connected, and issue invoices that contain routing hints to get back to your node.

Something similar I am trying to achieve with some tests I've done and I am still trying to promote other node operators should try it in these 2 scenarios:

I would want that more people will try to put together these "uncle Jim" scenarios. Also using Blixt mobile node (pure LND) and OBW (Immortan) is a good way to add more privacy on your LN txs.

132 sats \ 1 reply \ @l0k18 OP 13 Jan 2023

Interesting stuff. Yes, private channels and isolating the location invoices are relayed to users from the server also makes a lot of sense.

In our plans for Indranet we have also discussed the subject of Indra routing channels as well. Indranet's initial MVP is only client side privacy, being derived partly from the HORNET protocol, the other end of the circuit is a public Indra node with LND running on it. This would enable not only private channels but private channels with one end being completely hidden.

Another idea we have relates to how we are going to implement the p2p network seed nodes in Indranet. This will enable us to interpose and collect a kind of toll for payment traffic on Indranet as clients will open a few channels to our seed nodes, eliminating the complexity on the client side, while providing a revenue stream to keep us afloat and continuing to improve the system.

During the discussion in which my colleague proposed this idea I also pointed out that effectively relay nodes have the option to not connect their channels to the broader LN network and only some nodes will have channels out to the rest of the network. They only have to connect to the Bitcoin main net.

As a relative beginner with LN, one of the things that struck me as problematic is it seems like most LN providers require quite large channels, certainly larger than average third world LN node runners would be able to do. I am not even in the third world but I don't have enough sats to open channels with my Zap wallet, which I find really annoying. Indra's channels will be quite small, and this also leads in to why we need to use AMP - because sometimes there simply won't be a wide enough channel even though a relay has enough on their channels.

(as an aside, one of the things that I think Indra will provide is a relatively self balancing channel graph because of the intentional randomisation of selection of relays in client circuits, which would also combine with AMP to lower the channel balancing labor cost).

I am subscribed to the main LN dev mailing list, also, and it's a recent topic that has come up, how to handle payment processing where nodes are intermittently online.

Practical use cases like these are what is going to make Lightning Network into a thing.

Outside of that, another privacy feature that Indranet will enable is relaying on chain transactions far distant from the location of the private keys that are used in them.

It is one of the things about Monero that is a real, tangible advantage over Bitcoin - the fact that you can't correlate a transaction to a location or key. Sure, the transaction can be seen emanating from your IP address, but spending it or correlating it to the rest of your keys is basically infeasible.

So far, LN doesn't really enable this, but I think with techniques like you are discussing, especially the private banks, people will be able to hold their sats while reducing the risk of racketeers using spying nodes to capture traffic flow and locating users with balances big enough to be worth mounting a physical attack. This is a key thing we want to eliminate. In every bull market there is news stories about people being extorted to give up their wallets. I hope this will become a thing of the past as we get Indra up and running.

11 sats \ 0 replies \ @DarthCoin 13 Jan 2023

Very interesting. This is why I came to SN, to find this kind of information and discussions. not bullshit crap about shitcoins and price...