specs
specs copied to clipboard
filecoin-project
'ChangeWorker' method needs to be delayed
Since we use the worker key to sign blocks, any change in this address represents an entirely different probability set for block production. I believe snow white mentions this attack.
We should delay a change in the worker key by at least K (the randomness lookback). I think double that is probably a good idea, in case people try to fork off and mine their own chain where they win more.
As for the specific mechanism, i'd like to avoid having to have two method calls to change the worker key (StartKeyChange and FinalizeKeyChange). So maybe we can tie it to PoSt submission somehow?
I'll sleep on this and come up with something tomorrow.
Yes! I believe it's a key part of the design, and what they mean by robustly reconfigurable committee. Specifically, they call it adaptive key selection attacks. Their solution I think is pretty simple, namely select committee kappa blocks before the random seed. So they get the committee 2kappa rounds back, and the seed kappa back (the "two-lookback mechanism" that led me down the k, l path which we've thankfully moved somewhat away from).
Agreed that double is the right place to start. Is there anything else worth considering as pertains to "lookahead" or VDFs... Not that I can tell.
Yeah... Maybe some sort of process whereby a key change is instantaneous but seeded with randomness drawn 2k rounds back?
@sternhenri I think youre looking at the wrong part of the problem. The point is that when creating the election proof, I need to use a key thats been committed to the chain for some number of blocks.
I think the easiest way to do this is to have 'ChangeWorker' set a 'key change' field on the miner that gets changed to 'pending' on the next post submission, and then actually takes effect on the post submission after that.
Sorry, I'm unfortunately caching back in to this, and don't quite understand my prior point facepalm.
That said, I still hold that your new key should not kick in until far beyond hereto unknown randomness. Ie if you change your key in round X, that key should only be used in generating electionProof starting at round X + 2*k (with k the randomness lookback for ticket sampling in leader election).
Why couldn't we just track key changes over time, as in keep some sort of meta userID and you change associated key, thereafter, you simply use key from 2k blocks back as part of generating electionProof.
(be gentle with me :b)
Changing the worker address introduces complications for the deal protocol. In order to arbitrate a payment channel or deal, a client presents a deal signed by the miner (which was hitherto not present on chain). If the miner's key changes after signing the deal, the client still needs to be able to arbitrate.
@sternhenri your original comment sounds like a solution to me. It exactly commits a worker key to the chain for some number of blocks before an election as @whyrusleeping is asking for. Constraining the update is more complicated and I don't understand how it wins us anything over that.
