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
LinzhiCorp
@LinzhiCorp_twitter
we have pretty good collaboration tools, let's use them
Hudson Jameson
@Souptacular
@LinzhiCorp_twitter feel free to go ahead with the creation of your own
When I said I'd think about it, I don't expect myself or the cat herders to come up with a solution quickly :)
Michael - Blurpesec
@blurpesec
Plenty of other things to work on atm :-)
Hudson Jameson
@Souptacular
Yep!
LinzhiCorp
@LinzhiCorp_twitter
oh we shall take the lead respectfully. if a forum comes up here we'll move.
Kristy-Leigh Minehan
@OhGodAGirl
@AlexeyAkhunov You can have your opinions in flux, and that is fine. :)
Andrei Maiboroda
@gumb0
On preparing ConstantinopleHotfix fork: should we also create a temporary testnet to test the transition, like we did with Stureby testnet?
Main net never did two forks at once before, might be worth to see the exact same transition going well on the testnet first
Kristy-Leigh Minehan
@OhGodAGirl
@LinzhiCorp_twitter It may be disingenuous to have a hardware forum started that is run by a pro-or-anti-manufacturer. Hardware fights never end well, and end up turning into a political nightmare of censorship.
Pro-or-anti ASIC manufacturer.
Jaap Buurman
@Mushoz
Is there a backup plan to delay the ice age should the new fork be delayed for unforseen circumstances?
Péter Szilágyi
@karalabe
We're already in backup mode :D
Let's not design a backup backup just yet :D
Michael - Blurpesec
@blurpesec
Plan E?
Roy
@Shammah
How much time does the ice age give us in the worst case scenario? 9 months?
Merkle Tree
@merkle_tree_twitter
chain will become unusable for most in 3 months
Martin Holst Swende
@holiman
@Mushoz nope. Well, I guess fix it and :shipit:
Christoph Burgdorf
@cburgdorf
Here's a stub implementation for the new fork in Py-EVM with codename "Petersburg" ethereum/py-evm#1719
(I guess the name is still up for discussion ;))
Ghost
@ghost~55c3ed250fc9f982beac84b3
@cburgdorf I like the name
Christoph Burgdorf
@cburgdorf
@AlexeyAkhunov let's see how long it takes for the press to come up with weird Vitalik <-> Putin connections again ;)
Ghost
@ghost~55c3ed250fc9f982beac84b3
It gets us to around 1920 on the timeline :)
St. Petersburg was renamed to Petrograd in 1914. Then, 10 years later, to Leningrad. Then, in 1991 - back to St. Petersburg
Christoph Burgdorf
@cburgdorf
That kinda fits the naming trouble we face with that fork really well haha.
Ghost
@ghost~55c3ed250fc9f982beac84b3
Regarding the upgrade switch that @karalabe brought up: I wanted to comment, but did not want to take more time on the call. I think it can be designed in a way that it does not present centralisation vector. I see it as a voting multisig with a very limited power - to skip a network upgrade. Any abuse of this power would be accountable, because we will see who pulled the trigger. Normally, the discussion and emergency call would still happen, and only after that, the key holders will "do their duty". If someone does it before the agreement call, it is clearly seen. And, of course, the membership of the multisig is regularly reviewed, and inactive participant removed. Also, if the multisig becomes completely compromised, removal of its powers can still be done via hard-fork coordinated in the "usual" way
And, of course, it should be opt-in from the clients
I think we should not shy away from such mechanism. Informal structures that make these kind of decisions already exist, and we know that. Making them formal actually make the process MORE transparent, not less
Ghost
@ghost~55c3ed250fc9f982beac84b3
It is related to my statement on today's call - even though EF and other funding entities want to stay away from certain HF decisions, in the end of the day, their policy on funding/non-funding of development of given forks matters quite a lot. It is informal, but it does not make it less true. Pretty much no alternative forks can survive unless there is a funding entity backing it (see BCH fork and Bitcoin.com, and Ethereum Classic as an example).
Ikmyeong Na
@naikmyeong_twitter
@lrettig 7.29m will be better since it is the first day of March and the exact switch block of 243th epoch
Jochem Brouwer
@jochem-brouwer

network upgrade?

It's nice to see that Etherscan actually calls it a Network Upgrade. Didn't notice that until now

Danno Ferrin
@shemnon
@AlexeyAkhunov Yes, the key centralized question is who gets keys? How many? What triggers a HF cancellation? Like 3/5 and keys to client devs, companies, miners and exchanges? Picking keysize and keyholders is the actual hard part of that model.
Ghost
@ghost~55c3ed250fc9f982beac84b3
@shemnon Don't think it is that hard actually. I would say, choose 5-out-of-10 multisig with some people who would be involved in such decision anyway
I know it is like a holy cow for many people, but if you think logically, it does not need to be
it is very easy to resist such power for node operators, if they want to
Danno Ferrin
@shemnon
The argument quickly devolves to who would/should be involved in such a decision, and who is a stakeholder.
I like the idea I just am concerned about implementation.
Ghost
@ghost~55c3ed250fc9f982beac84b3
I repeat - it is not for stakeholders - it is just formalising who makes the decision anyway. Look at who did it this time, give those people keys, then add some more
Jamie Pitts
@jpitts
As this switch idea probably requires in-depth discussion, I created a topic for it: https://ethereum-magicians.org/t/abort-switch-to-withdraw-a-planned-upgrade-to-mainnet/2480
Ghost
@ghost~55c3ed250fc9f982beac84b3
Thank you, @jpitts. It is a recurring theme, I think, the denial of informal structures and their power, while these structures are almost in the plain sight
Jochem Brouwer
@jochem-brouwer
@AlexeyAkhunov I like the idea of multisig. How do you see that this power is distributed? I am assuming locking up Ether to gain a proportional amount of votes for the locked up Ether?
Danno Ferrin
@shemnon
I think we should limit the kill switch discussion to the eth magicians forum @jpitts opened. I expect it to be very long.
atlanticcrypto
@atlanticcrypto
I think there is a key point not talked about here - the existence of the difficulty bomb really limits the ability for any group to continue operating on the previous chain - the difficulty bomb has become a coercive tool that forces acceptance on the miner side of what's coming in a fork no matter what - and unless a contingent of miners have a developer group who can sustain and grow the pre-fork chain development, they are basically forced to accept what the developers want. This idea of "well you can just choose to not do it" is kind of BS. The only option any Ethereum miner has when a fork happens is to leave the network entirely and do something else.
Jochem Brouwer
@jochem-brouwer
Ether makes no sense if I think about it. It should indeed be people who can reasonably call this off
atlanticcrypto
@atlanticcrypto
And I am not throwing stones here - the developers in this group have been extremely accepting of my comments and suggestions over the past 12 months - and I have appreciated it very much. However, the difficulty bomb is a coercive tool. In Bitcoin miners are deemed to be the be-all end-all decision makers, in Ethereum miners only have an anecdotal seat at the table, because at the end of the day, we will do whatever you push through in a fork, or we'll leave. And that might be okay - and I know Michah is 100% transparent that he gives zero fks - but the miners are a huge part of the ecosystem and userbase.
Jamie Pitts
@jpitts

Regarding @lrettig's earlier statement regarding non-technical aspects of ProgPoW, and even this difficulty bomb discussion:

This (plus Eth Magicians) is the right forum for discussing the technical aspects of ProgPoW but probably not the non-technical aspects (e.g., “favoring” one class of miners over another). We don’t have an established forum for the latter, but we could set up an EIP0 forum.

I agree with this strongly, and interpret it as: core devs and the various Rings should primarily focus on technical considerations. Legal / philosophical /ethical / political considerations are for a different forum. One needs to be created where it can productively be worked out. The EIP0 group was a good start, particularly w/ subjects around "meta EIPs".

Peter (bitfly)
@peterbitfly
If I understood correctly during today's core dev call a PoW change will not be decided by the devs. Thus I would like to propose to let miners decide on it by the means of a hashrate based voting (e.g. via flags in the extradata field). Miners are the main stakeholders in this decision and should have a say on this. On top of that this will also allow us to identify the real proportion of ASICs on the network as they will likely vote against any PoW change.
Nick Johnson
@Arachnid
@ppratscher Doing that would guarantee voting against ProgPoW if the network is already captured by the devices ProgPoW seeks to prevent.
That seems like a poor failure case t o me.
Peter (bitfly)
@peterbitfly
For example start with a binary vote if the PoW should be changed. If more than 75% (number to be defined) of the network hashrate is in favor then move further to discuss which algorithm to choose from (ProgPoW or something else)
Yes, then we at least know the real proportion of ethash Asics
Right now we can only guess