secp256k1 key support

[waynenilsen]

Is your feature request related to a problem? Please describe.

This library is not capable of properly serializing secp256k1 public keys.

The deserialization side requires 64 bytes but the schema requires 32 bytes

Related issue - it does not support serialization for secp256k1 signatures which are 65 bytes not 64 as demonstrated here in nearcore

Update - I did end up working around this other issue by simply using rpcRequest directly and doing all of the other work of creating the tx, serializing, signing, serializing again (to bytes) then to base64 for the param value for interacting with rpc directly.

Describe the solution you'd like

Basically I am asking that this client update to something equivalent to
what nearcore has

Describe alternatives you've considered

I may need to implement serialization myself in the meantime or fork this repo to continue progress. Really fundamental issue here.

Given it more thought, it seems that because SCHEMA is exported I can set up what I need to make this work (for now) although it would be great to have this in the library itself.

Additional context

here is some code that does not run in isolation but does demonstrate the issue that i'm running into

  it("should create an account from a funded implicit account", async () => {
    const rootAccount = worker.rootAccount;
    const newKey = RbsNearEd25519KeyPair.fromRandom();
    const implicitAccountId = newKey.implicitAddress();
    const testNearAmountToStartWith = parseNearAmount("1");
    const result = await rootAccount.transfer(implicitAccountId, testNearAmountToStartWith);
    expect(result.result.status["SuccessValue"]).to.eq("");
    const accountDetails = await worker.provider.viewAccount(implicitAccountId);
    expect(accountDetails.amount).to.eq(testNearAmountToStartWith);
    const connection = new Connection(
      "networkId",
      worker.provider as unknown as providers.Provider,
      new SingleSigner(newKey),
      "jsvmAccountId"
    );
    const publicKeyBytes = new Uint8Array(new Array(64).fill(0));
    const implicitAccount = new Account(connection, implicitAccountId);
    const createAccountResult = await implicitAccount.createAccount(
      v4(),
      new utils.key_pair.PublicKey({ keyType: 1, data: publicKeyBytes }),
      new BN(parseNearAmount("0.5"))
    );
    expect(createAccountResult).to.be.ok;
  });

Realistically I know that I am already attempting to circumvent the serialization with what i'm doing with keyType direct assignment but you get the idea.

When you change this code to use 32 bytes and keyType 0 it serializes the transaction fine.

Ok and I came back and did some manual work around here and this works

  it("should create an account from a funded implicit account", async () => {
    const rootAccount = worker.rootAccount;
    const newKey = RbsNearEd25519KeyPair.fromRandom();
    const implicitAccountId = newKey.implicitAddress();
    const testNearAmountToStartWith = parseNearAmount("1");
    const result = await rootAccount.transfer(implicitAccountId, testNearAmountToStartWith);
    expect(result.result.status["SuccessValue"]).to.eq("");
    const accountDetails = await worker.provider.viewAccount(implicitAccountId);
    expect(accountDetails.amount).to.eq(testNearAmountToStartWith);
    const connection = new Connection(
      "networkId",
      worker.provider as unknown as providers.Provider,
      new SingleSigner(newKey),
      "jsvmAccountId"
    );
    const publicKeyBytes = new Uint8Array(new Array(64).fill(0));
    const implicitAccount = new Account(connection, implicitAccountId);

    SCHEMA.set(Secp256k1PublicKey, {
      kind: "struct",
      fields: [
        ["keyType", "u8"],
        ["data", [64]],
      ],
    });

    const createAccountResult = await implicitAccount.createAccount(
      v4(),
      new Secp256k1PublicKey({ keyType: 1, data: publicKeyBytes }) as utils.PublicKey,
      new BN(parseNearAmount("0.5"))
    );
    expect(createAccountResult).to.be.ok;
  });

[pong-rong]

Ahem..
#780

[waynenilsen]

Respectfully, I have completely lost context on this and I cannot carry it forward at this time. It is still a shortcoming for this client however and I believe it should be addressed.

If there is any way that you want me to help please let me know. I'm not sure what is meant by your comment but I do find it unnecessarily cryptic.