Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Feb 28 2019 19:45
    @Arachnid banned @merkle_tree_twitter
  • Feb 17 2019 00:56
    @jpitts banned @Aquentson_twitter
  • Apr 09 2018 04:14
    @holiman banned @JennyJennywren_twitter
  • Oct 21 2017 19:12
    @Arachnid banned @Musk11
Alex Beregszaszi
@axic
LOG* is the major reason token contracts would have code in the “fallback” function
Micah Zoltu
@MicahZoltu
Yeah. The inability to log is quite unfortunate.
Make .transfer be KINDA_STATIC_CALL, which allows LOG*. :wink:
Alex Beregszaszi
@axic
I’m sure it is possible to formulate a proper EIP defining this special case how to execute a function which only has the stipend, but it is not as simple as saying “it turns into a staticcall”.
Micah Zoltu
@MicahZoltu
:thumbsup:
Geoff Hayes
@hayesgm
I honestly think the best long-term solution here would be to allow contracts to specify an EVM-version or set of EVM-flags. This way you could always depend on your contract working a specific way, but we could allow new contracts to have different behavior (e.g. the benefit of lower gas costs). The problem is that contract-to-contract calls would become difficult or impossible to analyze. It would also make it clear that contracts cannot depend on certain aspects of remote contracts, such as gas limits on unknown code.
Micah Zoltu
@MicahZoltu
@hayesgm I think, for the reason you mentioned at the end, that would not actually resolve this particular issue.
Nick Johnson
@Arachnid
@MicahZoltu I'm pretty sure the gas stipend was designed with this in mind. There's a reason it's greater than the cost of a log4 but less than the cost of an SSTORE.
Micah Zoltu
@MicahZoltu
@Arachnid I agree that .transfer and .send were designed with this in mind. I guess the question is whether Solidity behavior is part of the larger Ethereum "guarantee" or not?
Nick Johnson
@Arachnid
@MicahZoltu The gas stipend is built in to the EVM, it's not a Solidity feature.
Micah Zoltu
@MicahZoltu
Hmm, I thought Solidity compiled .transfer down to CALL ... 2300 ...?
Nick Johnson
@Arachnid
At this point I don't think we can, or should, remove the invariant. And even if we come up with another solution for the net gas metering change, I think we should consider adding the gas > 2300 restriction to clients anyway. Presently we have an invariant that's not explicitly enforced anywhere. We should add a guard that explicitly ensures the invariant is preserved.
@MicahZoltu No, a CALL with value > 0 and gas < 2300 will automatically provide 2300 gas instead.
Micah Zoltu
@MicahZoltu
Ah, I see...
Nick Johnson
@Arachnid
From the YP, appendix g:
Gcallstipend 2300 A stipend for the called contract subtracted from Gcallvalue for a non-zero value transfer
Ghost
@ghost~55c3ed250fc9f982beac84b3
Also, regarding the intent of EIP-1283 (which was previously EIP-1087), it was mainly to enable inter-frame communication within the same transaction. I wrote an alternative EIP, which has the same intent, but does not have the issue of EIP-1283 (1087): https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1153.md. Of course, I did not know about the the problem with EIP-1283/1087. What I am saying - if the demand for this change is really high, we can still do it, and even cheaper
Nick Johnson
@Arachnid
@Vendoreth_gitlab This is not the place to ask; please find a more appropriate channel.
Piper Merriam
@pipermerriam
@Vendoreth_gitlab this isn't the place to get individual support, try ethereum.stackexchange.com
Alex Beregszaszi
@axic
Also note there were some proposals to even increase the gas stipend. Here’s the EIP with reasoning: https://eips.ethereum.org/EIPS/eip-1285
Nick Johnson
@Arachnid
@jbaylina We absolutely should not encourage using selfdestruct to send; it's a nasty edge case, and allowing contracts to react to value transfers is a feature, not a bug.
Piper Merriam
@pipermerriam
Would this be considered a non-issue if the solidity docs were updated to 1) make it clear that these APIs don't protect against re-entrancy and 2) make it clear that re-entrency protection using GAS stipends isn't viable.
Micah Zoltu
@MicahZoltu
The real invariant people want is something that I don't think we can reasonably provide (reentrancy protection). The first-level proxy invariant people want is, "this call can't result in a storage update before it returns" (something I have always been against because it means contracts can't do interesting things when receiving ETH).
Nick Johnson
@Arachnid
@pipermerriam It's not just a Solidity issue, it's in the EVM. And I think it's far too late to change this invariant.
@MicahZoltu We could provide something like that by introducing a new call type, but that's a lot of extra complexity.
Micah Zoltu
@MicahZoltu
@Arachnid Yeah, I'm not a fan of it, but I think it is what people want (people often want things that are bad for them).
Nick Johnson
@Arachnid
@Vendoreth_gitlab Unless you need help updating an Ethereum client implementation you maintain to support Constantinople, this is not the appropriate place.
@MicahZoltu Right now what we need to do is preserve what people have.
Micah Zoltu
@MicahZoltu
While I am a fan of backward compatibility, I'm not a fan of getting locked in to decisions forever either beacuse people wrote code that makes assumptions it shouldn't have made. I can appreciate delaying a change like this for some amount of time to give people time to deal with it, but I'm not a fan of asserting that "we will always have this debt because one or more people may have made an inappropriate assumption while writing code". Knowing that the stipend value was set at the EVM layer may be enough to gain my support in delaying this EIP for a whole HF cycle, but I'm not convinced that we should permanently hack around it or indefinitely support the idea that < stipend means no storage changes.
Nick Johnson
@Arachnid
I mean, I'm not a fan of that either. But I don't think breaking existing code like this is an option we have. Part of the point of deploying on Ethereum is that your code will keep functioning the same way tomorrow as it does today.
It'd be particularly nasty to make non-backwards-compatible changes in an environment where there's no built in mechanism for upgrading code.
One of the big selling points of using Ethereum is that if I want, I can eliminate all trusted parties from my code: no owner, no trusted upgrade mechanism, nothing. We break that if we start introducing changes that retroactively make secure contracts insecure.
Micah Zoltu
@MicahZoltu
I have always suspected that Ethereum will eventually need to fall into that sort of mode (I call it Enterprise mode), where there are strong guarantees of no breaking changes. I guess I had hoped that we weren't there yet because I think Ethereum still has a lot of improvement necessary that won't be possible under that sort of constraint.
Perhaps the saving grace is Ethereum 2.0? We can run Ethereum 1.x in Enterprise mode indefinitely, yet gain benefits from lessons learned in Ethereum 2.0 where we can make all sorts of breaking changes.
Nick Johnson
@Arachnid
I think we've always been in "no breaking changes" mode, personally, ever since mainnet launch.
People use the network to do real things with real stakes.
And yes, 2.0 gives us lots of opportunity to make things better.
Brian Cloutier
@lithp
Is there anything stopping evm behavior from depending on when a contract was deployed? Contracts deployed before-Istanbul are always safe from this kind of attack, and contracts deployed after-Istanbul should know better than to rely on SSTORE having a high gas price, because it'll have a lower price. Contracts would inherit their era from the creating contract, so a before-Istanbul contract calling CREATE would create another before-Istanbul contract, but a transaction creating a brand new contract would result in something following the new rules.
Tomasz Kolinko
@kolinko
Brian, this wouldn't help in many cases
Nick Johnson
@Arachnid
@lithp There's no protocol field for when an account was created, no.
Brian Cloutier
@lithp
I bet there are reasons this wouldn't work but that doesn't sound like one of them, if you're hard-forking anyway you could add a field recording the era
Tomasz Kolinko
@kolinko
Because if you make an assumption in an earlier fork that a given function will only do such and such based on how much gas you give to it, this will obviously change when you are able to run a contract running on a new EVM
Evgeny
@eMarchenko
Maybe we can just increase cost for dirty SSTORE to about 2000 gas? that would prevent transfer-reentrancy, but is still quite an improvement and requires very little code changes and testing (hopefully)
Nick Johnson
@Arachnid
@lithp That's way harder than it sounds. Changing the consensus fields for accounts would require a stop-the-world upgrade to all existing ones.
@eMarchenko It's a solution, but it also makes net gas metering a lot less useful.
Brian Cloutier
@lithp
@kolinko Sure, I can see how it could get very confusing when you have contracts from different eras calling each other
Martin Holst Swende
@holiman
This is a good discussion, but could we please postpone the discussion a bit, and keep this room focused on the constantinople non-fork for the next couple of days?
Nick Johnson
@Arachnid
:+1:
Brian Cloutier
@lithp
:thumbsup:
Péter Szilágyi
@karalabe
Builds will be dripping in within the hour