Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Greg Colvin
    @gcolvin
    Aha. Say X and Y used to call Z and Z went away, holding a key of Y’s in its storage. Now Z gets replaced by the evil ZZ. X accepts ZZ and calls it, and ZZ proceeds to grab the key that Y gave it and do some damage?
    Federico Bond
    @federicobond
    Yes, I think we are talking about the same thing. Y may reject evil ZZ, but as long as X can perform a transaction in C that delegatecalls to the redirected contract, ZZ can then proceed to update storage locations that involve Y’s assets held in C.
    Greg Colvin
    @gcolvin
    One should never trust another contract to hold your assets. But yes, this kills my idea.
    Greg Colvin
    @gcolvin
    @Arachnid I’m sorry I failed to surprise you.
    "I cannot think of any variant of the replacing deleted contracts suggestion that isn't a terrible idea I will fight tooth and nail against introducing, though
    But I'm always happy to be surprised.”
    Martin Holst Swende
    @holiman
    @gcolvin Yeah, so the problem is User callsX. X holds balance. X delegatecalls Y, whereupon Y-code acts within the context of X. Now Y is dead, and X cannot signal anything, it's hardcoded to only perform one specific delegatecall to Y.
    Greg Colvin
    @gcolvin
    Aarrgghh...
    RorschachRev
    @RorschachRev
    If the ABI is the same or almost the same, and the code has one or two line changes, I think the introduction of "new backdoors" would be very difficult. While the entire contract would need some scrutiny, the main attention should be on the changes made. Instead of comparing two sets of disassembled code, it would be much faster to compare 2 sets of source code. I think pricing and barrier to entry should reflect this. Injecting a new upgrade architecture into contracts that don't have it is a huge mess of permissions, private keys, contract ownership v contract control v funds managed. I love the idea of upgradable contracts, but that should already be in the contract or they use existing permissions to manually move the funds to a newer version of the contract at a different address. Limiting the contract insertion to "stuck ETH" makes the most sense, despite how appealing other features may be.
    Micah Zoltu
    @MicahZoltu
    I have been out for several days and will likely not have time to read backschat. However, I would like to express that I generally side with @Arachnid (which I have argued elsewhere) that we (community, dev ecosystem, etc.) would be better off if we just included a hard fork with a hard-coded list of addresses to "mint" Ether for. Determining the list would be an off-chain concensus and should only include Ether that was lost due to typos/bugs.
    We would need a process for submitting such proposals and reviewing them (which is a lot of legwork) but presumably anything that could be handled by something like EIP 156 could be vetted/found in an automated way with this, but this could also solve Parity lost funds, the ICO that had the truncated address a while back, etc. which cannot be easily "proven" on-chain but is very easy to prove off-chain.
    RorschachRev
    @RorschachRev
    That is what I call a "dirty" hard fork, and it would need to be offered to a large number of people. They would need to be able to pass a wallet verification challenge, and demonstrate something regarding why the ether was lost in the first place
    I would do my absolute best to campaign against Parity getting paid Ether.
    Micah Zoltu
    @MicahZoltu
    In its most constrained form it only does whatever EIP156 does, which presumably can be fully automated.
    Yet, it introduces almost no EVM complexity like EIP156 does.
    RorschachRev
    @RorschachRev
    EIP156 doesn't cover most of the issues I've read about.
    Micah Zoltu
    @MicahZoltu
    From there, we can discuss how far we want to take it. Do we want to include "obvious typos" that cannot be mathematically proven but all humans agree were typos? Do we want to include Parity wallet bug? etc.
    Agreed. My point was just that a dirty fork can solve any set of problems in this class with lower complexity than any other solution to the same set of problems.
    And I will always pick the solution with lower complexity.
    The exact set of problems we want to fix with a dirty fork is a separate discussios that we need to have, certainly.
    RorschachRev
    @RorschachRev
    Lowest complexity: get a bank account
    Micah Zoltu
    @MicahZoltu
    Having had a bank account, I can assert that is not the lowest complexity solution. :)
    RorschachRev
    @RorschachRev
    People have (in this chat) argued that we should embrace Ethereum Foundation having all the powers of a bank, including restoring funds, moving funds, correcting addresses, etc.
    In which case, those people should go get a bank account and not use blockchain.
    Micah Zoltu
    @MicahZoltu
    However, the point you are trying to make I believe holds. If you are arguing that "code is law" and we should not change law and therefor we should not recover any funds I think that argument also has merit.

    Options:

    1. Do not recover anything.
    2. Recover with dirty fork.
    3. Recover with EVM behavior change.

    I'm strongly against (3). I would be content with either (1) or (2) and I think each has merit in its own right.

    RorschachRev
    @RorschachRev
    I think we need more client side checks, and use technology to double check what we intended. The use of checksums is an easy "anti-typo" system. A white list in full node wallet s would allow an address lookup. If these technologies are created, function well, and the typo+fail quickly approach zero, then maybe we could possibly consider solving historical issues. If Ethereum Foundation needs to do a hard fork ever 3-12 months in order to move funds around, we're using Bank of Ethereum.
    Micah Zoltu
    @MicahZoltu
    As long as humans are writing new code, I suspect there will be no end to novel new ways to lose money.
    Jim McDonald
    @mcdee
    Someone in the Ethereum Foundation needs to write (and debate) a statement of intent for how Ethereum handles lost money situations. Once they have that the the technical processes (or not) should flow from there but arguing bottom-up isn't going to get anywhere as there are a decent spread of opinions across the spectrum
    Micah Zoltu
    @MicahZoltu
    I do think that there is value in adding protections against common sources of losses (like typos), but I don't necessarily think every mistake needs to have security measures put into place. The Parity bug, for example, is pretty isolated and I think adding EVM complexity to prevent a repeat of that exact situation is overkill.
    RorschachRev
    @RorschachRev
    I don't think Parity situation should involve EVM changes. Personally I think that they broke the law and should be investigated for breaking the law.
    I don't mean "Code is law and you wrote bad code" I mean, the FBI should arrest them.
    Nick Johnson
    @Arachnid

    @RorschachRev People have (in this chat) argued that we should embrace Ethereum Foundation having all the powers of a bank, including restoring funds, moving funds, correcting addresses, etc.

    I would like a citation for this, please.

    iFA
    @iFA88
    You can do everything with the client (deleting address balances, moving funds..) if the community accepts that and uses the client
    Nick Johnson
    @Arachnid
    This message was deleted
    Micah Zoltu
    @MicahZoltu
    @mcdee I suspect the EF won't make any public move until after they believe there is concensus from "the community" (as ill defined as that is). I have been outspoken against this strategy of the EF in the past, and my stance hasn't changed but I do think that is the "current process".
    Nick Johnson
    @Arachnid
    @MicahZoltu What would you prefer?
    RorschachRev
    @RorschachRev
    @Arachnid I will scroll up and get it, the person was not working at EF.
    Nick Johnson
    @Arachnid
    @mcdee There's no reason the EF would need to do that - anyone can write such a proposal and look for community support of it.
    Dexaran
    @Dexaran

    @iFA

    You can do everything with the client (deleting address balances, moving funds..) if the community accepts that and uses the client

    100% community consensus is just impossible.

    Nick Johnson
    @Arachnid
    That is not even close to what you claim it is.
    Micah Zoltu
    @MicahZoltu
    I think there is significant value in having centralized vision and leadership. I'm not a believer in the whole" community concensus" thing because I don't think humans tend to come to concensus on complex subjects, but they will follow strong leadership even when they disagree because they see value in network effects and trusting a proven leader.
    Nick Johnson
    @Arachnid
    @MicahZoltu I think the IETF is an existence proof of the ability for humans to come to consensus on complex things :)
    Jim McDonald
    @mcdee
    @Arachnid sure, but it would be nice for the EF to take some sort of leadership position here, even if it is just to broadly lay out the positions and give the community a framework around which to discuss
    Nick Johnson
    @Arachnid
    @mcdee Isn't that what it's already done, with Vitalik's initial draft of 156, and by creating this channel?
    Micah Zoltu
    @MicahZoltu
    My understanding is that the IETF standards process doesn't move at the speed of business. It is a trailing thing. Cryptoscurrency is in its infancy and if you don't move fast you die to a competitor. We can't afford to have a standards process that takes decades.
    iFA
    @iFA88
    @Dexaran Hey dexaran :) It is not require that every person accept that fork
    Nick Johnson
    @Arachnid
    @MicahZoltu No consensus process is nimble, but the IETF certainly doesn't take "decades"
    Micah Zoltu
    @MicahZoltu
    I don't think any crypto-currency can really afford to not be nimble at this phase. Maybe in 5 or 10 years when things have matured and stabalized, but right now things are simply moving too fast to be able to do the whole "community concensus" thing and not die.
    RorschachRev
    @RorschachRev
    @Arachnid November 15, "pretext" said many things, summarized by him saying, "No, merely that we could use experience from 'bank recovery and resolution' matters to improve things that many people dislike." He told stories about how great it was that his bank forwarded his rent to the correct address, how they restored his money several times, etc. We did not agree on much.
    Micah Zoltu
    @MicahZoltu
    Also, doesnt't the IETF have a core committee (e.g., leadership)?
    Dexaran
    @Dexaran
    @iFA88
    We must not violate the previous "rules" (protocol) if at least one person is against it. If not, then what's the value of this blockchain as an immutable and censorship-resistant history of transactions (execution)?