We have multiple workstreams (mainly #5452) presently where a TenureExtend is created, even if a new BTC block has a winning miner. As part of testing for this feature, we've learned that there is an edge case where, if there are two bad sortition winners in a row, the "good" miner cannot TenureExtend a second time, because they can't write to the miners StackerDB contract. This is because the miners StackerDB only allows writes from the current and previous sortition winner.
I think there are a few potential paths forward for this:
Modify make_miners_stackerdb_config to allow either the sortition winner OR the miner who was able to successfully TenureExtend the previous block to write to this slot.
Make a new StackerDB, like miners-v2, which allows N previous sortition winners to write to it. This technically can run into the same issue as described here, even if N was something high like ~10.
We have multiple workstreams (mainly #5452) presently where a
TenureExtendis created, even if a new BTC block has a winning miner. As part of testing for this feature, we've learned that there is an edge case where, if there are two bad sortition winners in a row, the "good" miner cannotTenureExtenda second time, because they can't write to theminersStackerDB contract. This is because the miners StackerDB only allows writes from the current and previous sortition winner.I think there are a few potential paths forward for this:
make_miners_stackerdb_configto allow either the sortition winner OR the miner who was able to successfullyTenureExtendthe previous block to write to this slot.miners-v2, which allows N previous sortition winners to write to it. This technically can run into the same issue as described here, even if N was something high like ~10.