Sender account not recognized on private ethereum network - ethereum

I'm currently developing a dApp in Solidity and am working on a web3 library to handle communication with it.
I struggle with the process of new account creation and transaction signing in web3. Before I continue it worth noting that I'm running my own local, private blockchain (currently with Ganache).
My code looks as follows:
try{
let a = web3.eth.accounts.create()
let dataTx = someContract.methods.someMethod().encodeABI()
let rawTx = {
to: someContract._address,
from: account.address,
data: dataTx,
gas: 10000000000
}
const transaction = web3.eth.accounts.signTransaction(rawTx, util.toBuffer(account.privateKey))
web3.eth.sendTransaction(rawTx).then(console.log)
}
catch(e){
console.log(e)
}
The problem here is that the web3.eth.sendTransaction() method raises the following exception: Error: Returned error: sender account not recognized.
My understanding is that web3.eth.accounts is used for managing local accounts and web3.eth.personal is used to communicate with a client (e.g. Geth). I wish to keep the private keys of accounts my app creates locally on the device of the web3 client, but it raises this exception.
Where am I going wrong? Should I register the newly created accounts somewhere before running transactions with it? Is there some vital information I'm missing here?
Thanks!

If you want to use an account other than Ganache provided you, you have to start Ganache providing your accounts data in the form private_key,initial_balance:
Example command: ganache-cli --account 0xf38b5679751228eab7d9f3aa02bd0b0c0f7b44e448c0cfd410a1d7053efb6c56,123456789
And it's output:
Ganache CLI v6.1.8 (ganache-core: 2.2.1)
Available Accounts
================== (0) 0x44fa41e453654ccb365a358e994c764a37eea91f (~0 ETH)
Private Keys
================== (0) 0xf38b5679751228eab7d9f3aa02bd0b0c0f7b44e448c0cfd410a1d7053efb6c56
Gas Price
================== 20000000000
Gas Limit
================== 6721975
Listening on 127.0.0.1:8545

I am having same issue in my project. The problem in my case is beacuse i am not using same web3 provider to create contract variable.
example code:
const providerEth= new Web3.providers.HttpProvider(
'HTTP://127.0.0.1:8545'
);
const web3Eth = new Web3(providerEth);
const contract= new web3Eth.eth.Contract(abi,address);
Here, we are not using metamask provider although both on same network Still it not recognize the account. So you should create contract like this
const web3Eth = new Web3(window.web3.currentProvider);
const contract= new web3Eth.eth.Contract(abi,address);
const accounts = await web3.eth.getAccounts();
var receipt=await contract.methods.transfer(receiver,amount).send({from:accounts[0]});
Now, you can able to call smart contract function with account address.

I had the same issue. It happened when I already opened my truffle console and after that I did a restart of my ganache because I wanted to start clean.
What fixed it for me was stopping the truffle console job and starting it again.

You are refering to functionality in web3 1.0.0 which is not yet fully released.
If you go to https://web3js.readthedocs.io/en/1.0/getting-started.html
you would see that they state the following:
This documentation is work in progress and web3.js 1.0 is not yet released! You can find the current documentation for web3 0.x.x at github.com/ethereum/wiki/wiki/JavaScript-API.
Most probably you are using a version 0.20.x or something like that so check this first. To check this open the dApp in the browser and type in the console the following:
web3.version.api
This should show you which version you are using.
I don't think there is a way to create accounts with web3js 0.20.x directly but you can try to update the web3js to the 1.0.0-beta and try to run your code again. You can find it in NPM here - https://www.npmjs.com/package/web3

Related

ChainableTemporaryCredentials getPromise and Missing credentials in config, if using AWS_CONFIG_FILE

I have an node application deployed in GCP.
The application includes code to access ressources in AWS-cloud.
For this purpose it uses the aws-SDK with ChainableTemporaryCredentials.
The relevant code lines are...
const credentials = new ChainableTemporaryCredentials({
params: {
RoleArn: `arn:aws:iam::${this.accountId}:role/${this.targetRoleName}`,
RoleSessionName: this.targetRoleName,
},
masterCredentials: new WebIdentityCredentials({
RoleArn: `arn:aws:iam::${this.proxyAccountId}:role/${this.proxyRoleName}`,
RoleSessionName: this.proxyRoleName,
WebIdentityToken: token,
}),
})
await credentials.getPromise()
The WebIdentityToken was received from google and looks good.
At AWS-side I created an proxy-role (the line from masterCredentials RoleArn).
However at runtime I get the error:
Missing credentials in config, if using AWS_CONFIG_FILE, set AWS_SDK_LOAD_CONFIG=1
I do not understand this error. Because my application runs in GCP and I use temporary credentials I do not understand why I should use aws-credentials in form of an credentials file or environment variables like AWS_ACCESS_KEY_ID or AWS_SECRET_ACCESS_KEY. I thought the idea to use ChainableTemporaryCredentials is NOT to have direct aws-credentials. Right?
You can see the public code at:
https://github.com/cloud-carbon-footprint/cloud-carbon-footprint/blob/trunk/packages/aws/src/application/GCPCredentials.ts
and documentation regarding env-variables at:
https://www.cloudcarbonfootprint.org/docs/configurations-glossary/
Any help which leads to understanding of this error message is welcome.
Thomas
Solved it. "Missing credentials in config, if using AWS_CONFIG_FILE, set AWS_SDK_LOAD_CONFIG=1 was totally misleading." In reality it was a problem with the field-names in the GCP-JWT-token und the policy in aws. See https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_iam-condition-keys.html#ck_aud

how to actually make an auction functionality into my daap?

I've been trying to make an NFT marketplace with the functionality of auctioning an item. But I don't know how to achieve this via signing transaction.
I have tried to use almost every method of signing from web3.js, but it requires the private key of the user.
However there's the function web3.eth.signTransaction which doesn't require any private key to sign the transaction, but it gives an error on the console. saying : Error: The method 'eth_signTransaction' does not exist / is not available.
Can someone give me an overview of how this signing and sending transaction can be done implementing the functionality of auctioning an nft like nft marketplaces: opensea or foundation.
From the docs:
Signs a transaction. This account needs to be unlocked.
It doesn't require the private key, but it requires the account (that is used for signing the transaction) to be unlocked on the node. Which means the node needs to hold the private key to unlock the account.
It's usually allowed on local nodes such as Ganache or private nodes.
And public nodes such as Infura usually disable this functionality (hence the error message "eth_signTransaction is not available") since they don't store your private keys.
You can ask the user to sign the transaction using their wallet. For example using MetaMask (or any other wallet implementing the Ethereum provider API):
const transactionParameters = {
from: ethereum.selectedAddress, // must match user's active address
to: 'your address'
};
await ethereum.request({
method: 'eth_sendTransaction',
params: [transactionParameters],
});

What is the difference between currentprovider and givenprovider in web3.js

Can anyone explain what is the difference between currentprovider and givenprovider?
I think like this.
givenprovider connects to blockchain thorough web browser, and
currentprovider connects to blockchain thorough metamask.
I'm not sure my understanding is correct.
Do you have any idea?
I think that's a lot of confusion regarding the Ethereum providers because lack of the standard at the begining. I'd like to sort it out as I understand it.
From web3 docs:
import Web3 from 'web3';
// "Web3.providers.givenProvider" will be set if in an Ethereum supported browser.
const web3 = new Web3(Web3.givenProvider || 'ws://some.local-or-remote.node:8546', net, options);
Please not that to initialise web3 instance, the givenProvider on the Web3 module is used.
Let's see MetaMask docs:
MetaMask injects a global API into websites visited by its users at
window.ethereum (Also available at window.web3.currentProvider for
legacy reasons)
This is based on ERC1193
Basically, Web3 assigns window.ethereum to Web3.givenProvider property if the provider is ERC1193 compliant (as MetaMask), and can perform some fuzzy magic to detect the provider if not.
Following this logic, on the instance web3.currentProvider is the provider that web3 was initialized with, while web3.givenProvider is the provider injected by the environment (like window.ethereum). For example:
import Web3 from 'web3';
export const givenWeb3 = new Web3(Web3.givenProvider)
givenWeb3.currentProvider === givenWeb3.givenProvider // true
export const externalProvider = new Web3('http://localhost:8545')
externalProvider.currentProvider === externalProvider.givenProvider // false

Truffle/Ganache: is there a way to set a deployment address?

I'm currently developing a dapp in Solidity and want to frequently test it locally along with the updates - so I don't really want to redeploy it everytime to a test net.
However, everytime I deploy it, the address the smart contract is deployed to changes, so I have to update my front-end code to the new address.
Is there a way to "force" the smart contract to always be deployed at the same address? Or is there any other equivalent solution you might think of?
Thanks!
Faced the same problem. I don't know whether it legal but you can do:
in your migration file (migrations/1_example_migration.js)
var MyContract = artifacts.require("MyContract");
module.exports = function(deployer) {
console.log(deployer);
console.log(arguments);
let n = 5; // it can be any address from list of available
deployer.deploy(MyContract, {from: arguments[2][n]});
};
Documentation
you can get the account list you have by passing in the accounts argument like follows In the deploy_migration files :
module.exports = function(deployer, network, accounts) {
// Use the accounts within your migrations.
}

VimeoUpload not re-authenticating After Deletion of App Access on Vimeo.com

I was able to connect and upload videos using the library but when I deleted the app connection on Vimeo.com (as a test) the app didn't authorize again.
the upload looks like it's working but nothing is uploaded as the app is no longer connected.
I deleted the app on the phone and restarted but it still won't re-authorize the app.
This comes up in the output:
Vimeo upload state : Executing
Vimeo upload state : Finished
Invalid http status code for download task.
And this is in OldVimeoUpload.swift: ( didn't include the actual access code!)
import Foundation
class OldVimeoUpload: VimeoUpload
{
static var VIMEO_ACCESS_TOKEN :String! // = "there's a string of numbers here"
static let sharedInstance = OldVimeoUpload(backgroundSessionIdentifier: "") { () -> String? in
return VIMEO_ACCESS_TOKEN // See README for details on how to obtain and OAuth token
}
// MARK: - Initialization
override init(backgroundSessionIdentifier: String, authTokenBlock: AuthTokenBlock)
{
super.init(backgroundSessionIdentifier: backgroundSessionIdentifier, authTokenBlock: authTokenBlock)
}
}
It looks like the access token number is commented out. I deleted the 2 forward slashes to see if that would fix it but it didn't.
I spoke too soon.
It sounds like you went to developer.vimeo.com and created an auth token. Used it to upload videos. And then went back to developer.vimeo.com and deleted the auth token.
The app / VimeoUpload will not automatically re-authenticated in this situation. You've killed the token and the app cannot request a new one for you. You'll need to create a new auth token and plug it into the app.
If this is not accurate and you're describing a different issue let us know.
If you inspect the error that's thrown from the failing request I'm guessing you'll see it's a 401 unauthorized related to using an invalid token.
Edit:
Disconnecting your app (as described in your comment below) has the same effect as deleting your auth token from developer.vimeo.com.
Also, VimeoUpload accepts a hardcoded auth token (as you see from the README and your code sample). It will not automatically re-authenticate, probably ever.
If you'd like to handle authentication in your app check out VimeoNetworking or VIMNetworking. Either of those libraries can be used to create a variety of authentication flows / scenarios. Still, if a logged in user disconnects or deletes their token, you will need them to deliberately re-authenticate (i.e. you will need to build that flow yourself). In that case, the user has explicitly stated that they don't want the app to be able to access information on their behalf. It would go against our security contract with them to automatically re-authenticate somehow.
Does that make sense?