Modify SignerCommand::Sign type to not sign blocks with taproot

[hstove]

Right now, the SignCommand::Sign type takes a block and a is_taproot boolean flag. The newly added SignerDB doesn't differentiate between taproot or schnoor block signatures, which can lead to issues. We either need to update SignerDB to add the is_taproot flag, or just remove the ability for these block signature commands to use taproot. My understanding is that the latter is better, because we won't be using taproot signatures to sign blocks.

[xoloki]

Nakamoto will not sign with taproot, but sBTC will.

It seems more forward looking to fix signer DB to support this.

[hstove]

Yeah I do follow that reasoning, but when signing for sBTC, will the type need a block field? Am I wrong that it would make more sense to have types like SignCommand::SignBlock(block) and SignCommand::SignTx(tx)?

[netrome]

Yeah I do follow that reasoning, but when signing for sBTC, will the type need a block field? Am I wrong that it would make more sense to have types like SignCommand::SignBlock(block) and SignCommand::SignTx(tx)?

Yeah I think that makes more sense. In sBTC we'll sign BTC transactions and not Stacks blocks as the Nakamoto signer does.