Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Feb 28 19:45
    @Arachnid banned @merkle_tree_twitter
  • Feb 17 00:56
    @jpitts banned @Aquentson_twitter
  • Apr 09 2018 04:14
    @holiman banned @JennyJennywren_twitter
  • Oct 21 2017 19:12
    @Arachnid banned @Musk11
5chdn
@5chdn
since it's only a test network it's probably fine
Lane Rettig
@lrettig
@AlexeyAkhunov yes, we estimated the block time at 14 sec I think, and last I checked it was 12.9
So we were off by about a day
Martin Holst Swende
@holiman
I'm inclined to let it be. @AlexeyAkhunov wants to postpone. @5chdn thinks 'probably fine'. Any other opinions?
By 'let it be' I mean don't postpone
Mikhail Kalinin
@mkalinin
I am currently working on gas calculation update for CREATE2. it should be ready by tomorrow. But it turns that we won't be ready to publish a release before Ropsten fork block happens, so, it'll be available only in a Snapshot version. But it doesn't look like a big problem and we're ok on keeping 4_200_000 for Ropsten
Elichai Turkel
@elichai
In the ABI, if a contract returns a uint. will the evm output it in decimal or in hex? (for e.g. the input to the evm is hex starting with 4b hash of function)
Piper Merriam
@pipermerriam
@elichai this isn't the place for that kind of support, you should ask on https://ethereum.stackexchange.com/
Paweł Bylica
@chfast
Aleth will be fine. But I don't mind postponing
ledgerwatch
@AlexeyAkhunov
@holiman I don't necessarily want to postpone. I think this is a more prudent from the "process" point of view. If there are tests you can run on the clients before going into the testnet, you should run them first. If not, and you won't, then of course it does not matter
so I will reformulate the question to the client devs: will postponing the Ropsten fork allow you to run more code reviews/checks/tests on the code? If the answer is yes for at least geth or parity, I would recommend postponing. If no, then postponing does not help
Wei Tang
@sorpaas
The only issue we have right now for parity-ethereum is ethereum/tests. All CREATE2 test fails after cost per byte changes.
Martin Holst Swende
@holiman
@AlexeyAkhunov I see it a bit differently. We're understaffed on testing, and a good way to get more test coverage is to put it on a mainnet where everyone can help test it. It wouldn't have to be ropsten, it could have been a new testnet, but I think forcing clients to make real releases with Constantinople as soon as possible is better for everyone. I don't want to bork Ropsten intentionally, but if it uncovers a consensus error then that's a very good thing.
Martin Holst Swende
@holiman
Replace 'on a mainnet' with 'on a network'
Jason Carver
@carver
We know some clients will stay on the non-Constantinople Ropsten fork, like parity stable. Tests aren't complete, so it's reasonable to expect consensus errors too. We might say it's acceptable to break a test network, but plenty of devs think of it as a place to test their contracts rather than for core to test consensus. All of that implies delaying.
On the other hand, I see two key rationales for not delaying: 1) we can use Ropsten to help identify consensus issues quickly and 2) we train developers to deal with chain splits and long reorgs. Those are both very valuable. IMO, they are valuable enough to aggressively launch on Ropsten, with a caveat: we need a loud communications broadcast.
All teams involved should be posting to twitter, blogs, etc saying "we are intentionally testing a contentious fork to Constantinople on Ropsten at 4.2M, we expect clients to split the chain during testing". If parity, EF, etc aren't comfortable broadcasting that message in the next ~24 hours, then I think we should delay the Ropsten fork, and launch a brand new testnet instead, to start consensus tests.
Martin Holst Swende
@holiman
I wouldn't use the word 'contentious fork' though
Jason Carver
@carver
Heh, sure, this is why I'm not in charge of marketing
Greg Colvin
@gcolvin
Paul D.
@poemm
@gcolvin I have proposed something similar for ewasm. I want to build tools for this in PyWebAssembly, and present advantages/disadvantages of various metering methods to everyone. But too busy lately getting ewasm WebAssembly engines ready before devcon.
Greg Colvin
@gcolvin
@poemm I look forward to post-devcon discussions
Paul D.
@poemm
@gcolvin Likewise.
Lefteris Karapetsas
@LefterisJP
We at raiden network test our contracts at Ropsten since it's the only PoW network usable by both clients.
Tim Siwula
@fluffypomeranian
How many reads/second can a client support?
Lefteris Karapetsas
@LefterisJP
@holiman by quickly scanning the channel can't see when is the proposed Ropsten breaking happening?
Martin Holst Swende
@holiman
@LefterisJP at block 4.2M, roughly around 12th pf October, afaik
Lefteris Karapetsas
@LefterisJP
I see. Is it a done deal? Or will it be postponed after all?
Martin Holst Swende
@holiman
It's not a done deal, but it needs quick decision
Hence the tweet
Lefteris Karapetsas
@LefterisJP
:+1:
Martin Holst Swende
@holiman
How bad would it be for you if there was a chain split?
How long would you manage without a non-broken ropsten?
Lefteris Karapetsas
@LefterisJP

Tweet served its purpose :) . I am here saying we heavily use ropsten for testing our contracts atm. We are rather close to mainnet release and really don't want to add the task of finding another testnet on top of my team right now.

How bad would it be for you if there was a chain split?

Would effectively make testing almost impossible. Say a chainsplit between parity/geth. Half of us use parity, other half geth to test both clients.

How long would you manage without a non-broken ropsten?

I don't understand the question. You mean for how much longer do we need a testnet?

Martin Holst Swende
@holiman
I mean if we had a split for four days, how bad would that be?
Péter Szilágyi
@karalabe
So, we're wrapping up our release and wondering what the final course of action should be?
I think we definitely need to do the SHA3 gas cost addition, otherwise it's just asking for a DOS
So, do we fork at the appointed block, or do we delay? Imho since Parity released a stable version with the block set in stone, Ropsten is forking into two at that point. One old, the other invalid.
As such, I don't think it makes sense to postpone to a different block, since you either remain on old Ropsten and don't update, or you need to update to a fresh release.
It will be a mess, yes. Personally I don't mind that much because imho Ropsten is reaching it's end of life anyway. A testnet is supposed to be light and easy to use, but Ropsten became way too heavy already. I don't mind if it breaks up and joins Morden in history.
Martin Holst Swende
@holiman
Did Parity? I understood otherwise? @5chdn ?
And yes, SHA3 gascost is in, afai have been able to assess consensus
André Silva
@andresilva
afaik we still haven't released any version that sets the HF block on ropsten. and we have a pending PR with CREATE2 gas cost changes
Lefteris Karapetsas
@LefterisJP

I mean if we had a split for four days, how bad would that be?

Pretty bad. At such point I would prefer a new PoW testnet.

A testnet is supposed to be light and easy to use, but Ropsten became way too heavy already. I don't mind if it breaks up and joins Morden in history.

For us and our testing consistency with older data is not required. We can easily afford to re-deploy to a new PoW testnet (that's lighter than Ropsten) that can be used by both clients. As long as such a testnet exists and we don't have to do that often.

Péter Szilágyi
@karalabe

Pretty bad. At such point I would prefer a new PoW testnet.

Well, you could gasp wait 4 days with resuming testing on the public testnet ;P

or perhaps run your own private testnet for heavy testing?
Noel Maersk
@veox
Continuing to run the pre-fork Ropsten is also an option.
AFAIK, Raiden is in public testing. As in, the general public has been invited to use this version, prior to the main-net release.
Lefteris Karapetsas
@LefterisJP

Continuing to run the pre-fork Ropsten is also an option.

That is an option.

or perhaps run your own private testnet for heavy testing?

What @veox said. It's not just us testing.

Well, you could gasp wait 4 days with resuming testing on the public testnet ;P

We are on a feature freeze so testing is our main focus right now. 4 days of development is a lot