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

debug PoP #33

Closed
wants to merge 1 commit into from
Closed

debug PoP #33

wants to merge 1 commit into from

Conversation

SebastianElvis
Copy link
Member

No description provided.

@lesterli
Copy link
Collaborator

@SebastianElvis Did the finality provider have the registration issue with the babylon-private under the base branch?

We failed to register the finality-provider to Babylon with the error: InvalidArgument desc = invalid proof of possession: failed to verify pop.BtcSig

Registering Babylon finality provider...
service injective.evm.v1beta1.Msg does not have cosmos.msg.v1.service proto annotation
Error: rpc error: code = Unknown desc = failed to register the finality-provider to Babylon: rpc error: code = Unknown desc = rpc error: code = Unknown desc = failed to execute message; message index: 0: rpc error: code = InvalidArgument desc = invalid proof of possession: failed to verify pop.BtcSig [cosmos/[email protected]/baseapp/baseapp.go:1012] with gas used: '47242': unknown request
Usage:
  fpd register-finality-provider [fp-eots-pk-hex] [flags]

Aliases:
  register-finality-provider, rfp

Examples:
fpd register-finality-provider --daemon-address 127.0.0.1:12581

Flags:
      --daemon-address string   The RPC server address of fpd (default "127.0.0.1:12581")
  -h, --help                    help for register-finality-provider
      --passphrase string       The pass phrase used to encrypt the keys

Global Flags:
      --home string   The application home directory (default "/home/finality-provider/.fpd")

Whoops. There was an error while executing your fpd CLI 'rpc error: code = Unknown desc = failed to register the finality-provider to Babylon: rpc error: code = Unknown desc = rpc error: code = Unknown desc = failed to execute message; message index: 0: rpc error: code = InvalidArgument desc = invalid proof of possession: failed to verify pop.BtcSig [cosmos/[email protected]/baseapp/baseapp.go:1012] with gas used: '47242': unknown request'make[1]: *** [start] Error 1
make: *** [start-deployment-finality-gadget-integration-op-l2-demo] Error 2

@SebastianElvis
Copy link
Member Author

We failed to register the finality-provider to Babylon with the error: InvalidArgument desc = invalid proof of possession: failed to verify pop.BtcSig

Have been discussing with @gitferry about this and this is a known bug. The bug is as follows

  • upon createFinalityProviderRequest it will create a new secret key in the key ring. The user specifies a keyname in the request. The key is derived from various source of entropy, including keyname. The secret key is used as BTC SK and Babylon SK, and determines the FP's Babylon addr. The PoP will be signed over this Babylon addr.
  • however, when starting the FP program it uses the key with key name specified in config. The PoP will be verified where the corresponding Babylon addr in config is treated as signer.

If the keyname in config does not match the keyname specified by the user who sends createFinalityProviderRequest , PoP verification will fail.

A temporary workaround is to always use the fp name given in config file when creating finality provider.

A proper fix will be more complicated. My idea was as follows but there could be simpler ways

  • Let keyring in the App struct to only manage BTC keys but not Babylon keys. The Babylon client is already parsing the private key to a keyring in memory so this has no issue
  • Make create-finality-provider a one-time thing, e.g., after invoking it once, subsequent invocations to this will return error directly. For example, it can be revamped to sth like fpd initThis is in line with the decision of removing the support of multiple FP instances.
  • The handler of create-finality-provider should get Babylon address from Babylon client, rather than creating a new key in the keyring

@lesterli
Copy link
Collaborator

@SebastianElvis which issue can we follow on this bug fix?

@SebastianElvis
Copy link
Member Author

This is not tracked yet, #22 is relevant though. Will create an issue for this

@SebastianElvis
Copy link
Member Author

#34

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

Successfully merging this pull request may close these issues.

2 participants