I'm studying solidity programming, and I have a question on this line of code:
Transfer(0x0,msg.sender,tokens);
I don't understand what 0x0 means. Is it the new token address or is it the new smart contract's address?
0x0 is essentially a black hole of an address. Ether funds go in, none come out (kind of like a marriage!). It's an abbreviation for the genesis address 0x0000000000000000000000000000000000000000, which with almost absolute certainty nobody has the private key for, so it can't be spent. Note that tokens like ERC20 can be transferred OUT depending on the contract, but not Ether.
Amusingly/tragically a lot of people screw up and send money here by accident.
In your case, it looks like the contract is trying to send money to this address. Apparently, there's some use cases for this called "proof of burn" which I guess means that you can send ether? I don't quite understand that as it's literally taking Ether out of circulation.
Other cases can be for using it as a large amount for an address for comparison. Example is your_ETH_balance < 0x0 (Is probably TRUE).
Currently, 0x0 has 7251 ether (and growing since I started typing). Today's trading puts it worth about $4.2 million, so it'd be one of the more valuable addresses to crack if you happen to have a functional quantum computer (which you don't).
Related
I am learning about threshold signatures and their use cases on EVM Blockchains.
I am trying to understand how they are able to always have the same address.
Is the following correct? It is my understanding of how it works
A smart contract exists on chain. This smart contract is the address
of the TSS wallet. The smart contract has a function that decides if
signatures are valid. If this function is called with the requisite
(threshold) signatures from parties, it approves use of the smart
contract address for on chain meta transactions.
TSS does not have a way to work off chain to produce an Externally
Owned Address (EOA) even in a two party case. It depends on a third
party smart contract to authorize use of an address.
Sorry if I'm way off, it's quite hard to understand the underlying tech of TSS. As I understand it, there is no known way to create an EOA without re-assembling a private key e.g. with MultiSig right? Or can TSS produce signatures from the same address based on signatures of two parties, such that the TSS signature always represents the same address / private key that is not known by any party? Any examples or documentation would be greatly welcome!
I am not an expert on multiparty computing (MPC) which I believe threshold signatures (TSS) are part of. Thus, I do not know if there is a way to cryptographic natively to have a stable EOA for TSS. But I know some multiparty computing hardware companies do this by providing generic multisignature solutions across multiple different blockchains.
However you can have a simple threshold scheme with Ethereum by
Deploying a smart contract that lists its owners in the on-chain storage
The smart contract needs to have just one function to check if the incoming messages contains enough signatures from owners
The address of such account is the deployed smart contract address
Here is a tutorial of building such a smart contract wallet by Mahmoud Fathy.
I discovered a YouTube based scam where a fake Solidity tutorial instructs users to go into Remix and deploy a scam contract. The scam contract allows any address to withdraw the funds. It has fake comments that are hilarious, but it is really scary that this scam targets potential new people in the space.
How do I find the matching contracts from the compiled bytecode? I want to see on the blockchain which contracts match this so I can find the offending address that reaches out to claim.
If there a method in geth? What about a scanner? Maybe The Graph and a subgraph?
Should I just download the chain and query? The problem for me is chain bloat and syncing Ethereum will take forever.
I'm working on a new project that I'm launching soon. The dapp is almost ok, I'm writing the contracts.
But I'm not sure I understood everything, if someone can help me :(
I would like to create a token contract with a supply fix (like 1 million), then make two pre-sales (one with and without whitelist), then a contract to sell on DEX with rewards, staking system, etc.
What is the best way to do this?
Is it possible to :
create the tokens with the first contract
transfer them to the pre sale whitelist contract
make the pre-sale
transfer the remaining tokens to the pre-sale contract without withelist
make the pre-sale
transfer the remaining tokens on the last contract, which will manage all the features of my token + put on a dex
am I right in the way I do it or am I completely wrong ?
If I'm wrong, do I have to do everything in one contract, with specific functions and flags like for the beginning and the end of a pre-dirty ?
if I do everything in one, will some smart guy be able to put the contract on a DEX and add liquidity?
I looked for several ohm/nodes project contracts, I saw the pre-sale contracts but I didn't understand when they create the token because their pre-sale contracts are just sell contracts
and I didn't understand how after the pre sale the main contract takes over
i would like a final contract like that, once the sales are finish
https://snowtrace.io/address/0xf2cfc11093edb5a2dc7f49e70a3a3a9cd4f4fee4#code
if someone can help me, thanks :)
ps : last question, in the contract i dont understand what are payees, shares, addresses and balances variables
This question covers a few different things so I'm going to split my answer up.
Answers:
I looked for several ohm/nodes project contracts, I saw the pre-sale contracts but I didn't understand when they create the token because their pre-sale contracts are just sell contracts
Presale contracts by nature are selling contracts the token contract and the presale contract are generally not the same but there are a thousand ways to do that. They receive x amount of tokens and take payment in say ETH for x tokens.
if I do everything in one, will some smart guy be able to put the contract on a DEX and add liquidity?
Anybody will pretty much always be able to add liquidity for a token because that is external to the token but there are certain ways you can prevent adding liquidity until a certain condition is met say a certain timestamp you just need to detect operations that are swaps/adding liquidity and throw an error.
ps: last question, in the contract I don't understand what are payees, shares, addresses, and balances variables
I am not entirely sure what the purpose of these are for because I am not very familiar with the BRIG protocol.
and I didn't understand how after the pre-sale the main contract takes over
The main contract does not need to take over from the presale contract because the presale contract just runs until all of the tokens are sold and then it just becomes an empty husk.
Other stuff:
In the future please split up your questions across multiple StackOverflow posts.
I'm a product manager not a Blockchain coder, looking for a 2nd opinion and some general good practice advice. I have one question in bold, the rest is background.
Background:
We have an app in development that will write user's information into a Smart Contract on the ETH blockchain.
The SC's we deploy contain information only, no Ether.
Each user has their own SC which stores only that users specific information.
Our App allows the user to edit and update this information and then upload the changes, encrypted, into their own SC.
The user's SC address is 'tied' (sorry for lack of correct terminology) to their own Ether wallet.
I see on Etherscan (Ropsten) there is a Contract Creator address which is a constant for all the SC's our App creates.
I'm assuming that the contract creator address is unique to us, it is code we've created and as such it deploys only our Smart Contracts on behalf of our Application.
I was hoping that each SC address would be known only to its owner and us only. Now I see that anyone can access this information.
My Concerns:
Should there be an exploitable flaw in our code then a bad actor has a list of contract addresses to attack.
The worst-case risk to us is that a bad-actor could access each users data in an unencrypted state if a flaw exists in our publicly accessible code.
The Bad-Actor then uses that flaw and the list of smart contract addresses they can get from Etherscan to download multiple users data.
My Question
Are these realistic concerns?
If so what general directions can we look at to mitigate these risks
If so is there a way I can obscure the Creator address in Etherscan without other negative consequences
The developers are outsourced 3rd parties and excellent people to work with. But Im looking for an alternate opinion than just theirs at this time as a double check.
Apologies if the information Ive provided is confusing or incomplete.
Thanks in advance for your time.
I was hoping that each SC address would be known only to its owner and us only. Now I see that anyone can access this information.
As you have addressed here, data regarding the blockchain (i.e. transaction hashes, contract addresses, and user addresses) is transparently available. This is by-design with Ethereum and allows for the traceability aspect of the ledger.
Furthermore, smart contract data is potentially available to any actor in the Ethereum network. However, that is based upon the following:
In order to access the smart contract data, an actor would require the contract ABI. This interface allows code to be written to interact with the smart contract methods. Now, it is helpful to understand that this ABI could hypothetically be easily reverse-generated with enough details of how your DApp interacts with the existing smart contract.
If your smart contract logic has exploitable flaws, a malicious actor on the network could take advantage of this. This is why contracts should be well-written and unit tested with near (if not) 100% code coverage. You should also identify the potential actors in each contract scenario and be sure your test cases appropriately cover these scenarios.
If so what general directions can we look at to mitigate these risks
Given the contract scenario you have described, if the only actor who should have access to these user data smart contracts is the user them self, then you simply need to apply something akin to a function modifier to your smart contract logic. In the linked example, access to the smart contract data is restricted to a single specific Ethereum user address.
If so is there a way I can obscure the Creator address in Etherscan without other negative consequences
Sure. It sounds like you're currently using a single account to deploy the smart contracts, hence the creator address is constant. (Side note: I'm not sure why you're deploying the contract on behalf of the user with this account, it sounds like the user should be deploying their own smart contract). Regardless, you could simply create a new proxy user address each time you deploy the smart contract. However, I don't see any benefit to doing so and this would just be an example of security through obscurity.
Background on the compromised address
I fell for a MEW phishing scam, and I use that particular eth address for airdrops, investments sites etc, I'm expecting eth to be paid to me through that address, and I can't change the address because I've already used it.
My approach
My intended approach is: a script that will perpetually check my address for any incoming ether, and automatically transfer it to another address. This needs to happen before the scammer transfers the ether out. I am willing to use a high gas price, so the transfer can be swiftly included in a block.
How to Implement?
From my little research, I've found out that this can only happen through webjs, and having the full eth node. Can I use infura and Nodejs to do this? If it's possible, how do I do it?
Racing the Scammer
You are unlikely to be able to out-compete the scammer in a race to withdraw. They are "professionals" at this, and can probably submit the withdrawal transactions faster than you.
Stop the Bleeding
Your best option is to find a way to change the location of any future dividends & withdrawals. For example, if you have an ERC20 token that sends you dividends (and the scammer didn't already drain the token from your account), then transfer that token to an uncompromised account. Dividends will start appearing in your new account, and the scammer cannot intercept them.
Prevention
I'm sorry for your loss. Many people have learned expensive lessons this way. It's worth reading up on prevention techniques to avoid phishing scams, to help protect yourself in the future.