Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Bob Summerwill
    @bobsummerwill

    No - it is to discuss the subset of EIPs which are related to various types of trapped ether. Mainly covered in EIP156, plus the pending EIP from Marek, and maybe more.

    That discussion could happen in https://gitter.im/ethereum/EIPs, but is likely to be contentious and of very broad interest. Nick suggested a new channel specifically for this subset of EIPs to avoid ruining the signal-to-noise ratio in the existing channels.

    Bob Summerwill
    @bobsummerwill
    @kjameslubin @liorsaar1 @batlinal @marleyg @patrickmn @conor10 @joelburget @tylobban @jpmsam @juanfranblanco @shahankhatch @christianlundkvist @danfinlay @ililic @jeffscottward @jmlubin @jo-tud @juanfranblanco @maurelian @mbeylin @niran @pelle @petermunnings @pospi @raineorshine @rverbee @rusthomas @ryanreich @hughlang @jakelang @s-matthew-english @samcassatt @simonlapscher @tcsiwula @timjlowe @tueric @tyndallm @wuehler @zigguratt @zmitton @dominicwilliams @timohanke @hdiedrich @leithaus @brianbehlendorf @christo4ferris @compleatang @zramsay @benjaminbollen @j-h-scheufen @silasdavis @shuangjj @phonikg @ryan-orr

    OK - done with invites.

    Does that make sense, @LefterisJP? Or do you think that all discussion around EIPs should just be directly in https://gitter.im/ethereum/EIPs?

    Are you in favor of mailing lists over Gitter for this kind of strategic discussion? Greg's point is that archiving and discoverability of these kind of WHY questions is crucially important. He can search through years of dialog on all kinds of tricky edge-cases within the C++ standard, because everything was done via mailing lists. But he has no clue how decisions were reached on various points within Ethereum because the communication is so disorganized and hard to search through.

    chriseth
    @chriseth
    Bob, do you really think that mentioning every single person you know in the Ethereum ecosystem is a good way to handle this?
    Bob Summerwill
    @bobsummerwill
    Yes.
    Would you seek to exclude people from this crucial discussion, Christian? I am sure that only the interested subset will participate. There is nobody in that list of people who is a bystander. These are people with a very active stake.
    @mkalinin @Nashatyrev Sorry, Harmony team. Forgot you.
    axelay
    @axelay
    Thanks for the intro Bob - let's get this into the open
    Rocky Fikki
    @rfikki
    My first few questions are why does it seem pertinent(more critical) when close nit participants/developers have issues with smart contracts that we need hard forks / soft forks in order to recover ether from? Why is there not any of this urgency and movement when less known projects / teams have issues that need attending with regards to locked/lost ether. When are issues with smart contracts too small to be considered for such fixing?
    Greg Colvin
    @gcolvin
    We are try to make all lost ether recoverable. It won't be easy.
    Tim Siwula
    @timxor
    Any ideas or mechanisms on how to recover all that frozen eth?
    Greg Colvin
    @gcolvin
    EIP 156 is one. Another is to allow the owner of a suicided contract to replace it. The latter presents difficulties because the new contract will have all the powers of the old one, but not necessarily the same behavior.
    Greg Colvin
    @gcolvin
    So if the contract controls someone else's ETH, it gets control of that ETH, but cannot be counted on to return it to its owner. This is arguably better than having the ETH locked away completely. But there are other cases that are worse than leaving the owners ETH locked up. @Arachnid can explain those better than I. I've wondered whether it would be possible to recover a copy of the blockchain before the latest lossage and analyze whether any such cases actually exist, but it's beyond my skill.
    And that's all I have to offer for now @tcsiwula.
    Tim Siwula
    @timxor
    Hmm pretty intresting. Do you what the steps were to recover ether from this smart contract a few months ago? https://etherscan.io/address/0x1dba1131000664b884a1ba238464159892252d3a
    @gcolvin
    Greg Colvin
    @gcolvin
    No, I don't. That is, I don't know the technical details. It was a white hat operation, which generally involves exploiting bugs in a contract to get funds that have been or could be stolen to a safe place.
    That is not what we are up to.
    Tim Siwula
    @timxor
    Ahh got ya. Let me read over that eip and try to get a better understanding.
    Bob Summerwill
    @bobsummerwill

    @rfikki My expectation is that we will either proceed with some set of EIPs which allow the recovery of as broad a set of common trapped funds scenarios as possible without compromising security - or that we proceed with none of them. And that would be a HF scenario for the community to decide on.

    @mwilcoxnz has been harping on this point for quite a while, which is that protocol changes should treat all parties equivalently. An attack on one is an attack on all. So, we should look to favor generic solutions over specific solutions.

    Adding generically useful recovery features is probably uncontroversial. Adding "If address = paritylibrary then recover" ... not so much. That kind of targeted fix is safer, but is a tyranny of the majority / picking a winner scenario.

    And is exactly what happened with the DAO.

    CC @AFDudley @FaceDeer @realcodywburns

    Mark reminded me of this hypothetical discussion from a few months ago, which is not so hypothetical anymore. It isn't quite the same scenario, but it is close:

    https://www.reddit.com/r/ethereum/comments/6izcy5/lets_discuss_would_we_hardfork_to_address/?st=ja0k5iii&sh=a506ea61

    Nick Johnson
    @Arachnid
    I'm skeptical there are any generic fixes that recover Parity's lost funds without introducing detrimental changes - but I'd be happy to be proven wrong. I'm firmly against the various "un-self-destruct" proposals I've seen put forward so far.
    Unlike others, though, I'm okay with a list of "recovery actions" in an HF that include specific addresses to recover funds from.
    They don't introduce any long-term change to the EVM, and what complexity they introduce is restricted to a single state transition.
    I'm even more of a fan of the idea of tokenising lost ether, though. I think it's quite an elegant solution, if you can provide a way to prove to the token contract that you ought to own the ether.
    Martin Holst Swende
    @holiman

    So, I'll discuss technical things, but with a few caveats:

    • Anything I say in regards to technical proposals or ideas, do not mean that I assume that a HF will follow.
    • The decision about HF or no HF is up to the community.
    • In the event that it comes to such a choice, my preference will be that the clients are default-free, forcing users to make an explicit fork-choice.

    The only public proposal as of yet, afaik, is EIP 156, to which I have made a suggested amendment.

    Here's the short about EIP156 (and I'm talking about v2):

    • In it's current form, can be implemented at any time. It creates contracts which allow certain types of lost ether to be represented by a token, futureToken. The claimants can make their claim by submitting proofs which can be verified on-chain. The current proposal covers:

    • Contracts that are accidentally created with no code (but prefunded with value),

    • Losses due to an old ethereum javascript library that incorrectly computed ethereum addresses

    Note that in all cases, the "rightful owner" of the assets is obvious and mathematically provable, and no user is being deprived of any assets, and this proposal provides no explicit favor to any single account, user or application.

    Regarding my proposed amendment

    • Would cover dead parity wallets. The proposal is based on hardcoding the hash of the affected wallet(s), and attributing the creator with the balance on the wallet.
      • Unfortunately, I do not see a way to avoid basing it on specific hashes.
      • Even if there is a way to on-chain verify that contract x is incapable of transmitting ether (e.g.: no CALL and only DELEGATECALL to accounts without code), I don't feel comfortable attributing such ether to the creator in the general case. For example, the QuadrigaCX incident with the funds locked in "ReplaySafeSplit" would be given to the creator of the splitter library. I'm afraid that doing such a solution would make the creator a target for multi-million dollar lawsuit - and what if that person doesn't even have the key anymore(?).
    • Would not be able to recover trapped ERC20 tokens.
    • Would not restore wallet ownership, but attribute full ownership to creator.

    As I said, these contracts could be implememented at any point. A future hardfork could endow the contract with ether corresponding to the tokens, which could then be redeemed.

    The idea to tokenize lost assets is IMO rather elegant. There is also another interesting aspect, the idea to make these tokens tradeable. In that case, it would be open to speculate on whether a future HF is likely, and perhaps risk-averse holders could recover (some) of their losses long before a HF ever takes place. Maybe the token value could even be used as some voting-mechanism about HF. I don't know, haven't investigated the game-theory behind that, but it's an interesting thought.

    Yoichi Hirai
    @pirapira
    I believe reckless users should be punished although I can tolerate nicer treatments for a while.
    Lefteris Karapetsas
    @LefterisJP

    The idea to tokenize lost assets is IMO rather elegant. There is also another interesting aspect, the idea to make these tokens tradeable

    I am not sure I understand how such a token would have value. Without an HF to restore the lost funds what would provide value to such a token?

    Marek Kotewicz
    @debris
    Only speculation. Such tokens would be securities
    Lefteris Karapetsas
    @LefterisJP
    Aha so exactly same thing as bitfinex did after its hack
    Marek Kotewicz
    @debris
    Yes, although it would be slightly less shady
    Nick Johnson
    @Arachnid
    Nothing.
    More than slightly less shady ;)
    Marek Kotewicz
    @debris
    yes, there would be definitely more transparency, but it the same time, no guarantee that those tokens will ever be recovered ;)
    Nick Johnson
    @Arachnid
    That's right.
    How would people feel about the idea of extending 156 to cover sends to addresses that are a single nybble different from a claimant address?
    Eg, to cover easily demonstrable typos?
    axelay
    @axelay
    There are indeed several actions that resulted in locked Ether - a good starting point would be to itemize them and that should give a clearer picture of what can be done depending on each case scenario. For example Ether sent to 0x0 addresses should be the most straight-forward ones, then evolving onto more complex cases.
    Nick Johnson
    @Arachnid
    Actually, sends to 0 are more complex than some other cases already enumerated, because it's harder to prove onchain.
    (EG, 0 has ether from many accounts, while an address that differs only in one nybble from a valid one has ether owned by only one account)
    axelay
    @axelay
    I stand corrected then - thus the idea of enumerating the scenarios and potentials fixes for them
    Nick Johnson
    @Arachnid
    Yup, I agree.
    Tim Siwula
    @timxor
    haha, kinda agree with @pirapira view 🤪
    Greg Colvin
    @gcolvin
    @holiman Could you say more about the QuadrigaCX incident and the problems it presents? My thinking was that getting locked funds exposed to the various means of resolving human disputes was better than leaving them locked up. Would this be a case of an innocent party being exposed to litigation?
    Martin Holst Swende
    @holiman
    Someone deployed a horrible splitter, which did not implement a default method whicg threw. This was before thw modifier payable became required to accept money. Much later, they called splitter with bad method sig, which then became stranded
    axelay
    @axelay
    QuadrigaCX is not the creator of the contract either - making the situation even more delicate
    Martin Holst Swende
    @holiman
    Right
    Greg Colvin
    @gcolvin
    OK, whose ETH is stranded, and who would control it if they replaced a deleted contract?
    Gabriele Rigo
    @gabririgo
    I have 10 Ether stuck in gavcoin, will I be able to recover them or is it an isolated case which is not meant to be discussed as not of general relevance?