I would like to create an Ethereum address 0x..... without a private key. Obviously one way to do it is to generate one from a paper wallet and throw away the key.
But is there another way to create one without a key? (I am not certain if the Ethereum blockchain checks an address for validity outside of the 0x prefix)
A valid Ethereum address is a checksum hex representation of a 20byte number starting with a 0x.
So anything between 0x0000000000000000000000000000000000000000 and 0xFFfFfFffFFfffFFfFFfFFFFFffFFFffffFfFFFfF is a valid Ethereum address.
You can generate a random 20byte number with openssl or a similar tool:
openssl rand -hex 20
Example output: b69c34f580d74396daeb327d35b4fb4677353fa9
And then checksum it:
This case-sensivity is used for checksum validation. The address is compared against the raw binary keccak-256 hash of the address bytes, and where there are letters in the same corresponding place as a “1” bit, the letter is capitalized.
Source: https://coincodex.com/article/2078/ethereum-address-checksum-explained/
Easier than calculating the hash and adjusting the letter capitalization based on that hash, is using a library that generates the checksum address (from a non-checkum address) for you - for example web3.js
Example output: 0xB69c34f580d74396Daeb327D35B4fb4677353Fa9
And you have a valid address without ever knowing the private key.
Related
I have a dataset containing obfuscated IPs. In order to do something, I would need to match IPs I know with this dataset.
If my dataset contains hashed IPs 1053617334, 1043615471
And I have IP 192.168.0.1, how can I hash it so I can verify if it is in the dataset or not?
IPv4 addresses are commonly represented as so-called "dotted quads", like 192.0.2.42 or 192.168.0.1.
That's 32 bits of data. And, that same data can be represented as a single unsigned decimal number. Your numbers like 1053617334, 1043615471 are probably examples of those numbers. They aren't, strictly speaking, hashed or obfuscated. They're just represented differently.
http://192.168.0.1 and http://3232235521 mean exactly the same thing.
There are all sorts of online tools to convert back and forth between dotted quad and decimal representation. For example.
Consult your AA documentation or support team to figure out how to handle this.
I am wondering besides these below mathematical expressions are there any other functions available to call inside a smart contract? Like math functions, like pi, sin, cosine, random() etc?
I am wondering if one can write smart contracts that require a little more than just basic arithmetic.
Below Image is taken from this page:
https://docs.soliditylang.org/en/develop/cheatsheet.html#function-visibility-specifiers
Solidity doesn't natively support storing floating point numbers both in storage and memory, probably because the EVM (Ethereum Virtual Machine; underlying layer) doesn't support it.
It allows working with them to some extent such as uint two = 3 / 1.5;.
So most floating point operations are usually done by defining a uint256 (256bit unsigned integer) number and another number defining the decimal length.
For example token contracts generally use 18 decimal places:
uint8 decimals = 18;
uint256 one = 1000000000000000000;
uint256 half = 500000000000000000;
There are some third-party libraries for calculating trigonometric functions (link), working with date time (link) and other use cases, but the native language currently doesn't support many of these features.
As for generating random numbers: No native function, but you can calculate a modulo of some pseudo-random variables such as block.hash and block.timestamp. Mind that these values can be (to some extent) manipulated by a miner publishing the currently mined block.
It's not recommended to use them in apps that work with money (pretty much most of smart contracts), because if the incentive is big enough, there can be a dishonest miner who can use the advantage of knowing the values before rest of the network and being able to modify them to some extent to their own benefit.
Example:
// a dishonest miner can publish a block with such params,
// that will result in the condition being true
// and their own tx to be the first one in the block that executes this function
function win10ETH() external {
if (uint256(blockhash(block.number)) % 12345 == 0) {
payable(msg.sender).transfer(10 ether);
}
}
If you need a random number that is not determinable by a miner, you can use the oracle approach, where an external app (called oracle) listens to transactions in a predefined format (generally also from&to specific addresses), performs an off-chain action (such as generating a random number, retrieving a google search result, or basically anything) and afterwards sends another transaction to your contract, containing the result of the off-chain action.
EIP-155 states that the "The string format of the substituted hexadecimal ID MUST be leading zero padded to 64 hex characters length if necessary."
In what situation is a 0-padded hex ID necessary? It is odd they chose to use the keyword MUST here as it seems like the choice of whether to use 64 hex character padding is completely arbitrary.
I understand that there cannot exist more than 2^256 ids (64 hex digits), but wouldn't the choice of metadata URI for an ERC-1155 token be implementation-dependent?
For example, if I wanted to create an ERC-1155 token composed only of 64 NFTs, I'd much prefer defining metadata URLs as follows:
https://{DOMAIN}/1.json
https://{DOMAIN}/2.json
...
https://{DOMAIN}/40.json (64 in hex)
I suspect that ERC-1155 was built with uint256 in mind as the standard for numeric types and that requiring ID to be padded to 64 hex characters means that all 256 bits of information are specified explicitly. Maybe this alleviates potential issues with dirty leading bits?
Padding doesn't appear to be strictly necessary to function - I have seen smart contracts which use unpadded metadata URLs, such as Mining.game
(https://mumbai.polygonscan.com/address/0x1a3d0451f48ebef398dd4c134ae60846274b7ce0#code),
(https://api.mining.game/1.json).
This is on the Polygon testnet, not a mainnet, so keep in mind that code quality may not be stellar. But regardless, it appears to work.
I know how to generate ethereum public address from public key or from private key.
But i was wondering if we can generate the public key from ethereum public address?
Creating Public Key from Ethereum Address is IMPOSSIBLE.
As you know, from Public key you can achieve Address via 40% of an array which was hashed by keccak procedure, and this is a one-way path.
So, let`s looking at this algorithm:
1- having public key (128 characters, hex format meaning 0-F)
2- keccak hash it to receive 64 characters, again hex format
3- drop first 24 characters which remains for us 40 character as address
4- you can add "0x" now to the beginning of this array.
keccak hashing is not reversible, if you want to brute force it it will take 16^64 guesses or one century if you can have access to a quantum computer which can guess 3.6*10^67 arrays per second.
This is except that 24 hex characters that you dropped, so add 40% load on top of it.
No quantum processor is invented yet!!!
It is very simple but only and only if a tx was sent by that address over the ethereum network.
In ethereum there exist r, s, v values. v is the message hash, s is signature and r is empirical pubKey and to understand this r you must have some background of ECDSA,which is obviously not part of the question.
So once you have them from raw-tx data you may recover pubKey, say Q, in following way (G is generator Point):
r = (vs^-1) x G + (rs^-1) x Q
r - (vs^-1) x G = (rs^-1) x Q
Q = (rs^-1)^-1 x (vs^-1) x G
Good now you have all known on RHS and unknown at LHS, just calculate.
Suggested reading: ECDSA Wiki
I want to know if BigInt is enough in size.
I have created a registration.php where the user gets emailed an account activation link to click to verify his email so his account gets activated.
Account Activation Link is in this format:
[php]
$account_activation_link =
"http://www.".$site_domain."/".$social_network_name."/activate_account.php?primary_website_email=".$primary_website_email."&account_activation_code=".$account_activation_code."";
[/php]
Account Activation Code is in this format:
$account_activation_code = sha1( (string) mt_rand(5, 30)); //Type Casted the INT to STRING on the 1st parameter of sha1 as it needs to be a STRING.
Now, the following link got emailed:
http://www.myssite.com/folder/activate_account.php?primary_website_email=my.email#gmail.com&account_activation_code=22d200f8670dbdb3e253a90eee5098477c95c23d
Note the account activation code that got generated by sha1:
22d200f8670dbdb3e253a90eee5098477c95c23d
But in my mysql db, in the "account_activation_code" column, I only see:
"22". The rest of the activation code is missing. Why is that ?
The column is set to BigInt. Is not that enough to house the Sha1 generated code ?
What is your suggestion ?
Thank You
Hashing methods like SHA-1 produce binary values that are on the order of 160+ bits long depending on the variant used. The common SHA256 one is 256 bits long. No cryptographic hash will fit in a 64-bit BIGINT field because 64-bit hashes are uselessly small, you'll have nothing but collisions.
Normally people store hashes as their hex-encoded equivalents in a VARCHAR(255) column. These can be indexed and perform well enough in most situations, especially one where you do periodic lookups based on clicks. From a performance and storage perspective there's no problems here.
Short answer: BIGINT is way too small.
A hash is basically a stream of bits (160 bits in the case of SHA-1). While it's certainly possible to render those bits as a base 2 number and convert it to base 10, you need a really big storage to do so (as far as I know it's not common to see integer variables larger then 64 bits) and there aren't obvious advantages. BIGINT is a 64-bit type, thus cannot do the job.
Unless you have a good reason to store it as number, I'd simply go for either a binary column type or its plain-text hexadecimal representation in a good old VARCHAR (the latter tends to be more practical to handle).
You are trying to store a string in a BigInt. That is your issue. SHA hashes are a mix of alphanumeric characters not just numbers. Change the field to a VARCHAR and you'll be fine