Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Features: Creating and decoding trampoline onions #3391

Open
jtimon opened this issue Jan 3, 2020 · 0 comments
Open

Features: Creating and decoding trampoline onions #3391

jtimon opened this issue Jan 3, 2020 · 0 comments

Comments

@jtimon
Copy link
Contributor

jtimon commented Jan 3, 2020

@t-bast is working on bolt for trampoline payments in lightning/bolts#654

He was also working on an implementation for eclair in ACINQ/eclair#1220
Since it has been merged, presumably eclair will only need some polishing and to keep up with the changes to the bolt until it is accepted.

He suggested that, apart from reviewing lightning/bolts#654 , perhaps a good way to help the bolt move forward would be implementing it in another implementation, for example, c-lightning.

Instead of trying to fully implement it in a single step, he suggested that an interesting first step could be to simply add the ability to encrypt/decrypt trampoline onions (without adding the code that does the relaying / path-finding). It seems that's what he did in ACINQ/eclair#1209

To solve this issue, we would need to simply add that ability.
The encryption would take a list of trampoline nodes (a trampoline route), a route to the first trampoline, and would return an encrypted onion.
The decryption would take such an encrypted onion and do two layers of decryption to extract the trampoline data.

For creating the onion, one solution could be to modify createonion from #3260

Alternatively, a new createtrampolineonion rpc call specific for trampoline onions could be added.

For decoding, similarly we could add a decodetrampolineonion rpc call or a more general one.
I guess at some point, we will want to hide this behind sendtrampolineonion or similar.
Or perhaps we don't want to expose the decryption as an rpc call even temporarily.

EDIT: Here's my embarrassing first stab at creating trampoline onions: master...jtimon:createtrampolineonion
I still need to read and re-read many things, both bolts and code.

Any feedback welcomed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant