> Finally, can you elaborate a bit on this fragment of the BIP that describes
> a "short cut" when a specific signers is meant to send their nonces last:
>
> > Second, if there is a unique signer who is supposed to send the pubnonce
> > last, it is possible to modify nonce generation for this single signer to
> > not require high-quality randomness
>
> My reading here is that if there's a signer that will always send their
> nonce last (possibly the responder to an LN funding attempt or a server for
> a non-custodial service like Loop), then they don't actually need to
> generate real randomness, and can just fully specify all the new optional
> arguments? If so then this may end up really simplifying the implementation
> of certain protocols since that last party doesn't (?) need to worry about
> their nonces as long as all the other (?) parties are using strong
> randomness?

I believe this was added in response to an email that a co-worker and I sent to Jonas. The idea originated because one of our signers would have a difficult time tracking, restoring, and securely deleting secret nonces across a signing session, so what was important was that the signer not have to retain state, rather than that they not have to provide their own randomness. The result is that the signer also doesn't need to provide randomness though.

The important property of the last signer's nonce is that any variation in any other party's nonce, or other values that contribute to the challenge, must uniformly randomize the last signer's nonce. The sentences following the one you quote describe exactly how achieve this, particularly:

* Optional arguments become required

* extra_in argument must be composed of all other parties' nonces

These modifications ensure that if and only if the partial signature will be exactly equal will the same nonce be used in a subsequent signing session.

Best,

--Brandon