Signer rejects orchestrators whose ticket recipient differs from their node address #1

The signer can't pay an orchestrator that runs with a separate hot key. POST /generate-live-payment requires OrchestratorInfo.address to equal TicketParams.recipient (signer/service.go#L360). go-livepeer lets an orchestrator sign with a node key while its tickets pay its registered address (-ethOrchAddr), so for these orchestrators the two fields differ.

This is common. On October 12 we tried four public orchestrators, and all four used a separate node key; the signer refused to pay each of them. It answered 400 incomplete or expired orchestrator payment params, although the params were complete and current, so the error doesn't point to the cause.

Why the check can go

Both fields arrive in the caller's OrchestratorInfo. A caller who wants a different recipient can set the address to match it, so equality says nothing about who the orchestrator is. The chain checks that follow already use the recipient: validateTicketParams reads the payer's deposit and reserve with PayerFunds(payer, recipient) (signer/payment.go#L191).

Proposed change

eliteprox/node@00c483eacacaef9f067cdbfb3988b9e20163573d replaces the equality check with a check that the recipient is a non-zero, 20-byte address. Its tests cover a distinct, a zero and a short recipient, and confirm that the signed payment pays the supplied recipient. It also updates docs/http-api.md. The commit sits on top of an unrelated TLS change (eliteprox/node@ebff260); John can split it into its own PR.

Two questions

1. Signed payment state is scoped to OrchestratorAddress, the node key. With this change, a caller could reuse one state with a different recipient. Should the scope include the recipient?
2. Signed-ticket events report the node key as OrchAddress. Should they also carry the recipient, so accounting can attribute spend to the registered orchestrator?

Why we need it

The Network Engineering SPE build track pays public orchestrators through this signer. Until the signer accepts a distinct recipient, it can pay only orchestrators whose node key is also their registered address.