Adding raw signature values to FeeMarketEIP1559Transaction (or any other Transaction type)

[vdamle]

For apps that generate signatures from HSMs/hardware wallets etc., it would be nice if the library provides a way to input the ECDSA signature parameters generated by the signer and the y-parity, along with the unsigned TX payload and get the payload with signature.

I see there is a method that does exactly this but it is protected:

https://github.com/ethereumjs/ethereumjs-monorepo/blob/master/packages/tx/src/eip1559Transaction.ts#L311-L331

Obviously, I can copy-pasta that code, but it would be nice to expose that method. Thoughts?

[jochem-brouwer]

Does the HSM/hardware wallet return an yParity of either 0 or 1 for these signatures? (I assume you are using EIP1559 txs?)

[vdamle]

Sorry for the delay. You are correct that I can get the correct r and s and v values from the signature returned from the HSM/any external wallet -- after a little bit of gymastics -- specifically, changing s value to make sure it is non-malleable and also determine the correct v.

• So I started by instantiating a Transaction with a call to fromTxData where I supply all relevant values as params.
• I then generate the 32 byte hash that I can send to an external signing service.
• After I have the signature parameters, I have to call fromTxData again by supplying all relevant params that now includes the signature params (duplication, IMO)

To me, that feels like extra boilerplate because:

• r, s and v are read only variables.
• there is no helper function in the library for "Look, i created this transaction without signature params. I now have the signature params, could you please add these to the transaction and give me back what I need to submit to the node?"

That said, I do agree that an end user can the same code that _processSignature() has accomplish the above.

[jochem-brouwer]

Aha, now I indeed see the redundancy which is indeed somewhat unnecessary. What value does your HSM return for v? Is it 0 or 1 or something else?

We should indeed expose _processSignature or something similar (maybe overload sign to accept r, s, v values?). We will discuss 😄

[vdamle]

Thanks @jochem-brouwer - ether of those solutions would work just fine! HSM only returns {r, s} for the signature. The v bit is computed locally by attempting recovery for v = {0, 1} and use whichever value results in a public key/address match.

[jochem-brouwer]

I addressed this today, I think this would work for you? #3238

[vdamle]

The API looks great @jochem-brouwer , thanks for the enhancement! 🙏🏼