Scaling LN routing with Chaumian eCash
370 sats \ 13 comments \ @gd 18 Jan lightning
I’ve been lightly digging in to Cashu and Fedimint over the last couple of days and have been pressing myself to think of additional areas to make use of the eCash implementations.
So far, most of the applications seem to be around making it easier for users to transact more easily and private. It goes without saying that this is awesome.
I’ve been thinking about whether routing nodes might be able to make use of federated eCash between themselves as a kind-of L3 in order to facilitate LN routes between nodes which don’t have channels between them.
For example:
In the current world if we have 4 nodes (A to D) and want send a payment from one side to the other, we need a route to send that payment.
Route: A -> B -> C -> D
If there is no LN channel route between A and D, the payment will fail.
Instead of C having a channel open to D, what if it was part of an eCash federation where one of its federation counterparts can complete the route to D.
Route: A -> B -> C -> (ECASH FEDERATION) -> E -> D
This would allow C and E to settle balances with eCash and for E to pass the payment to D without having an LN channel connection with A or C.
An additional benefit might be that the liquidity that C has in the eCash federation can be outbound to ANY of the other federation members, rather than a single channel, whilst improving the privacy of all transactions that flow through it.
Has this concept been discussed much in the space? I can imagine it’s use to effectively hop across LN nodes, reducing payment path lengths and increasing connectivity.
write
preview
related posts
100 sats \ 3 replies \ @fanis 18 Jan
Interesting idea. I'll add we could preserve the atomicity of the route by adding another spending condition to the ecash that C sends to E, that is revealing the preimage.
What's nice is the rest of the route doesn't need to care about the fact that the payment goes through an ecash custodial mint. The risk is taken by E when it accepts to forward the payment in exchange of ecash tokens (a bit like a hosted channel can be used to route payments.
However, a major pain point is that if there is no channel between C and D (or C and E), the sender is unlikely to pick a route that goes A -> B -> C -> (ECASH FEDERATION) -> E -> D. So in the current state of Lightning this would only work if the ecash part happens at the end of the route (A -> B -> C -> (ECASH FEDERATION) -> D, so that the recipient (D) can add a routing hint in the invoice telling the sender (A) that there is indeed a path from C to D. But then, that's not really routing, but just using a Lightning Gateway (C) inside a chaumian mint.
reply
21 sats \ 2 replies \ @gd OP 18 Jan
Nice! Atomicity was one of the first additions I wanted to look in to.
I was also thinking about that pain point, it would likely require an upgraded routing method in order to use one or multiple federations along the route.
Couple of really interesting parts that I’m going to continue looking in to. I’m going to get a Fedimint up and running this evening to play around with.
Really appreciate your input!
reply
0 sats \ 1 reply \ @fanis 18 Jan
I was also thinking about that pain point, it would likely require an upgraded routing method in order to use one or multiple federations along the route.
What's interesting is the twi proposed alternative routing mechanisms that I know of would solve this pain point:
reply
0 sats \ 0 replies \ @gd OP 18 Jan
Aha- yes trampoline routing would make great sense for this
reply
0 sats \ 8 replies \ @nerd2ninja 18 Jan
I’ve been thinking about whether routing nodes might be able to make use of federated eCash between themselves as a kind-of L3 in order to facilitate LN routes between nodes which don’t have channels between them.
You know what would be better than this? An n-of-n multi-party channel.
Come on, read PeterTodd's reply to my post about how there's concerns over LNSymmetry not working well in untrusted environments and apply that level of detail of adversarial thinking to the things you come up with. You know about how, in an untrusted environment a 10 node multi-party channel could only be 2 actual people behind all of those nodes.
Think about the type of adversarial thinking it took to come up with the replacement cycling attack: https://www.nobsbitcoin.com/how-does-a-lightning-replacement-cycling-attack-work/ How might that affect what you've come up with?
E-cash federations require trust. Even the people promoting fedi-mints are only promoting it for people to support their local communities as in you know who the fedi-mint custodians are. Because if you don't know who they are, they could claim to be a fedi-mint and actually be 1 person with a multi-sig wallet.
https://thebitcoinmanual.com/articles/fedimint-federation/
These trust assumptions are:
Custody: The user must trust the Federation Guardians with custody of their funds, which introduces custodial risk. LN Pay: The user must trust “1 of n” Lightning Gateways to pay lightning invoices outside of the mint. LN Receive: The user must trust “1 of n” Lightning Gateways to receive lightning payments into the mint. Tx Execution: The user must trust a quorum of Federation Guardians to process transactions (deposit, redemption, swap, contract enforcement).
reply
0 sats \ 7 replies \ @gd OP 18 Jan
I’m not advocating for untrusted parties to form federations. I’m more so exploring the idea of trusted parties forming routing federations for greater network reach and higher liquidity efficiency between them.
reply
0 sats \ 6 replies \ @nerd2ninja 18 Jan
An n-of-n multi-party channel is still better in that case.
reply
0 sats \ 5 replies \ @gd OP 18 Jan
What benefits would the n-of-n multi-party channel give us over the eCash style?
reply
0 sats \ 4 replies \ @nerd2ninja 18 Jan
Well its n-of-n (so no signatory collusion) with unilateral exit. Even if you assume a trusted multi-party channel, if almost all members of the multi-party channel became uncoorperative (died, went offline, what have you) you can still exit (get your funds out) without them. Even if you assume a pretty bad multi-party channel where you're using current day mainnet and with no justice transactions (because you trust so much) the unilateral exit is still relevant.
There is a multi-party channel proposals that do have justice transactions by the way, just want to put that out there: https://eprint.iacr.org/2018/918.pdf
AND when you build all of that out, you don't have to build an interoperability layer or convince the network to use a different routing mechanism like you guys were talking about in another comment
reply
0 sats \ 3 replies \ @gd OP 18 Jan
Hmm, my understanding is that the all signatories must sign all transactions in a n-of-n. So there is no unilateral exit and a single signatory has the ability to censor a given transaction. Isn't that what gives immunity to signatory collusion?
reply
0 sats \ 2 replies \ @nerd2ninja 18 Jan
I'm going to blow your mind for a minute. You know lightning channels? Just the normal ones we make with CLN or LND. Those are n-of-n (2-of-2) multi-sigs with unilateral exit.
Its because you can exit by yourself if you follow certain rules, but the other party (or parties in the case of multi-party channels) have recourse if you try to exit using an old state.
Yes, 1 party can become uncooperative (this is where the all signatories must sign all transactions part comes in) and thereby prevent a payment from going through, but you can exit without them and them reopen with everyone except them later, and you can exit without their signature.
"Using Lightning Factories, there is no risk for a counter party going unresponsive, since the factory can be closed uncooperatively with a small locktime ∆t to allow for disputes, instead of a period of time representative of 29 the lifetime of the factory"
This paper I linked for you is just one of many proposals for multi-party channels and it does have a concept of justice transactions
reply
300 sats \ 1 reply \ @gd OP 18 Jan
I understand very well how 2-of-2 lightning channels work, but 2-of-2 doesn't have risk of signatory collusion.
Lightning Factory details are interesting— thanks for the paper.
view replies