Do not let user try recovery if one block left

[pythcoiner]

Closes #1102 and resolve @kloaec issue where 1 block recovery path was displayed recoverable even if tx not confirmed.

[nondiremanuel]

For the moment I assigned it to v7 since as we were discussing yesterday it is not strictly required to have it immediately (it is a behavior that should not be "regular" Liana wallet usage)

[pythcoiner]

updated wording as offered by @jp1ac4 on discord:

[nondiremanuel]

Some minor comments:

• Can we make "path" singular when there is only one recovery path available?
• For the same reason, when there is 1 recovery path available, "select one" is not very precise. Maybe we should use a more general "please select"
• Is "will be" correct in this case? Why not "x recovery path(s) is/are available"?

Also, was the green bar below the sentence already present? I didn't get it last time I tried iirc.

[pythcoiner]

Some minor comments:

• Can we make "path" singular when there is only one recovery path available?
• For the same reason, when there is 1 recovery path available, "select one" is not very precise. Maybe we should use a more general "please select"
• Is "will be" correct in this case? Why not "x recovery path(s) is/are available"?

i'll do this

Also, was the green bar below the sentence already present? I didn't get it last time I tried iirc.
no, i added it at screenshot time!

[pythcoiner]

[nondiremanuel]

Great thanks! The only nit that I notice remaining (not part of this change but I just noticed) is the fact that "can recover X coins" should be singular (coin) when the coin is 1. We could maybe use this PR to correct also this nit.

[pythcoiner]

[jp1ac4]

Checking again the original issue, I'm wondering if the problem was that the coin that had a recovery path available at the next block was still unconfirmed (see #1102 (comment)). The createrecovery command only considers confirmed coins.

[pythcoiner]

Checking again the original issue, I'm wondering if the problem was that the coin that had a recovery path available at the next block was still unconfirmed (see #1102 (comment)). The createrecovery command only considers confirmed coins.

You right i guess we were both (Kevin and I) testing w/ a 1 block recovery timelock, i'll look for a way to handle this edge case.

[pythcoiner]

i've added a new recovery arg to remaining_sequence() instead in order to handle the edge case

[darosior]

A 1-block relative locktimed transactions cannot be included in the same block as its parent. Only transactions valid in the next block can be broadcast on the network. That's the reason why createrecovery only considers confirmed coins.

[nondiremanuel]

Moving this and the relative issue to v8 since as per team discussion we won't be able to properly review and test it given the close deadline.