Accusal attack during Transfer R&R process

[adamgall]

In transfer workflow, very first step involved Old Arch giving that secret shard data to a New Archaeologist.

What if the New Archaeologist is just trying to screw over the Old Archaeologist? They could very simply take that data, and submit an accusal to the contract.

Boo, bad design.

There needs to be a way to tell the system: A transfer is bout to happen, but before it gets finalized, any accusals against the Old Arch are invalid.

[sethhrbek]

Could this transfer indication only be valid for "x" number of blocks (or a timestamp interval)? Otherwise an archaeologist could block an accusal in perpetuity.

[adamgall]

Could this transfer indication only be valid for "x" number of blocks? Otherwise an archaeologist could block an accusal in perpetuity.

Great point. Yes, seems like some kind of timeout would be needed here.

[sethhrbek]

Another issue --

After transfer, the original archaeologist could now accuse the new archaeologist, since they still have access to the original unencrypted shard.

We tried to work through some incentive mechanisms to avoid this (such as some of the original archaeologist's bond staying locked), but can't come up with a good solution.

Another option would be to update the accusal to only be successful if m shards are submitted to the accusal function (enough shards to reveal the secret), or keep the same "single hash" submission which would indicate the caller has access to the outer layer private key. This would prevent a single archaeologist from successfully accusing after transferring (unless m = 1).

[adamgall]

Another option would be to update the accusal to only be successful if m shards are submitted to the accusal function (enough shards to reveal the secret)

At face value, I like this option.