Jim McDonald

> The `(target_root, epoch)` tuple uniquely identifies the list of proposers for `epoch`, whilst the `(shuffling_pivot_root, epoch)` uniquely identifies the shuffled list of attesters for `epoch`. I assume you mean...

> Is there a reason that `current_target_root` and `previous_target_root` are added to the proposer and attester duties? I assumed that `current_target_root` would be for proposer duties and `previous_target_root` for attester...

Batching GETs is the best option for most of the items. We do have a couple of requests that use POST instead of batched GETs, as it's in the validator...

A few generic questions: - should `/eth/v1/lightclient/snapshot/` only take a block root, or should it allow the more generic block ID? Rationale behind this would be to allow simple retrieval...

What happens if the validator's balance drops below 16 Ether? I don't see either `ExitedVoluntarily` or `ExitedSlashed` describing this state. I'm also a little concerned that the names quite verbose...

Regarding the states, I'm fine with Paul's states except for the last three. As we do not know how withdrawals are going to occur we don't know if there are...

> ...I would advise against the "done" or "finished" states... We can leave the group state at "withdrawal", then.

Do we want to proceed with this? The API is basically out of the door in its V1 state now that mainnet is launched, and although there are benefits to...

Requiring a smart contract appears to be overkill for this. Is there an issue with querying a node for the relevant address balance before and after the proposed block, and...

Personally I have no requirement for proposer payments to be fed through a smart contract for accounting purposes. As mentioned in the specification, there is overhead and smart contract risk,...