Transcoder Approved Address Lists

Nobody has claimed this yet.

A thought came up when working on the TLS proposal and reviewing https://github.com/livepeer/LIPs/issues/4.

TLS root certificates are meant to be kept offline and safely under lock-and-key, while day-to-day work is done with intermediate certs. Less handling is required of the root cert, which minimizes the space of things that could compromise the keys. The ability to rotate, revoke and issue new certs is also an important operational safeguard.

The more I think of it, we should build similar safeguards for the transcoder's keys, which could potentially be very valuable targets. Currently, the transcoder's bonded address is "hot" : it is required for calling `reward`, `claim`, `verify`, `withdraw` and so forth. Any compromise of the transcoder's key is game over for the operator: they cannot replace (or even rotate) their keys without a re-bonding campaign.

To solve this, transcoders could maintain a set of authorized addresses [1] that are allowed to submit certain transactions on behalf of the the transcoder. Most transcoder function signatures would need to take the transcoder's address, for example `reward(transcoder_address)` [2]. We could still have [separate withdrawal addresses](https://github.com/livepeer/LIPs/issues/4).

Altogether, this would allow operators to campaign for a transcoder whose private key existed only on a Ledger, and keep that Ledger in a safe deposit box.

There are also scalability benefits. Transcoders could run multiple physical nodes for redundancy, load balancing, [geoip routing](https://github.com/livepeer/LIPs/issues/6), and independent operations without relying on a single, central node. Any damage caused by the compromise of a single node would also be limited to that node. Compromised nodes could immediately have their keys revoked by removing their address from the authorized list.

[1] Rather than maintaining an explicit list of addresses on-chain, HD-type addresses might help here, but that looks like it might be more expensive in terms of the additional metadata and computation needed to verify the root address.

[2] Actually, the `reward` function itself could probably be called by anyone, rather than an authorized caller. But other functions, eg `claim`, require more care.

Start by reviewing the proposal's discussion of authorized addresses and the listed transcoder functions: reward, claim, verify, and withdraw. Read the linked TLS proposal and LIP-4 for related key-management decisions. The issue needs an agreed design and scope before implementation can be considered complete.

Written by the indexing model from the issue text.