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
Lane Rettig
@lrettig
So yea if the block time is indeed ~12.9 secs, my math shows block 4.2M happening in 10.16 days
Noel Maersk
@veox
It's regularly fluctuating on Ropsten. Hashpower comes and goes.
4242424 would actually come 6 to 7.5 days later than 4200000, so maybe 4200000 is better.
Martin Holst Swende
@holiman
@vbuterin your approval is required to merge the pr to the eip
So I didn't mean to ask about endianness, but the PR in general, since you're the author of the eip
ledgerwatch
@AlexeyAkhunov
@veox By "deterministic init code" I mean the init code that is, for example, always returns the same string regardless of what is on other contracts. What is deemed "deterministic" shall be agreed between the participants in a state channel
Noel Maersk
@veox
@AlexeyAkhunov Yes, I understand. What I meant is that deterministic behaviour can't be guaranteed by this destroy/re-create scheme. Just a thing to keep in mind.
ledgerwatch
@AlexeyAkhunov
@veox no, the destroy/re-create allows great flexibility that I wanted to bring to everyone attention. And this flexibility might have lots of uses outside of state channels. But for state channels, I suspect they will use very strict subset of init codes
Noel Maersk
@veox
Say, contract X references external contract E for some behaviour. contract E relies on a storage value in X being set. Destroying and re-creating X will see code for both X and E remain the same, but the behaviour of E will change, and so by extension will that of X's.
So, verifying that X behaves the same before destruction and after re-creation requires verifying the same condition for every external contract that X might reference. (This is essentially the same problem as when verifying behaviour of any non-"pure" code.)
(FTR, I'm not trying to contradict that this flexibility is useful. It does seem so, and indeed especially in state channels.)
Noel Maersk
@veox
@AlexeyAkhunov ^^^
Martin Holst Swende
@holiman
Yes, so don't allow external calls in initcode if you want determinism. It's pretty simple to prove determinism, if that's an intended goal.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[W Dimitry] What you mean by determinism here? Like on a given state the result is always determend
ledgerwatch
@AlexeyAkhunov
by determinism here we mean that if you see the init code you can determine what the deployed contract code is going to be (that was my meaning anyway)
non-determinism is when by looking at init code you cannot determine what the deployed contract code is going to be
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[W Dimitry] Well from bytecode prespective you could pre execute transaction and get the code.
ledgerwatch
@AlexeyAkhunov
that might not be enough. Init code can contain external call to other contracts and pull the deployed code from there
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
[W Dimitry] I mean the state change you will always see
[W Dimitry] Making it hard to read is an issue
Lane Rettig
@lrettig
Right or it can depend on context like block number, difficulty, gas limit etc
Martin Holst Swende
@holiman
If someone wants a piece of initcode to be deterministic, he/she can easily make it so. If they don't, it will be tricky to verify that it indeed is
ledgerwatch
@AlexeyAkhunov
@holiman Yes, that was exactly what I meant, thank you!
Noel Maersk
@veox
@jimpo Would say so.
Just did.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Hudson Jameson (souptacular)> Testing bridge
Danny Ryan
@djrtwo
Looks like it works from gitter
Martin Holst Swende
@holiman

Regarding some discussions that has been happening on EIp-1014, Skinny Create2.

I have now performed some benchmarks, and can confirm that the combination of uncapped size of initcode + lack of cost-per-byte is problematic in CREATE2, and can lead to DoS attacks if not fixed. Therefore, I propose that we accept the change to EIp 1014 which uses the folowing phrasing:

Additionally, an extra GSHA3WORD * ceil(len(init_code) / 32) gas is charged.

Furthermore the problem is also present today, with CREATE, but that is due to internal implementation details in most (all?) clients. Short story: it can be fixed without changing CREATE. Client implementors can PM me for details and testcases. I have already spoken to Parity members about this.

An alternative change could be to introduce a cap on initcode size. That would also 'fix' the problem in a less 'correct' manner. cc @/all

Paweł Bylica
@chfast
The gas is charged up front from the caller?
Martin Holst Swende
@holiman
I guess so, yes? It needs to be charged before the address is calculated
Paweł Bylica
@chfast
I think the same. It should be part of the CREATE2 cost.
Martin Holst Swende
@holiman
I consider this 'approved' by @vbuterin (eip author), aleth and geth. Any objections from Parity or Trinity (@pipermerriam) or other client implementors to adding this immediately? Also, we need to determine if we should postpone the Ropsten fork with this change.
Mikhail Kalinin
@mkalinin
@holiman no objections from EthereumJ
Holger Drewes
@holgerd77
I am also seeing the Ropsten fork date as extremly tight, considering that EIP-1014 for CREATE2 is not finalized and tests for EXTCODEHASH ethereum/tests#484, SSTORE ethereum/tests#511 and difficulty bomb delay are not yet production-ready.
One thing is that breaking Ropsten testnet might not be the "end of the world" (Piper), but I think on this path we'll break it for-sure (at least very likely).
Fredrik Harrysson
@folsen
@holiman I talked this over with Tomasz internally as well, so I think whatever he says is good.
ledgerwatch
@AlexeyAkhunov
In my opinion, it is good to delay Ropsten due to this addition to the EIP-1014. If Ropsten is mostly probably to be broken, it is risk without reward.
Martin Holst Swende
@holiman
I'm of two minds. It's a trivial change, and we haven't released the ropsten release yet, so it would be simple to include it within a few days. More testnet time is better...
ledgerwatch
@AlexeyAkhunov
If it is trivial, then I would suggest trying to get it implemented. If it works, then keep Ropsten fork on track. If it does not, delay it :)
Martin Holst Swende
@holiman
Oh I made the PR earlier today
But tests won't be regenerated in time :/
Piper Merriam
@pipermerriam
@holiman no need to hold things up for trinity, we're still not quite performant enough to be a viable client.
Adrian Sutton
@ajsutton
For the record, Pantheon’s CREATE2 implementation follows the new gas calculation and other changes from ethereum/go-ethereum#17812. It will be tight given the prep we need to do for initial open sourcing, but I’m hopeful that we’ll have full Constantinople support before it actually kicks in on Ropsten. The biggest concern is that the ethereum reference tests appear to be in a fairly unhappy state at the moment so testing compatibility is challenging.
And that was the wrong link… too many tabs open and all looking like github pull requests….
Martin Holst Swende
@holiman
We've started an initiative to improve on the situation with tests. See this gist for more details: https://gist.github.com/holiman/fdec3547f2b104803abbd2c6e751a8e7 . There is a new hire who will (among other things) work on this
Holger Drewes
@holgerd77

@holiman :thumbsup: :thumbsup: :thumbsup: That's great! @winsvega is doing a great job on the execution side, to complete the picture it would be great if you could also extend on communication with the new hire, atm it is hard to get e.g. the latest state of the Constantinople implementation or generally a picture what is happening related to tests.

Stuff I would value a lot here:

  • More structured issues or alternatively projects to sum up work e.g. for Constantinople, test reorg,...
  • More work on the documentation at https://ethereum-tests.readthedocs.io/en/latest/ (still have admin access there and can pass on access if desired)
  • Regular updates (biweekly or so) what is going on (Reddit, medium, somewhere, can also be minimalistic for not adding too much additional workload)

Just some wishlist. :smile:

Martin Holst Swende
@holiman
@5chdn are parity onboard with cost-per-byte for CREATE2 ? And if so, will it make it in before the ropsten HF release version? Otherwise, we definitely need to postpone
5chdn
@5chdn
tbh the ropsten hardfork date is very unfortunate because we won't be able to backport all constantinople changes to stable in time, but I wont complain because we missed the last dev call