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
Micah Zoltu
@MicahZoltu
@localethereum_twitter No ETA yet, current focus is on not-forking in ~30 hours. After that is done core devs will evaluate how to proceed with Constantinople and when. Just removing that EIP may be the ultimate solution, but on a short timeframe it was deemed prudent to take the simplest path, which is to not fork at all.
localethereum.com
@localethereum_twitter
IMO it would be helpful to know who made the decision (e.g. who voted for it & who was included in the vote)
Micah Zoltu
@MicahZoltu
I suspect we'll see more details and a retrospective in the days to come. The short answer is that the issue was brought up by ChainSecurity, the available core devs discussed it here and in a call and made the decision to advocate for a cancellation of the hard fork.
Unfortunately, due to the time constraints, there wasn't a lot of opportunity to reach out to a wide audience and have an extended debate about the merits of the various options.
In this case, a decision was made to err on the side of caution in light of the new information provided by Chain Security.
Piper Merriam
@pipermerriam
Someone could take the chat history from this channel for the day and distil that information out of it if they wanted to
Steven Schroeder
@schroedingerscode
@pipermerriam Yup. There are circumstances when decisions have to be made quickly to lessen felt impact and this was one of them. The easiest, least risky change was changing the block number and available devs agreed.
Aron
@cobordism

It should also be noted that even though there were risks in going ahead with the fork and risks in delaying the fork, there was an asymmetry in timing. The closer we get to the time of the planned fork, the harder and riskier it is to call for a postponement.
As such the decision to delay the fork had to be made really quickly. This undoubtedly played into the decision tonight.

It was simply not feasible to spend 12 hours investigating / discussing because by that time (less than 24 before the fork) a delay may no longer have been possible.

localethereum.com
@localethereum_twitter
Fair, thanks. Looking forward to the retrospective. Maybe we'll see a new & improved plan for the next urgent fork/non-fork (which hopefully never happens)
I'll contact whoever I know & get those nodes upgraded 👍
Micah Zoltu
@MicahZoltu
Thanks @localethereum_twitter!
Chris Hobcroft
@chrishobcroft

I've created a github issue, designed to capture questions and comments which cannot be addressed right now, but which would be valuable to discuss during a post-mortem.

ethereum-cat-herders/hard-fork-checklist#1

Thank you for your contributions and patience.

Hex Capital
@Hex-Capital
Thanks @5chdn and the Parity team for quick turnaround!
Phil
@phillux
also 2.3.0-beta here (release notes coming soon): https://github.com/paritytech/parity-ethereum/releases/tag/v2.3.0
Phil
@phillux

@Souptacular since all the updated versions are released, we should update the blog post to reflect that. I recommend changing:

"Miners, Exchanges, Node Operators:

  • Update your Geth and/or Parity instances when they are released.
  • These releases are not released yet. We will update this post when they are available.
  • Links and version numbers and instructions will be provided here when they are available.
  • We expect to have updated releases in 3-4 hours from the time this blog is published."

to
"Miners, Exchanges, Node Operators:

  • Update your Geth and/or Parity instances to the updated versions using the links below"
Noel Maersk
@veox

@5chdn - from "1 TB yet" node:

Constantinople will activate on Sunday 8933219337287-04-06 21:19:17 UTC.

Do you have a stand-alone estimator, perhaps? Or a node you won't be upgrading? (The archive node's page is inaccessible, BTW.)

Please keep it low-priority, though. ^_^

Hudson Jameson
@Souptacular
@phillux good idea. I can do it later. I'm about to start playing with my tabletop RPG group.
I'm a superhero named The Beacon.
Nick Johnson
@Arachnid
I hope your superpower is that once you've observed something, it can't be changed by time travellers.
Danny Ryan
@djrtwo
:joy:
Hudson Jameson
@Souptacular
No it's actually that I can somewhat manipulate WiFi and Bluetooth signals.
But weakly.
Danny Ryan
@djrtwo
keep practicing
Hudson Jameson
@Souptacular
So it's a shitty superpower.
Lane Rettig
@lrettig
Actually I think that sounds like a cool superpower
Nick Johnson
@Arachnid
That's okay, this evening I'm playing a druid who's literally a walking medicine cabinet, so...
Lane Rettig
@lrettig
Can we have an all core devs RPG session once Constantinople is over and done with? @Souptacular can DM
Nick Johnson
@Arachnid
:+1:
5chdn
@5chdn
@veox not understanding the question
Noel Maersk
@veox
@5chdn It still "would be nice" to have an estimate of when block #7080000 will be. Not just roughly (from memory, or guess).
May I also remind all that Ropsten, Rinkeby, Kovan, Goerli, Gangnam, and (pretty soon) Ikmyeong Na's ProgPoW fork are open for demonstration of the "fresh" vulnerability, without much cost (time) of experiment set-up.
Michael Zhou
@Dominator008
What's the fate of EIP-1283?
Will it be included?
Noel Maersk
@veox
Some projects are offloading data storage to testnets. Others are doing pegs. The possibility of disruption to feed back into ETH main-net is not zero.
@Dominator008 To be discussed on (regular) Friday meeting.
Michael Zhou
@Dominator008
Ok thanks
Tomasz Kolinko
@kolinko

Ok, so we found a contract in the wild that can be exploited. An old unused one, but shows the pattern in the wild. 0x693399AAe96A88B966B05394774cFb7b880355B4 - reentrancy between agreeToTrade and offerTrade to trigger balance underflow.

More details on EthSecurity telegram group, since here it's offtopic if I understand correctly (or I can copy the details here as well, @holiman )

Noel Maersk
@veox
I'd say it's reasonably on-topic... But that's IMO. Perhaps a link?..
Benjamin Burns
@benjamincburns

@MicahZoltu I think one part of the story might be the not-so-long-yet availability of Constantinople dev tools. We released the EthereumJS Constantinople VM 22 Nov 2018, it took Truffle some time to integrate and the first Constantinople-ready Ganache version came out just 6 days ago. Since ChainSecure uses this first beta to test the vulnerability my assumption is that these releases might have triggered experimentation, will investigate this further.

One outcome of this might be to take dev tool readyness stronger into account when planning a hardfork date, and make release of the 2-3 most used tools (and not just the VM as some base layer) a precondition for some date settlement.

I share the concern (I'm a member of the Truffle team and oversee the development of ganache-core and ganache-cli).

Who should I be coordinating with to make sure we're supporting things appropriately here?

also if there's a formal (or informal) retrospective on this, I'd be happy to participate
Noel Maersk
@veox
@kolinko Did you detect it by scanning or manual review?.. If the latter, and the scanners don't detect it when they finish their runs, it's a rather strong signal that the scanners' capabilities are insufficient.
Tomasz Kolinko
@kolinko
scanning + manual review
and here's the description of the example contract exploit
Nick Johnson
@Arachnid
Oh god, we have a telegram group too?
Tomasz Kolinko
@kolinko

Quoting Hubert from ChainSecurity who double-checked my findings:

Here is how it works for contract 0x693399AAe96A88B966B05394774cFb7b880355B4. This is a contract that can be used to exchange ether and tokens. The attacker acts as follows within one transaction:

We assume that the balance of the attacker is one token.

  1. The attacker first calls offerTrade(1,1) from the attacker's smart contract deployed at attackerAddress => Exchanging one wei for one token
  2. The attacker calls agreeToTrade(attackerAddress) with 1 wei as value. This will perform some checks and then execute _from.send(), which activates the attacker contract.
  3. The attacker contract calls offerTrade(0,2) which know only costs 1513 gas and sets the tokensOfferedOf[attackerAddress] = 2.
  4. agreeToTrade() continues and balanceOf[_from] -= tokensOfferedOf[_from]; underflows. The attacker now has a quasi infinite balance and can transfer all these tokens.

The problem is this sequence.
if (balanceOf[_from]<tokensOfferedOf[_from]) throw;
if (!_from.send((msg.value*(100-ethTaxRate))/100)) throw;
balanceOf[_from] -= tokensOfferedOf[_from];

It is expected to be executed atomically, but this is not true due to the reentrancy.

@Arachnid telegram group is EthSecurity - mostly about security talk, this channel is for core development as far as I understand
(if anyone is interested more about this contract, pm me for the invite to telegram, to keep this group on topic)
Nick Johnson
@Arachnid
@kolinko I'm not griping about the existence of another channel, I'm griping about the use of yet another protocol. :)