3 ms·

The code is immutable, but Ethereum has a functionality called "suicide" by which a contract can, well, commit suicide. It is kind of like a deletion, in that t

The code is immutable, but Ethereum has a functionality called "suicide" by which a contract can, well, commit suicide. It is kind of like a deletion, in that the code can't be executed anymore afterwards, but of course the blockchain still contains the contract in its original, unmodified form. AFAIK this feature was introduced to make owners capable of deactivating contracts which contain known security bugs (so at least nobody can accidentially send any more money to those contracts). And because that's the intended purpose, a suicide is non-revokable, so a dead contract remains dead forever. A library apparently can be nuked because Ethereum does not explicitly have a concept of "libraries". They are after all just contracts, with the only difference being that they are intended to be called by other contracts instead of humans. I see the next controversial, but eventually Vitalik-blessed hard fork incoming...

bhaak 9y ago
> A library apparently can be nuked because Ethereum does not explicitly have a concept of "libraries". They are after all just contracts, with the only difference being that they are intended to be called by other contracts instead of humans. That's not correct. There is a construct "library" that is different from a normal contract. But the code in question didn't use that (for whatever reason). http://solidity.readthedocs.io/en/develop/contracts.html#libraries http://solidity.readthedocs.io/en/develop/contracts.html#lib... > I see the next controversial, but eventually Vitalik-blessed hard fork incoming... I wouldn't be so sure. It's only about 1% of all ETH and the funds are frozen. The DAO hack was ~15% and would have put those funds into the hand of a single entity which would endangered the eventual move to PoS.
- Slartie 9y ago
  > That's not correct. There is a construct "library" that is different from a normal contract. But the code in question didn't use that (for whatever reason). Thanks for pointing me to this! Didn't know that yet...but in that case I'm really wondering why this strange "library" from Parity even worked the way it did...? If it's necessary to use the library construct in order to have the code not access its own contracts' data storage and funds, but those of the calling contract (this is at least how I understand the description you linked to), how could the Parity library even work the way it did without this construct?
  - bhaak 9y ago
    You can always call public methods from other contracts regardless what construct you use. The library construct is a Solidity implementation detail but you can also use normal contracts, like they did in this case. So far, it really looks like almost a criminal sloppy refactoring of the official multi sig contract from the EF that has been extensively audited.
- deleted 9y ago
  [deleted]
- AgentME 9y ago
  As far as I know, Solidity "library" is practically just syntax-sugar for exactly what Parity's wallet was doing already. It wouldn't have prevented the library-contract from suiciding.

bhaak 9y ago

> A library apparently can be nuked because Ethereum does not explicitly have a concept of "libraries". They are after all just contracts, with the only difference being that they are intended to be called by other contracts instead of humans. That's not correct. There is a construct "library" that is different from a normal contract. But the code in question didn't use that (for whatever reason). http://solidity.readthedocs.io/en/develop/contracts.html#libraries http://solidity.readthedocs.io/en/develop/contracts.html#lib... > I see the next controversial, but eventually Vitalik-blessed hard fork incoming... I wouldn't be so sure. It's only about 1% of all ETH and the funds are frozen. The DAO hack was ~15% and would have put those funds into the hand of a single entity which would endangered the eventual move to PoS.

Slartie 9y ago
> That's not correct. There is a construct "library" that is different from a normal contract. But the code in question didn't use that (for whatever reason). Thanks for pointing me to this! Didn't know that yet...but in that case I'm really wondering why this strange "library" from Parity even worked the way it did...? If it's necessary to use the library construct in order to have the code not access its own contracts' data storage and funds, but those of the calling contract (this is at least how I understand the description you linked to), how could the Parity library even work the way it did without this construct?
- bhaak 9y ago
  You can always call public methods from other contracts regardless what construct you use. The library construct is a Solidity implementation detail but you can also use normal contracts, like they did in this case. So far, it really looks like almost a criminal sloppy refactoring of the official multi sig contract from the EF that has been extensively audited.
deleted 9y ago
[deleted]
AgentME 9y ago
As far as I know, Solidity "library" is practically just syntax-sugar for exactly what Parity's wallet was doing already. It wouldn't have prevented the library-contract from suiciding.