PIP-23: Sign and verify message by public and private key account

[Ja7ad]

PIP-23: Sign and verify message by public and private key account

[Ja7ad]

@b00f @kehiy @ambersun1234 Please review this PIP for accepting to implementation.

[kehiy]

@Ja7ad @b00f

I think these small changes were for Ethereum and Bitcoin when there was no path and they were in an evolution.

Currently, we have well-defined protocols to inherit from them or use them. which supports this logic and a lot more.

We can use Chain Agnostic improvement proposals Wallet Connect standard:
https://walletconnect.com/

Or implement a wallet connect standard like TON Connect specified for Pactus:
https://github.com/ton-blockchain/TEPs/blob/master/text/0115-ton-connect.md

Both of them have pros and cons!
But adding 3 functions and improving it step by step is reinventing the wheel.

If you agree, I think we can discuss in this way to have one of these. and change pip-23 status to withdrawn.

[b00f]

No, Please let's don't mix things.
This PIP is not categorized as"Wallet". It is related to "Interface" .

For that purpose we work on new PIP

[kehiy]

@b00f why we should have PIP for a simple code improvement? which is done a lot of times before?

[b00f]

@Ja7ad please update the PIP to and explain these APIs.

@Ja7ad This PIP should be categorized under "Interface". It adds new APIs to the gRPC. It should cover 3 methods:

* `SignMessageWithPrivateKey` (Util Service)

* `VerifyMessage`  (Util Service)

* `SignMessage`  (Wallet Service)

For the SignMessage, user needs to provide address and wallet password.

[Ja7ad]

@Ja7ad @b00f

I think these small changes were for Ethereum and Bitcoin when there was no path and they were in an evolution.

Currently, we have well-defined protocols to inherit from them or use them. which supports this logic and a lot more.

We can use Chain Agnostic improvement proposals Wallet Connect standard: https://walletconnect.com/

Or implement a wallet connect standard like TON Connect specified for Pactus: https://github.com/ton-blockchain/TEPs/blob/master/text/0115-ton-connect.md

Both of them have pros and cons! But adding 3 functions and improving it step by step is reinventing the wheel.

If you agree, I think we can discuss in this way to have one of these. and change pip-23 status to withdrawn.

walletconnect used sign and verify message for connecting then give some json-rpc method to interaction Dapps with wallet.

This is low layer methodology to sign and verify custom message with private and public key.

[b00f]

There are some issues with the PIP yet:

1. Private key is not in hex, it is in bech32 encoding.
   "Input: Message as string, Private key associated with Pactus account."
2. For "Example" we should provide data. Not function signature that is explained above. We can remove Example section.
3. Services are not mentioned. We can update like:

• SignMessageWithPrivateKey (Util Service)
• VerifyMessage (Util Service)
• SignMessage (Wallet Service)

[Ja7ad]

Private key is not in hex, it is in bech32 encoding.

What is it result of bench32 encode?

For "Example" we should provide data. Not function signature that is explained above. We can remove Example section.

Ok

Services are not mentioned. We can update like.

I add service name for this methods.

[b00f]

Yes, Private Keys encoded as string by bech32m, Example: https://github.com/pactus-project/pactus/blob/08559b417be1f22eab80c0cf812a35af3e640854/crypto/bls/private_key_test.go#L88

[Ja7ad]

Yes, Private Keys encoded as string by bech32m, Example: https://github.com/pactus-project/pactus/blob/08559b417be1f22eab80c0cf812a35af3e640854/crypto/bls/private_key_test.go#L88

Thanks understood

[Ja7ad]

@b00f Please review: #149

[Ja7ad]

Example diagram: https://t.ly/-wSwu

[Ja7ad]

Issue implementation created: pactus-project/pactus#1386

[Ja7ad]

This PIP implemented in: pactus-project/pactus#1397