@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.
@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
createonionfrom #3260Alternatively, a new
createtrampolineonionrpc call specific for trampoline onions could be added.For decoding, similarly we could add a
decodetrampolineonionrpc call or a more general one.I guess at some point, we will want to hide this behind
sendtrampolineonionor 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.