multisigner

[Evanfeenstra]

1. use the broker/looper sequence to verify on the signer side that no VLS message was skipped. Each message should increment by one.

   • replace the BUSY AtomicBool with an AtomicInt that stores a global sequence number. Remove the sequence from the individual Channel structs.
   • the signer needs to keep track the current sequence number
   • What if broker restarts???? Sequence will restart at 0...
   • if the sequence is 0 OR jumps more than 1, then the signer needs to do the reconnect dance to sync the state, and then finally process the VLS message
   • broker should only talk to one signer at a time!

2. Broker should send the VlsMuts(SignerMutations) to all other connected signers whenever it receives it from one

[irriden]

@Evanfeenstra upon further thought, it seems to me we still need that BUSY atomicbool to make sure that handle_message is done by only one thread at a time right ?

We want a spinlock and a global counter.

[Evanfeenstra]

@Evanfeenstra upon further thought, it seems to me we still need that BUSY atomicbool to make sure that handle_message is done by only one thread at a time right ?

We want a spinlock and a global counter.

i guess so, makes sense

[Evanfeenstra]

from devrandom

the [LSS] state is only used for two things:

- when first building the Handler / Node / channels
- when deciding what changed when running an API call
- Right now for a multi-signer setup you would need to rebuild the root handler completely

as a reminder, we didn't design for multi-signer (yet)

[irriden]

On the second point - is that the signer computing the "state diff" to send back to the LSS server?

[Evanfeenstra]

On the second point - is that the signer computing the "state diff" to send back to the LSS server?

exactly

[irriden]

Section 1 addressed in #95