New answers tagged signature
0
The value returned by signTransaction is a RLP-encoded raw Ethereum transaction including the signature.
For more info see:
https://github.com/ethereum/execution-apis/blob/main/src/eth/sign.json#L28-L46
https://medium.com/@bindassbasanta/sending-a-raw-transaction-ethereum-a7b75f845969
0
If you have the signed transaction(signedTrx) then you can use:
const txHash = ethers.utils.keccak256(signedTrx);
0
The ABI or the Application Binary Interface is the standard to interact with the contracts. EVM uses the ABI encoded data to understand which part of the bytecode to execute.
When does it happen?
A contract interaction is just another transaction on ethereum. The payload/what-to-do is in the data field of the transaction. ABI encoding encodes the user's ...
0
However Trezor adds the prefix auto, but wherever its required you to manually enter it for strlen(msg),it should be "32" (in string) or better to use "\x19Ethereum Signed Message:\n32" + keccak256(msg)
0
How the hash is calculated highly depends on the contract. So to provide a detailed answer you would have to link the specific contract.
There are a couple standards that outline guidlines on how such an hash should be generated:
EIP-191
EIP-712
As an example where signature recovery is used you can look at tokens that implement EIP-2612 or at smart ...
0
I was looking for some way to directly acquire the Y-parity, instead of recovering it after the fact. Did some research after posting this question, particularly on this article:
http://coders-errand.com/details-of-ecdsa-signatures/
So apparently R and S are calculated using several different values. One of these values is the X-coordinate of a randomly ...
1
There is a clear front-running issue with the claimTokens function.
Let's say that user A sends a claimTokens transaction with a signed message as the sig parameter.
User B (evil) sees the transaction in the mempool. To claim the tokens that belong to A, all B has to do is copy the parameters of A's transaction, including sig, and send its own claimTokens ...
2
In general there is no issue in using ecrecover the most important part is how you create the hash that you sign (e.g. include the contract address and chain id into the hash to prevent replay attacks)
Most wallets don't let you sign data that could potentially be a raw transaction. Therefore you have a couple standards for signing.
The most notable ones are ...
1
I figured it out thanks to this brilliant article.
The secret is to use web3.utils.soliditySha3 which will abi encode and hash like Solidity would!
const message = web3.utils.soliditySha3(
tokenIds.length,
state,
fromAddress
);
and in the contract simply do:
keccak256(abi.encodePacked(
tokenIds.length,
state,
msg.sender
))
1
We observe that web3 exposes a few wallet functionalities that may not be very clear at first:
web3.eth.accounts / getAccounts()
web3.eth.accounts.wallet
It seems web3.eth.accounts.wallet.create is a utility meant to create accounts on the fly without actually auto-binding them to your local node's account list (credits: previous answer). You could use ...
0
What exactly do v, r, and s stand for?
r is the R.x value of the signature's R point.
s is the signature proof for R.x
v is a recovery parameter used to ease the signature verification.
v is not required but often included. But what is v?
Since the signature only includes the x coordinate of the point R, there are either 0, 1, 2, 3, or 4 matching y ...
1
For future people, Ismael in the comments was correct. I also had encoding and hashing problems. This solution depends on the .net Nethereum library. Item of note - my data type was the sender address, so the ABIValue TYPE was set to "address". This made a huge difference.
private byte[] GetSignature(string privateKey, string textToHash)
{
...
Top 50 recent answers are included