cnct: decode onion for incoming contest resolver#3594
Conversation
joostjager
added
incomplete
joostjager
changed the title
joostjager
force-pushed
the
resolver-onion-decode
branch
from
677cf2d to
9ef9187
Compare
joostjager
force-pushed
the
resolver-onion-decode
branch
8 times, most recently
from
b80d854 to
830acc4
Compare
|
Changed the design slightly to make sure we always parse the onion blob. Also if we didn't just restart. |
joostjager
force-pushed
the
resolver-onion-decode
branch
from
830acc4 to
5dc51b3
Compare
joostjager
changed the title
joostjager
force-pushed
the
resolver-onion-decode
branch
from
5dc51b3 to
4e5aac0
Compare
cfromknecht
left a comment
cfromknecht
left a comment
There was a problem hiding this comment.
Latest version LGTM! Nice refactor on resolver supplements, only some minor nits
|
would be nice to get this in before #3644 |
joostjager
force-pushed
the
resolver-onion-decode
branch
2 times, most recently
from
d7b9f79 to
4c8f0cf
Compare
There was a problem hiding this comment.
how could we lock in such an HTLC?
There was a problem hiding this comment.
crash before we reached processRemoteAdds in the link
There was a problem hiding this comment.
So we will lock in the HTLC, crash, restart and forget about it? Shouldn't we either forward or cancel it in that case?
Just seems a bit dangerous to ignore a locked in HTLC without returning any error here...
There was a problem hiding this comment.
We can forget about it, because the onion payload is invalid. In the off-chain flow nothing would have happened either.
There was a problem hiding this comment.
if the payload is invalid we would have canceled the htlc back offchain. now that we are on chain we can't cancel (or decode the payload and figure out what needs to be done) so we just let the incoming party timeout the htlc
joostjager
force-pushed
the
resolver-onion-decode
branch
from
4c8f0cf to
7bdcd0d
Compare
joostjager
force-pushed
the
resolver-onion-decode
branch
3 times, most recently
from
9f536a1 to
710819a
Compare
joostjager
force-pushed
the
resolver-onion-decode
branch
2 times, most recently
from
257e2cd to
13891fe
Compare
This change prepares for accessing the onion blob from a resolver.
With the introduction of additional payload fields for mpp, it becomes a necessity to have their values available in the on-chain resolution flow. The incoming contest resolver notifies the invoice registry of the arrival of a payment and needs to supply all parameters for the registry to validate the htlc.
joostjager
force-pushed
the
resolver-onion-decode
branch
from
13891fe to
0d7119a
Compare
|
@cfromknecht re-requesting review, as I got a rebase that was a bit more involved. I think it is better to be a bit more cautious with this sensitive part of the code. |
|
|
||
| // decodePayload (re)decodes the hop payload of a received htlc. | ||
| func (h *htlcIncomingContestResolver) decodePayload() (*hop.Payload, error) { | ||
|
|
4 participants
Also for on-chain resolution, we may require access to the onion payload. An example of this is the resolution of an mpp shard. We need the mpp fields in order to properly offer the htlc to the invoice registry.