Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SigningMode incorrect when registering a staking script #167

Open
SebastienGllmt opened this issue Aug 9, 2023 · 3 comments
Open

SigningMode incorrect when registering a staking script #167

SebastienGllmt opened this issue Aug 9, 2023 · 3 comments
Assignees

Comments

@SebastienGllmt
Copy link

Staking credentials can either be a Staking Key or a Stake Script

For our use-case specifically, we want to a register a stake pool owned by a hardware wallet where the staking credential is a Plutus script (so that rewards are distributed to Milkomeda through the smart contract)

However, it looks like this case is missing here. It never checks if the staking credential being registered is a Plutus script and so it incorrectly sets the mode to TransactionSigningMode.ORDINARY_TRANSACTION

The mode should be TransactionSigningMode.PLUTUS_TRANSACTION if using a Plutus reward script (setting aside that there is no way to know just from a script hash whether or not it's a native script or a plutus script)

@janmazak janmazak self-assigned this Aug 9, 2023
@janmazak
Copy link
Collaborator

janmazak commented Aug 9, 2023

The original design ignored stake pools managed by scripts (I vaguely remember a discussion on this topic and that was the conclusion).

The signing mode does not necessarily truly describes the intent of the transaction (since there's no way to find out what the script is from its hash). The only point of signing mode is to tell the HW wallet how to verify/validate the tx and what to do about certain UI flows. This is done explicitly when used through ledgerjs. For hw-cli, it just guesses, and kind of takes the "lowest possible" signing mode (e.g. when there are no Plutus/Babbage elements in the tx, it uses ORDINARY_TRANSACTION).

I have to understand your use case more thoroughly to know if it can be solved without changes in HW wallets. (Or if we should change something at all. An obvious choice might be a hw-cli option to set the signing mode explicitly.)

  1. Do you have a tx that should be signable with hw-cli, but is not?
  2. Do you have a tx that is signable with hw-cli, but the HW wallet UI displays stuff in an incorrect / misleading way?

@SebastienGllmt
Copy link
Author

Do you have a tx that should be signable with hw-cli, but is not?

Yes, this is the case. We just ended up signing the registration tx using a software wallet since there wasn't really a security benefit of signing the script registration with a HW so this issue isn't blocking us from doing something. Just letting you know about this issue

@fallen-icarus
Copy link

I just encountered this issue. I was trying to register two staking scripts and pay for the deposits using a hardware wallet payment address. However, I managed to trick the hardware wallet into using the PLUTUS_TRANSACTION mode by specifying a collateral input (even though no scripts were being executed). The UI displayed things unhelpfully, it displayed the bech32 script hash (which I didn't know and therefore couldn't verify) instead of the bech32 stake address I was registering, but it worked for my needs.

While staking scripts are currently not executed when being registered, I believe this is changing in Conway which means collateral inputs will be required to register staking scripts post HF. So the incorrect signing mode may fix itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants