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
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
it is predicatable in the way that we know we need to hard fork till block X or the chain will get stuck
Bob Summerwill
@bobsummerwill
I honestly do not understand what purpose the difficulty bomb serves anymore.
It is a delight on ETC not to have to worry about it.
Adding some bricking mechanism at a fixed block would be much simpler.
(though some group will obviously keep ETH1 going away - forking and removing that mechanism)
It reminds me of the US debt ceiling:
https://en.wikipedia.org/wiki/United_States_debt_ceiling
How many times has the bomb been delayed now?
How many more times might that have to happen?
Is all of the "faff" really helping ETH in any way?
Bob Summerwill
@bobsummerwill

@ppratscher "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"

That is an eminently sensible suggestion, IMHO, but maybe with the block number a LONG WAY AWAY, like 2 years.
And then reduce the block number at the time of the last HF prior to transition.

Andrea Lanfranchi
@AndreaLanfranchi

@ppratscher

yes which is not a bad thing imo

This is a huge change in vision. There is no "official" plan to suddenly brick legacy chain. It could even become one of the shards. The purpose, to my understanding, is to make PoW progressively less and less valuable for miners and encourage stakers.
Transition won't be a night-time switch : it could be only if phase 2 will transfer state from ETH 1.x to ETH 2.x and burn all assets on ETH 1.x

Martin Holst Swende
@holiman
ISTR someone volunteered to write an eip for postponing the bomb, at last ACD call. Any progress on that? I'm fine with other options, but bumping it a year or so sounds like the easy path. Then we could probably ship it a week or two after Istanbul, imo
Wei Tang
@sorpaas
Hmm, just want to make sure I'm understanding this correctly -- we're talking about doing another hard fork just one month after the Istanbul hard fork?
Martin Holst Swende
@holiman
Yes, but probably only a bomb delay
James Hancock
@MadeofTin
@holiman that was me.
Tim Beiko
@timbeiko
One thing that was mentioned to me after my last ACD tweetstorm is that past Ice Age delays included an issuance reduction on a per-block basis to offset the additional issuance on Eth1. I’m not sure how big/little of a concern that is and how much of an impact on total supply pushing back the Ice Age 12/18/24/36 months has, but it may be worth considering.
Also, could we devise a rule along the lines of “If we think the Ice Age hits in <1M blocks when a fork is scheduled to happen, we automaatically push it back by _N_ M blocks”? I think there is value in keeping it, at least until we have the Finality Gadget or some other Eth1 -> Eth2 link, because it forces minority forks to do more than “not upgrade”.
James Hancock
@MadeofTin
This is the EIP that did both the reduction and the delay. https://eips.ethereum.org/EIPS/eip-649
Tim Beiko
@timbeiko
Lastly, I wish we had not sent out a blog post ~hours before finding this out :sweat_smile: ! I agree with Wei’s concern that forking in January, only weeks after Istanbul (and holidays for a large part of the world) is not ideal.