André Vitor de Lima Matos
André Vitor de Lima Matos
On last bullet point, about `RefundTransfer`, maybe we can rely on the `SecretReveal` => `Secret/Unlock` from a mediator/initiator to next mediator on the failed routes with refunded transfers to stop...
Thank you, @hackaugusto for your thoughts. But I think some misunderstandings happened, and would like to get your position on the clarifications below: > meaning they can be sent as...
> This is not specific to the delivered and processes messages, how does this implies these messages incur latency? incur latency because they're unneeded. any unneeded message incur latency, given...
@rakanalh good points. Yes, your understandings are mostly right, only some clarifications: > The way to stop this message from being retried is to either have the transport also check...
> IMO the Processed message IS part of the protocol and it's meaning: the node has received and accepted the previous message. You're right, currently they're part of the protocol....
If this "side effect instead of Processed" isn't accepted, a **compromise** would be to use this approach at least for getting rid of `Delivered` messages, which already compose 50% of...
I'm working on a small PoC for the `Delivered` part I want to address for this limited scope of this issue, to guide me on commenting and better describing this...
On the workshop, it was decided on the following approach for now: - [ ] Remove requirement for signature in the `Delivered` message; the signature can be kept being done...
Issue was edited to include current proposal, after talks with @hackaugusto . This shouldn't take too long, but could break compatibility (it can be kept with a little more work...
This was done in the Light Client, and in a backwards compatible manner. Here's how we got it working - LockedTransfer, Unlock, LockExpired, RefundTransfer: BP-messages are retryed until receiving the...