3

when converting a type that uses a larger byte size then address Well, the behavior of these two methods depends on that type, for example: For uint256 b, they both return the same result, which is the 160 least-significant bits of b But for bytes32 b, the first method returns the 160 most-significant bits of b Testing method (Truffle 4.x): pragma ...


3

It is typically in order to workaround compiler warning about a view function which can be restricted to pure, for example: uint256[4] public arr; constructor() public { arr[0] = 11; arr[1] = 22; arr[2] = 33; arr[3] = 44; } function func(uint256 x) public view returns (uint256) { if (x < arr.length) return handle(x, viewFunc);...


2

The difference allows the programmer to be aware which addresses are meant to receive ether and which don't, as explained at the bottom of the the answer you linked (under "Rationale"). It is a static safety measure provided by the language (like static type checking). address payable has members transfer and send, address does not (Solidity >= 0.5). ...


2

Yes, type is a reserved keyword in Solidity, according to the source code. However, according to the docs, type is not a reserved keyword. With that said, the reason it is reserved is for deriving type information on-chain. You can read more about it in the docs: The expression type(X) can be used to retrieve information about the type X. Currently, ...


2

These keywords are reserved in Solidity. They might become part of the syntax in the future. Check this link


2

You could require streamers to overcollateralize, with those that fail to stay overcollateralized being liquidated. With that you can take a lazy update approach, where self-interested actors update the smart contracts in a patchwork pattern. So imagine for example that all streams are required to post collateral for at least 3 hours of streaming. When a ...


2

Starting from solc 0.5, call returns two values: bool success, which indicates whether or not the function completed successfully bytes memory data, which is the actual data returned from the function The comma in (bool success, ) = ... implies that you are already using solc 0.5 or higher. So simply change it to (bool success, bytes memory data) = ..., ...


2

This is called a developer revert comment. From the Brownie documentation: Each revert string adds a minimum 20000 gas to your contract deployment cost, and increases the cost for a function to execute. Including a revert string for every require and revert statement is often impractical and sometimes simply not possible due to the block gas limit. For this ...


2

No not at the moment but this keyword is reserved in Solidity in latest document. They might become part of the syntax in the future. Check this link


2

address(0) is a conceptual-abbreviation of an address with no known private key. Naturally, it means that if you transfer your ether to this address, then no one will be able to retrieve it. If you transfer your tokens to this address... well, that depends on how the token contract is implemented. For example, this promiscuous contract will allow anyone to ...


2

address(0) is a short way to write 0x0000000000000000000000000000000000000000 (which is essentially 0x0). The address is sometimes used to burn tokens, since it's very unlikely that someone has the private key for this address. The deposit function in your code assigns an amount of ETH (msg.value) to tokens[0x0][sender address], it does not actually send any ...


2

Turn out that Truffle v5 versions earlier than v5.1.5 won't successfully compile ^0.6.0 solidity contracts, because the solc wrapper Truffle used (directly from solc-js) was only compatible with ^0.5.0 contracts. The solution is to update the truffle package using npm update -g truffle Thanks to CruzMolina form GitHub !


2

No, it is not possible in solidity. The EVM doesn't have an opcode that can return that value. The BALANCE opcode returns the current balance of an address.


2

//please explain this for loop for (uint i = index; i < prices.length-1 ; i++){ prices[i] = prices[i+1]; } consider prices = [a, b, c, d, e ,f ,g] and index is 2 then element to be deleted is prices[2] which is c. Inside the for loop prices are reassigned to value of the next and deletes the last. after the for loop ends prices = [a, b, d, e, f, g, g]...


2

This is a design issue with ERC-20 standard. It has been not fixed until later ERC-777 standard and its send() method. Unfortunately, most of ERC-20 token contracts cannot be upgraded. You need to keep supporting this bad UX pattern forever. More here: Gasless transaction and easy token Solidity receiver callbacks for ERC-20 tokens Edit: Well there is a way ...


2

The Istanbul hardfork included EIP-1884, which (among other repricings) repriced SLOAD from 200 to 800 gas. That means loading 5 addresses from storage will cost 4000 gas, not including any overhead. The Istanbul hardfork also included EIP-2028, which lowered the cost of non-zero calldata bytes from 68 to 16. These two EIPS are what cause the huge difference ...


2

With ERC-20 you cannot do this. You cannot extend the capabilities of an existing smart contract, especially if it is owned by a third party. ERC-777 specifies a token receive interface that smart contracts can implement. A receiving smart contract implements ERC777TokensRecipient interface and can react to incoming ERC-777 send() calls. A tutorial: https://...


2

You're installing the last version from apt. It's much easy to install the specific version of solc with docker, here is an example: ## Download Docker image docker pull ethereum/solc:0.4.24 ## Usage: docker run --rm -v $(pwd):/root ethereum/solc:0.4.24 <command_here> # To generate ABI file from .sol file and send output to ./build folder docker run --...


2

As @goodvibration was saying, you always create different instances. So the byteCode is duplicated and thus costs always the same amount of gas. To avoid this you could use a clone factory: https://github.com/optionality/clone-factory. It creates a new contract which delegates all calls to the given library contract. The library is only deployed once, so the ...


1

Might sound silly, but are you sure you are not redeploying the contract on the restart? Make sure you are working on the same contract with the same state (data). If yes then you can try replacing your current validation with this one: require(bytes(hash).length > 0, "Empty hash!"); require(bytes(hashAlreadyRegistered[hash]).length == 0, &...


1

If the now is off more than 2 minutes (or was it 3 minutes), the network rejects the block from the miner. It is accurate enough for "meeting start time" or "sale start time" like objectives.


1

When I try to run this code on remix it gave UnimplementedFeatureError: Not yet implemented - FixedPointType. Which you can see here This is not possible to use uint(3/30) as you are doing. Casting of any floating point using uint is not acceptable. The Fixed Point are not yet unuseable in solidity as it documentation says: Fixed point numbers are not ...


1

It is a very general question, so a very general answer. Try-catch is a logical branching technique, and logic errors can have serious security implications. What implications can it have to the security of a function A function should always do exactly what it is supposed to do, in all cases. That should be obvious. It is not always wrong to try-...


1

I think you might be thinking about a general pattern Nick Johnson first wrote about, Amortized Work, https://medium.com/@weka/dividend-bearing-tokens-on-ethereum-42d01c710657 The general idea is to use queues (or conditions) to execute small units of work whenever gas is available. You can use that for garbage collection and other housekeeping/maintenance ...


1

Your contract is not ERC20-compliant. More specifically, it does not implement function balanceOf as dictated by the standard: Returns the account balance of another account with address _owner. function balanceOf(address _owner) public view returns (uint256 balance) I noticed that you have implemented something similar in your contract: function ...


1

A variable cannot be set as null or undefined because the EVM does not have a concept of null. When a variable is declared, it initially contains the zero-equivalent of it's given type. From the Solidity documentation on types: The concept of “undefined” or “null” values does not exist in Solidity, but newly declared variables always have a default value ...


1

'in' is a Reserved Keyword. This keyword are reserved in Solidity. They might become part of the syntax in the future.Check this link But you can loop through an array/list in different way. Compared to python. address[] public arraylist; // Creating a list of '**address**' type arraylist.push(newAddress); //Adding elements to array. ... // Length of ...


1

I see from:<sender_address> but to:<contract_address>. This is because you've sent a transaction from <sender_address> to <contract_address>. The <contract_address> balance is 0 and remains 0. This is because the contract function transfers the received amount to <beneficiary_account>. What is the difference ...


1

What you can do is bind the opening and closing to a timestamp. Transactions have access to the current timestamp with now so you can simply compare that to the values you want. So something like: require(1234 <= now && now <= 12345). Keep in mind that miners have some freedom when setting the exact timestamp. So if the stakes are high enough ...


1

The reason you got that error because there is no function name payable that take an integer value and return payable address. The parser doesn't recognise it and give you an error like that. I don't know your complainMap struct but i can guess that in it contain contrivutor variable and it's type is address. In solidity version greater than 0.5.0 they add ...


Only top voted, non community-wiki answers of a minimum length are eligible