Add a Event::DiscardFunding event

[ariard]

If our counterparty goes offline during the funding sequence, before we send a funding_signed we should feedback an event to the user, signaling it's okay to abandon the funding transaction and recycle the inputs for another purpose.

Dependency: #948

Extension: add timers if we never receive funding_signed to yield a DiscardFunding event too.

[1nF0rmed]

I'd like to assign myself this issue

[TheBlueMatt]

Feel free to take it and run with it! Let us know if you have any questions or need pointers.

[1nF0rmed]

Sorry for the late update. I've been going through the lightning-rfc and lightning overall as when going through the funding_signed I found that I needed to understand the base better.

1. Regarding the DiscardFunding event itself, from my understanding, I would need to need to add a struct enum for the same in the following:
   https://github.com/rust-bitcoin/rust-lightning/blob/ce3a04ba1a3dc12dcbe7b5753d90b8076a8540bf/lightning/src/util/events.rs#L76
   am I correct?

2. And given that this event itself isn't documented in the RFC, we would have to define it's structure, is that right?

3. Regarding the extension aspect
   When the funding_created message is sent by the funder to the fundee, is that when we should start the timer or should we have a delay of some sort?
   The RFC doesn't specify any units of time for a timeout, with respect to the the funding_created message. So, please let me know if I need to refer some other specification or if that is something previously discussed?

[TheBlueMatt]

Regarding the DiscardFunding event itself, from my understanding, I would need to need to add a struct enum for the same in the following:

yes

And given that this event itself isn't documented in the RFC, we would have to define it's structure, is that right?

I don't think any of our events are "documented in the RFC", so, yes :)

When the funding_created message is sent by the funder to the fundee, is that when we should start the timer or should we have a delay of some sort? The RFC doesn't specify any units of time for a timeout, with respect to the the funding_created message. So, please let me know if I need to refer some other specification or if that is something previously discussed?

Yes, I'm not sure what the timer should be, but after maybe 144 blocks or so, we should probably just give up (almost all of our timers internally are block-based, as we do not assume access to a clock).

[1nF0rmed]

Thanks!
Do you already have a definition in mind for DiscardFunding? From my understanding, we would need to have:

• the temporary channel id
• funding transaction id

Let me know if I am missing something or if I have misunderstood

Yes, I'm not sure what the timer should be, but after maybe 144 blocks or so, we should probably just give up

Is the 144 blocks delay a constant of sorts in the codebase?

Also, would this be the method that would have to broadcast the event before sending funding_signed?
https://github.com/rust-bitcoin/rust-lightning/blob/de9fba82f233fa185e54e833c7faf9c6a0f2b670/lightning/src/ln/channel.rs#L1731

Given that it is already returning Ok like so:
https://github.com/rust-bitcoin/rust-lightning/blob/de9fba82f233fa185e54e833c7faf9c6a0f2b670/lightning/src/ln/channel.rs#L1799-L1804
should I add an event broadcast before it?

[TheBlueMatt]

Do you already have a definition in mind for DiscardFunding? From my understanding, we would need to have: the temporary channel id funding transaction id

You actually may want to include the full transaction as well, if we've received it from the user. That way the user could simply create the transaction and forget about it entirely, and can walk the list of inputs they'd used again when they receive a DiscardFunding event.

Is the 144 blocks delay a constant of sorts in the codebase?

It would be, I suggest it just because its a nice round number - one day.

Also, would this be the method that would have to broadcast the event before sending funding_signed?

That is where the funding_created happens, but not where we'd care about the event. We care about generating the event when a channel is being closed before having received the funding_signed. See #997 for the places where a channel may be closed. It may make sense to base your work on that PR, possibly refactoring that PR somewhat to process the event generation in a function that can also check if we need to generate a DiscardFunding event.