Good morning Ariel and Rene and list,
I have started to consider how best to attack the modified Luaces-Pickhardt
JIT-Routing, which reuses the same payment hash as the message to forward.
(In the case where JIT-Routing is used by the ultimate source of a payment, the
payment hash of the
Good morning list
I have been thinking about how JIT-Routing can allow the network to be more
private and scalable than it currently is today. Rene has mentioned that
JIT-Routing allows channel balance information to affect pathing decisions
without the source node being aware. I would take
Good morning list,
I have been thinking of JIT-Routing in the context of unidirectional channels,
as for example in Eclair Mobile.
Now of course unidirectional-only nodes as in Eclair Mobile cannot forward and
cannot be intermediate nodes.
However, as I pointed out in previous email, the same
Good morning Rene and Ariel,
> Hey everyone,
>
> I am glad the suggestion is being picked up. At this time I want to respond
> to two of the concerns that have been thrown in. I have some other comments
> and ideas but would like to hold them back so that we can have more people
> joining
Hello Rene, ZmnSCPxj, and list
I really like the proposal and I'm sure it's the correct way forward for
reducing payment failures and increasing privacy (through mitigating probing
based network analysis)
However I am concerned that this proposal could introduce a vulnerability to a
Good morning Rene and list,
Let us consider then the rule *when* a rebalancing would be beneficial to the
node.
The node is offered a fee amount (`offered_fee_amount`) for the forwarding.
It knows that, under current channel states, it will definitely have to fail
and earn 0 fees.
If it
Good morning Rene,
The base idea is good at first glance.
However, let us consider this situation:
0.1 1.0
A - B
1.5 | / 0.5
|/
| /
| /
| /
|/
| /
| /
0.5 | / 0.75
