Proposal: Add the host's public key to the contract header

[lukechampine]

Proposal: Add the host's public key to the contract header

[lukechampine]

Further notes on "is this really necessary?"

First, we could theoretically get the host key by scanning the blockchain for the original contract ID. But for various reasons, this sucks. If the contract never hit the blockchain, you're out of luck; also, the original contract only contains the hash of the unlock conditions, so you really need a contract revision (which reveals the host's public key), not the original contract. And if things are operating normally, there won't be any revisions on the chain until the contract is about to end.

Second, a more technical consideration: is the host key (contained in the revision) really in danger of being corrupted? Even though we're overwriting the revision, we're overwriting the host key with the same bytes each time. (The position of the host key within the file does not change.) So shouldn't it be impossible to corrupt the key?

I tried researching the semantics of write/pwrite in this case, but couldn't find anything conclusive. My gut says that in practice, there's no danger of the host key being corrupted. But my gut also says that, in the absence of specified behavior, we should assume that some filesystem out there will corrupt the key. So in the interest of safety, the most responsible thing to do is to put the key in the header, where we can be confident it will never be touched by another write call.