debug PoP

[lesterli]

@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/cosmos-sdk@v0.50.6/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/cosmos-sdk@v0.50.6/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]

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]

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

[SebastianElvis]

This is not tracked yet, https://github.com/babylonlabs-io/finality-provider/issues/22 is relevant though. Will create an issue for this

[SebastianElvis]

https://github.com/babylonlabs-io/finality-provider/issues/34