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
James Hancock
@MadeofTin
The next period would be the end of january
Hudson Jameson
@Souptacular
My opinion: The community would be able to handle 25-30 second block times max. So if we can have a fork happen mid January that would be ideal :/
sassal
@sassal
i remember 30s block times... that was not pretty
+1 @Souptacular
James Hancock
@MadeofTin
I see two options. Fork fast and only change the number. Or, Fork a little slower and fix the ice-age mechansim so this doesn't happen again.
Mid january would fit either of those options imo
Hudson Jameson
@Souptacular

I have heard differing opinions as to:
a) Why the ice age was originally added to Ethereum.
b) What that means for the chain today.

So I hope we can quickly rehash those opinions as a community to see if we even want it anymore.

James Hancock
@MadeofTin
Yes
Hudson Jameson
@Souptacular
I don't know where I stand on the issue.
James Hancock
@MadeofTin
I believe in the intention, but not in the mechansim.
sassal
@sassal
given that eth2 is being deployed as a separate chain, i lean towards the ice age being unnecessary and something that could be removed without much consequence
but i dont know the current consensus around it in the community
James Hancock
@MadeofTin
The ice-age means that any contentious fork would need to be proactively made. And not retrofit onto any previous ethereum fork. It effectively bricks the legacy chain, and the only way to resurrect it is to make an update to client code.
Hudson Jameson
@Souptacular
@sassal @econoar can we include the explanation as to why we have the difficulty bomb and not just how it works in the EthHub article? I can then point people there when I ask them what their opinion is on it.
James Hancock
@MadeofTin
with the deploying of ETH2, i don't think we want old versions of Eth1 being shadow deployed. Better to leave all chains before us dead.
sassal
@sassal
@Souptacular can do
James Hancock
@MadeofTin
Shadow meaning, just grab an old version of Geth and start mining on it.
sassal
@sassal
@MadeofTin but can't someone just fork out the ice age if they want to deploy a shadow eth1?
James Hancock
@MadeofTin
Yes, but they have to actively do that. And then broadcast that they are doing it.
The forks aren't just laying around for anyone to pick up again
sassal
@sassal
this is true
James Hancock
@MadeofTin
The other historical reason was to give us a sense of urgency in deploying forks. Not necessary anymore. imo
Better to have a bricking mechanism that behaves predictably to fullfill the first case imo.
sassal
@sassal
yeah, i guess we just need to make sure to fix it so something like this doesn't happen again
James Hancock
@MadeofTin
A Fork should be an active choice a community makes. As you said "fork out the ice age" is something that a group can choose to do.
James Hancock
@MadeofTin
Around the same time last year I did some research on alternative difficulty adjustment algorithms. A bricking mechansim could easily be built in.
Micah Zoltu
@MicahZoltu
I'm a fan of removing the ice age entirely. SEPARATELY, I think the ice age should be deferred if it remains.
As a dapp developer and user, 30 second blocktimes are notably more impactful to users than 15s block times.
Not only because chain throughput is halved, but also just responsiveness.
James Hancock
@MadeofTin
The problem with the iceage is that it is really difficult to predict, not that it exists.
It involves simulating blocktime changes due to difficulty changes and relys on assumptions of changes of hashrate in the future.
James Hancock
@MadeofTin
You also have to simulate finding blocks which that is a Poisson_Point_Process https://en.wikipedia.org/wiki/Poisson_point_process
Micah Zoltu
@MicahZoltu
I have lobbied in the past that the ice age (if retained) should be a function of time, not a function of difficulty (or something along those lines, it has been a while).
Meaning, the chain targets a certain block production speed based on current absolute timestamp.
And then difficulty is used to adjust the system to target that block production rate.
James Hancock
@MadeofTin
Even a blockheight would be fine.
Micah Zoltu
@MicahZoltu
Would be better than current process yes. I generally am against using blockheight when you mean timestamp, and vice versa.
In this case, the intent is to target a timestamp, so we should use a timestamp.
James Hancock
@MadeofTin
Would be good to do some more research on if timestamp has unintended effects, but in general it would be better.
James Hancock
@MadeofTin
@hudson and everyone. Would it be worth holding a core dev call this friday to discuss? I hesitate to use an @ all but it may be a good idea to hold one. Otherwise we can address on next friday. Giving people more time to prepare and discuss proposals.
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<Hudson Jameson (souptacular)> Yeah let's give more time to discuss and have it as a main topic on the 29th meeting. We wouldn't be making any decision this Friday that would affect timing for a decision we would make the next week.
James Hancock
@MadeofTin
SeemsGood
Andrea Lanfranchi
@AndreaLanfranchi
A timestamp would imply some additional logic on syncing nodes (something like at time xx:xx:xx.yyyy but not before block zzzzzzz
AFAIK diff bomb was meant to force migration to ETH 2.x as it would brick legacy chain. Yet the need to defuse/postpone it at every upgrade seems (to me) its voiding the weapon from its main purpose.
My two cents.
Micah Zoltu
@MicahZoltu
Yes, switching to timestamps from current formula would require client dev work and a hard fork.
Ghost
@ghost~55c3ed250fc9f982beac84b3
@AndreaLanfranchi I agree with you regarding the bomb. The discussion above is a clear demonstration that having the bomb (with somewhat uncertain behaviour) that has to be rescheduled all the time, is a waste of people's cognitive resources. As I said before, if miners wanted to stay on the old chain, they could quite easily defuse the bomb on their branch of the fork. So it is not a very effective mechanism, but with a lot of faffing to keep it going
Peter (bitfly)
@peterbitfly
I suggest to replace the current block logic with a simple if blockNbr > BOMB_NUMBER then block.difficulty = uint64.maxvalue this way we keep to bomb alive but avoid the unpredictable block times
Andrea Lanfranchi
@AndreaLanfranchi

As I said before, if miners wanted to stay on the old chain,

IMHO it's not a problem of miners. No miner would stay on a chain where minted tokens have no value at all.
I think the real question is whether or not there's the need of a coercive tool to "force" the migration.

In my (very personal and unproven) opinion the "success" of ETH 2.x will be measured on behalf of "voluntary migration" rather than trying to force it.
@ppratscher ... that approach would tombstone the legacy chain in a matter of minutes.
Peter (bitfly)
@peterbitfly
yes which is not a bad thing imo