This is why I think delay encryption could be the endgame solution when the cryptography is ready. It has the advantages of threshold crypto without the honest majority assumption.
My point here is that you need to include something which ties it to a specific block at the point you create the hashed commitment to prevent it being copied and used elsewhere. Since the block hash is not available when the commitment is created that is why I suggest using the slot number.
I’m still confused by this. If we’ve seen Block A and are waiting for the next block, there is no way to know what will be proposed in the next slot unless you are the builder / proposer (even they don’t know until all txs are unsealed) - there may be no block at all. Do you mean that we know that Block B will contain certain unsealed transactions?
I think this could be unsafe, which I discussed in an argument for reorg safety.
Consider we allow a one block delay on inclusion, so the constraint (sealed tx) is posted in block A, then we allow one extra block B, before the unsealed transactions are included in block C. A malicious proposer of block B could potentially frontrun the unsealed transactions by delaying the reveal of their block and attesting to it in private. Now the unsealed transactions will be revealed and block C will be built on block A. Now the malicious proposer reveals block B which contains frontrunning transactions and attempts to reorg out block C. Now the unsealed transactions can be included in a future block C’ built on block B: the unsealed transactions have been frontrun.
I’d be interested to analyse further how viable this attack is, but my current opinion is that the unsealed transactions should only be included in the next block after the constraint is posted with no delay.