49

Selfdestructs in Ethereum are an operation (an OPCODE actually) at the EVM level, independent of what language or client you are using. For example, calling selfdestruct(address) sends all of the contract's current balance to address. This is useful when you are finished with a contract, because it costs far less gas than just sending the balance with ...


37

Note: this question originally asked about the suicide opcode, which has become selfdestruct in the meantime as per EIP6. selfdestruct is the encouraged term and may be found in newer Solidity and Serpent code. It is the same API and behavior, as described in the other answers, and is an alias for suicide. EIP6 describes the motivation: The primary ...


28

You can not return a struct because Solidity implements them only as a loose bag of variables, they are not real objects. You can use a solution from this answer: https://ethereum.stackexchange.com/a/3614/264 Update Since 0.4.17 you can use pragma experimental ABIEncoderV2 to return structs. Of course, until the experimental keyword is removed, it's not ...


24

The selfdestruct() function and the relative OPCODE are used when you have a contract that has a bug or an unwanted behaviour and you want to get rid of it. The selfdestruct(address) is a better version as @tjaden-hess pointed out, when you have a payable contracts (contracts that receive ethers) the ethers will be redirected to address which is a big win. ...


11

If I'm not mistaken, the docs are a little misleading on this point. A lot of danger around the illusion of safe destruction. Immutability wins over "delete". Nothing really gets destroyed. Blockchain has no concept that corresponds to overwrite like DB or a disk. It can only ever add changes to what it had before. If data, or a contract was ever present, ...


7

To start my answer, I have to say that once you put something on the blockchain it is "immutable", and by that I mean that it can not be modified or deleted. (there is a special type of "upgradable" contracts but this is not the answer for that) You can find here a lot of information about self-destruction. Why would you need to destroy others? For ...


6

No, if there is no code in the contract to suicide it then there is no way to destroy it. This is deliberate: People or other contracts have to know in advance whether it will still be there in the future, so it shouldn't be possible for someone to destroy it unless it included code that allows it to be destroyed. If there is no code in the contract ...


6

EDIT: I tried but realized I don't have the answer to "If the contract's data is removed to free up space, then surely the block in which it resides changes, and therefore that block's hash also changes. Wouldn't this therefore mean changing all subsequent blocks that rely on this hash?" Leaving this here in case it helps others explain. Each block has a "...


5

selfdestruct clears all the contract's data, it frees up space on the blockchain (exactly from the current and future state tree (a Merkle patricia tree) not from the previous blocks, the contract bytecode will remain in a old block but its account will be no longer accessible). we talk about freeing space because there will be no entry for the contract in ...


5

Ancient history, but here goes :-) There was one coordinating contract for the initial attack. A later version had a more complex algorithm to generate the empty account addresses, presumably to try to frustrate any future clean-up effort. This one just incrementally worked through the address space. Every time the coordinating contract was called - and it ...


5

No, there are no contract invocations with a selfdestruct (suicide), so there is no possibility of reentrancy. There are no CALLs as you've noted and the Geth code you've quoted is correct.


5

No In your function that calls selfdestruct(owner), you would also need need to call the (ERC20) token's contract transfer function. The code would look like: SomeToken tok = SomeToken(tokenAddress); uint tokenBalance = tok.balanceOf(address(this)); tok.transfer(owner, tokenBalance); Make sure that owner is an externally owned account (EOA) or a contract ...


4

Ethereum smart contracts are immutable. You cannot change their source code once they are deployed. You should have included the kill/suicide/selfdestruct code before deployment. However, I see two functions in the ABI that might be useful, one is safeWithdrawal and the other is ifSuccessfulSendTo. The second one is a variable I guess, but it looks like the ...


4

No, the address of a contract depends on the nonce of the sender. As you are creating a new transaction, your nonce will be different and the contract will be deployed in a new address.


4

A SUICIDE operation is effective at the end of the transaction. I can replicate the issue, so it likely is a bug in the geth traceTransaction implementation, where the other prior transactions in the block are not taken into account. Edit: this bug has been fixed


4

From the Ethereum Yellow Paper Section 4, page 3: 4.1. World State. The world state (state), is a mapping between addresses (160-bit identifiers) and account states (a data structure serialised as RLP, see Appendix ??). Though not stored on the blockchain, it is assumed that the implementation will maintain this mapping in a mod- ified Merkle ...


4

This will only work when the struct is passed around within the contract via the use of internal function calls. Even using ABIEncoderV2, when attempting to return a struct via a public or external function will give the following error: error: Failed to decode output: Error: Unsupported or invalid type: tuple


4

Passing structs is available in 0.4.17 with pragma experimental ABIEncoderV2. See https://github.com/ethereum/solidity/issues/40


4

No. selfdestruct of a contract does not effect any contracts created by the contract to be destroyed.


4

Elsewhere in the contract, find address admin; and declare it as address payable admin;. Alternatively, selfdestruct(msg.sender); because require(msg.sender == admin); ensures they are the same and msg.sender should be payable. A word of caution. selfdestruct is an inelegant way to stop a contract and could lead to non-trivial problems. Consider using ...


4

It may depend on what your definition of "contract" is. :-) Once a contract is selfdestructed, there is no code at that address anymore, so it can't execute a SELFDESTRUCT again. However, due to the existence of CREATE2, you can now potentially deploy new code to the same address as the previous contract. That new code could contain a SELFDESTRUCT opcode. ...


3

2 cases: outside and inside the Ethereum Virtual Machine (EVM). Outside the EVM Yes, race is possible if eth.getCode is used. eth.getCode is Javascript and is outside of a contract and the EVM. So after eth.getCode, the next block that your Ethereum client receives, could have a transaction that invoked selfdestruct on the (greeter) contract. Inside the ...


3

You can call getCode (web3.eth.getCode(address)). The call will return 0x if it selfdestruct'd. Note that this isn't a positive way to know it selfdestruct'd, it'll also return 0x if it's an EOA or the contract was created with no code.


2

The "should" depends on the use case. Your question does not specify any exact use case. Ethereum allows both kind of contracts. You can create upgradeable or non-upgradeable contracts. The developers are free to choose and craft contract rules they feel is the best fit.


2

Should I remove the old one? If there's no chance of either yourself or anyone else sending funds to it, then yes - it's a nice bit of housekeeping. Sending funds to a payable contract that has been selfdestruct()ed is basically sending them into a black hole. Removing a contract itself is another transaction so the best I can do seems like leaving it ...


2

It does not look like you have any function included in the contract that makes the contract "killable" or mortal. As Ethereum contracts are immutable as soon as they are deployed to the Blockchain there is no way to add a kill method after they are deployed. For your future contracts I'd recommend you to inherit from a mortal contract that specifies the ...


2

You can't send the result of selfdestruct to multiple parties. What you could do is self-destruct to the address of another contract, and put the splitting logic in that contract. However, unlike a normal payment to a contract, selfdestruct doesn't automatically invoke the fallback function, so you can't do any splitting in that call. You'd have to simply ...


2

You should be safe as the cleanup method seems to be only executable by the owner of the contract (has the onlyOwner modifier, which I guess checks msg.sender == owner). What the linked article refers to is the possibility of another contract inadvertently calling a function on a second contract (which contains a selfdestruct call) using delegatecall, in ...


2

For the source code, you can check Parity's repo. To get the bytecode, do something like: const Web3 = require("web3"); const web3 = new Web3(new Web3.providers.HttpProvider("https://mainnet.infura.io/")); const deadContractAddress = "0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4"; const blockAtDestruct = 4501969; const blockBeforeDestruct = blockAtDestruct - ...


2

What that warning is telling you is that you should be careful with deploying your contract which can selfdestruct and having other contracts depend on it. If you have contract B which calls a function on contract A and contract A is selfdestructed, then contract B will stop working. If you have a contract with a function that selfdestructs, there are two ...


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