@MicahZoltu -- continuing our conversation from the EIPs channel. I didn't quite get why you thought an ERP restoring code was more of a "one off" solution that one that transfers funds. My main goal is to have a process where we could can as sure as possible that "the right" thing is happening. In the case of the Multisigs, putting back the contract code is really easy to implement, really easy to verify, and restores access to more than just ETH (tokens, or even any special access permissions that were granted to a multisig by another contract).
Each client having code that generically deals with "recovery during hard fork" by just supplying it with a list of addresses to give money to is a one-time client implementation that can just be fed data during a hard fork many times in the future.
Recovering contract code would require clients implement contract code recovery, only to use it a single time for the parity multisig.
The issue is that it is two solutions instead of one.
Even if both solutions are equally trivial to implement, it is still twice the complexity.
And since the eth transfer thing can solve the Parity multisig problem and a whole swatch of other problems (because it is more generalized) I prefer it over having two separate solutions for that same set of problems.
@phiferd I recommend adding to your document off-by-a-little addresses. The script would look for addresses with ETH that are less than 8 contiguous bits different from an address that has transactions or contract code and transfering the ETH from the former to the latter.
I would also recommend another one for locating double precision truncation errors, where ETH is in an address that is the double precision truncation of an address that has transactions or a contract (there is one known big loss from this, I suspect a handful of smaller losses).
well, it's not twice the complexity -- it's the difference between a hundred lines of code and a hundred plus 2 (or maybe it's 5, I don't know). I think writing code to a particular address as part of an irregular state change could be useful in the future as well, not just for self-destruct.
Hmm. Gitter tried to pull in the gist and is not handling it well...
https://gist.github.com/mjmau/e073091446751b08762c8c65ae13a37d
That doesn't mean code never existed at the address, just that it doesn't exist today. Self destruct can make it so that code which existed previously no longer exists today.
short of an irregular state change, I'm trying to figure out how a contract could be created with no code (checked by
!tx.to && tx.input === '0x') but then have code added later.
Or 32-35 for that matter.
Ah, I see. it is a hack to try to detect failed transactions.
That should probably be cleaned up for production since it is an unreliable check.
I suppose it does err on the side of caution though, so you could launch with it and be fine.
New recovery proposal idea for anyone that wants to draft it up (CC0, don't even need to give me credit): Add a new opcode that drains all ETH from one address to another when the two addresses are sufficiently close to each other (binary edit distance). There are a couple classes of ETH that could be solved by this and it provides a permanent solution to the typo/truncation problem.
TBD: How to make sure the transfers go the right direction and people don't use it to troll/be a neusence?
I mean, where a smart contract is
A.
I guess it could check to see if
A has code associated with it or A has transactions signed by it?
If so, then a transfer from
A' to A can be initiated (gas paid for) by anyone.
better solution would be to implement new address format that would have redundancy
problem with ENS is that its voluntary, new address format would be mandatory (given that users would adapt it to their software)
I just stumbled on this. I don’t know if its of relevance. https://medium.com/bitclave/how-we-sent-eth-to-the-wrong-address-and-successfully-recovered-them-2fc18e09d8f6
There is a certain class of user errors that can be recovered relating to people using test accounts/contracts on main net on accident.