Improve sentinel voting script

[EggPool]

The sentinel voting script proved to be a useful tool for people with many in-cycle verifiers.

However, it's not fail-proof and real-world use shows that many times, a significant part of the votes issued that way did not make it to the chain.
Since there is no verification mechanism, the user has no feedback on the missing votes, has to check by other means and can't re-issue just the missing votes.

Other tools - like Nyzocli mass vote tool https://github.com/EggPool/NyzoCli/blob/master/MassVote.md - handle that in a more usable form but require a one time install of third-party code.

This is a proposal to improve core sentinel voting script and have it more efficient and user friendly.

Efficiency:
in sendSignatures, the script does forge a signature for every managed verifier.

nyzoVerifier/src/main/java/co/nyzo/verifier/scripts/CycleTransactionSignScript.java

Line 173 in 1dcaabe

for (ManagedVerifier verifier : managedVerifiers) {

However, only in-cycle can vote for cycle tx.
On regular sentinels - that handle both in-cycle and out-of-cycle verifiers - this is a significant waste of transactions.
Since that function also has the cycleNodes list data, it should be straightforward to forge transaction for in-cycle verifiers only.

Effectiveness:

nyzoVerifier/src/main/java/co/nyzo/verifier/scripts/CycleTransactionSignScript.java

Line 179 in 1dcaabe

// Make a message to send the transaction to the next 5 verifiers in the cycle.

Every message is then sent to the next 5 verifiers. But the timestamp comes from ClientTransactionUtil.suggestedTransactionTimestamp() that uses a 3 block offset.

nyzoVerifier/src/main/java/co/nyzo/verifier/client/ClientTransactionUtil.java

Line 26 in 1dcaabe

// The offset is calculated based on the difference between the open edge and predicted consensus edge, with a

So, if cycle moves as intended, 2 blocks only remain. With many messages, the cycle could move faster.
keeping 5 blocks window, it could be more effective to use +1 to +6 or +2 to +7 instead of +0 to +5

Verify and retry:
Once the messages are sent - and no matter if they were indeed sent or failed - it's supposedly done.
Messages could fail (temporarily overload target) or the target could not be able to embed the transaction in its block.
As a result, some messages do not make it.

A failsafe could be the following, adjusting the whole workflow:

• generate a hash list of votes to emit - only from in-cycles -
• repeat:
  -- guess timestamp, sign and forward these messages, stored expected blocks in the hash list
  -- wait for the cycle to freeze the last expected block
  -- fetch expected blocks, remove from hash list the votes that were embedded
• until the list is empty

Current scattering on NCFP-3 votes shows how the current process is not reliable enough.
This would ease for sure a lot of the voting pain users are experiencing, and release pressure from Discord admins trying to motivate users to vote and vote again day after day.

[orisica]

True, voting for cycle transactions feels like a lottery, you never know if your votes will go through or not.