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
S. Matthew English
@s-matthew-english
just to share it around with other PegaSysers and make sure we have all the relevant information for the call
ah
it's this I guess...
Paweł Bylica
@chfast
If someone whats to review some "crypto" code I sending changes related to ProgPOW here: https://github.com/chfast/ethash/pulls
Danny Ryan
@djrtwo
eth2.0 implementer call in a little more than one hour. agenda here ethresearch/eth2.0-pm#8
zoom link to follow
Danny Ryan
@djrtwo
Hudson Jameson
@Souptacular

@/all Core devs meeting in a little less than 12 hours

Agenda for meeting: ethereum/pm#58

Videoconference Link: https://zoom.us/j/717504189

We will be having someone who has ran new benchmarks for EIP 1108: Reduce alt_bn128 precompile gas costs.

We will also be having the team behind ProgPoW on the call so we can all sync up with what various people have been doing to test, benchmark, and otherwise explore it.

Please look over EIP 1108 and think of any questions you have for the ProgPoW team.

Hudson Jameson
@Souptacular
@/all 15 minutes until the call
Martin Holst Swende
@holiman
Trying to get this merged: ethereum/EIPs#1375 . Clarifications regarding Skinny Create2 cc @vbuterin
vbuterin
@vbuterin
not sure I understand the question
0xff is a single byte, why would it have endianness?
Lane Rettig
@lrettig
Preliminary call notes are up, please PR additions and corrections, thanks! https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2047.md
ledgerwatch
@AlexeyAkhunov
@lrettig Awesome as always!
Noel Maersk
@veox
I'm just listening to the recording... How about block 4242424 for Ropsten fork?
I use https://ropsten-stats.parity.io/ for basic stats on Ropsten.
OK, you've settled on 4200000.
Lane Rettig
@lrettig
https://ropsten-stats.parity.io/ is helpful, it says the average block time is 12.89 sec. I used 14 sec in my math. If it is indeed 12.89 sec (not sure over what time horizon this is calculated), then it will be closer to ten days from now, not 11.
Noel Maersk
@veox
In principle, having deterministic "init code" in CREATE2 doesn't guarantee anything to the counterparty. For example, the "init code" can reference an outside contract X that's itself a dispatcher. So, although the "init code" itself doesn't change, the behaviour might.
Lane Rettig
@lrettig
I said 14 sec based on https://ropsten.etherscan.io/chart/blocktime but there’s been a lot of variance lately
image.png
oh geez - that data is from 2017!
Noel Maersk
@veox
Yeah, was about to say...
Lane Rettig
@lrettig
I just noticed haha
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.