by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jun 20 2019 16:01
    gitcoinbot commented #110
  • Jun 20 2019 15:13
    gitcoinbot commented #110
  • Jun 20 2019 15:13
    gitcoinbot commented #110
  • Jun 19 2019 14:58
    mkeen commented #110
  • Jun 19 2019 12:34
    hrishikeshio commented #110
  • Jun 19 2019 01:47
    mkeen commented #110
  • Jun 10 2019 09:19
    kuhnchris commented #110
  • Jun 10 2019 01:12
    mkeen commented #110
  • Mar 28 2019 02:21
    ChihChengLiang closed #176
  • Mar 28 2019 02:21
    ChihChengLiang commented #176
  • Mar 28 2019 02:20

    ChihChengLiang on master

    deprecate repo Merge pull request #177 from Ch… (compare)

  • Mar 28 2019 02:20
    ChihChengLiang closed #177
  • Mar 28 2019 02:19
    ChihChengLiang opened #177
  • Mar 10 2019 08:27
    gitcoinbot commented #152
  • Jan 24 2019 11:20
    hrishikeshio opened #176
  • Jan 24 2019 07:46
    kuhnchris commented #110
  • Jan 24 2019 07:40
    hrishikeshio commented #110
  • Jan 21 2019 22:10
    kuhnchris commented #110
  • Aug 22 2018 21:01
    vs77bb commented #152
  • Aug 22 2018 21:01
    gitcoinbot commented #152
terence tsao
@terenc3t
Set crystallized_state.dynasty += 1
Let next_start_shard = (shard_and_committee_for_slots[-1][-1].shard_id + 1) % SHARD_COUNT
Set shard_and_committee_for_slots[CYCLE_LENGTH:] = get_new_shuffling(block.parent_hash, validators, crystallized_state.dynasty, next_start_shard)
Danny Ryan
@djrtwo
Yeah, I think it is going to be set dynasty_start = crystallized_state.last_state_recalc
Need to add initial values for dynasty start and some other vars as well
terence tsao
@terenc3t
Cool. I’m now implemeting dynasty transition for pryzm. Let me know if there’s other vars we should init when you get a chance : )
Danny Ryan
@djrtwo
Nice! I mainly implemented today. Have just those two fixes now. Adding some testing tmw
Mamy Ratsimbazafy
@mratsim

I’ve ported the fork choice rule to Nim: https://ethresear.ch/t/beacon-chain-casper-ffg-rpj-mini-spec/2760/13 and https://github.com/status-im/nim-beacon-chain/tree/master/beacon_chain/fork_choice_rule.

This is typed (including different hash types for block hashes and signature hashes).

It’s not v2.1 ready though and completely stand alone from the rest of the beacon chain.

isan_rivkin
@Isan-Rivkin
Hi, Casper FFG Question: How is Casper resistent to Long-Range Attacks ? I know usually PoS uses "checkpoints" every few blocks. This is a very centralized solution. Is Ethereum going to do this differently ?
Alex Stokes
@ralexstokes
@Isan-Rivkin the general idea is that Casper clients will sync the chain at least once every so often. This frequency, the withdrawal period, can be tuned so that it minimizes the feasibility of a long-range attack while not demanding too much of clients. It is a pretty big change in security model from a purely proof-of-work consensus. https://ethereum.stackexchange.com/questions/15659/what-is-weak-subjectivity and the linked blog post https://blog.ethereum.org/2014/11/25/proof-stake-learned-love-weak-subjectivity/
isan_rivkin
@Isan-Rivkin
@ralexstokes Thanks!
Benjamin Cordes
@benjyz
isn't Pow/PoS switch completely different in this regard? Nxt was pure PoS. in such a system much depends on the initial allocation. I think the big disadvantage of a switch is that it messes with the initial conditions ("weak immutability" if you will). i.e. at some point when things scale there is no mandate to make a decision to switch.
Grady Laksmono
@glaksmono
So, when are you guys going to launch this?
Jacques Wagener
@jacqueswww
when it's ready.
:P
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<vbuterin> btw is anyone from lighthouse and nimbus in here?
Jacek Sieka
@arnetheduck
@vbuterin ping
Danny Ryan
@djrtwo
lighthouse is asleep in australia
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<vbuterin> 👌 👌
<vbuterin> just want to make sure we're including everyone
<vbuterin> 😊
Jacek Sieka
@arnetheduck
thought lighthouses are needed when it's dark ;)
Paul Hauner
@paulhauner
All the ships have GPS now, turns out we’re not really needed. That’s why we pivoted from illumination to entropy and validator management.
Danny Ryan
@djrtwo
🤣
wanderingbort
@wanderingbort
Hello! Is this the best channel to ask casper protocol questions? Or is it focussed on the testnet/contract?
Danny Ryan
@djrtwo
This is a good place
wanderingbort
@wanderingbort
So, I think I'm missing a key part of the base protocol, I'm going to throw up a case (probably look dumb) and learn i the process :)

Give this block tree:

 Root
    /\
   /  \
 C'1  C"1
  |    |
 C'2  C"2
  |    |
 C'3  C"3
  |    |
 C'4  C"4

and these super majority votes:
Root -> C'1
Root -> C"2
C'1 -> C'3
C"2 -> C"4

Haven't we finalized checkpoints C'1 and C"2 on disparate forks without violating any of the slashing conditions?

Danny Ryan
@djrtwo
Neither C’1 nor C’’2 is finalized. You have to have a supermajority link to a direct child to finalize the parent. Root -> C’1 finalizes root. That is it for finality here
wanderingbort
@wanderingbort
Ah, so finalized requires a supermajority vote where h(t) - h(s) == 1?
Danny Ryan
@djrtwo
yes — from the casper paper "A checkpoint c is called finalized if it is justified and there is a supermajority link c → c′ where c′ is a direct child of c."
wanderingbort
@wanderingbort
yes, thats what I'm reading. I admit it is there. As that becomes a very important quality of the rest of the paper, if I may suggest, giving that link a proper name and defining it more explicitly may help avoid people like me in the future looking dumb :)
Danny Ryan
@djrtwo

You’re right. This is a common source of confusion and could be made clearer in the paper. Even pointing out that it is a common source of confusion and should be noted!

and you don’t “look dumb”. there’s a lot going on in the paper and you clearly a groking it. Glad you came here to ask

wanderingbort
@wanderingbort
Ok, so given the slashing conditions. Lets say all validators reveal their votes simultaneously. If finality must proceed by exactly 1, a reveal of 50/50 split of votes for Root -> C'1 and Root -> C"2 put the protocol in a state where no finality can proceed without an altruistic slash. Which means that proper game theory is to wait to establish a higher justified checkpoint as guidance. However, as voting for a justified checkpoint at any height puts you at risk of not being able to vote for the finality of that height (lest you violate the h(t1) == h(t2) slashing condition) you also cannot really vote in the blind there. It seems like being the first to reveal is far riskier than being the last to reveal and I am trying to figure out the mitigation for that so that game theory doesn't lead stake to stop casting votes out of fear or being put into a position where they must resign or be slashed.
the leap-frogging votes was what I thought was the path out of that pickle. But it was obviously not (and had other problems)
wanderingbort
@wanderingbort
actually, now I'm really confused. Even a vote for a link whose h(t) - h(s) > 1 means you have to slash yourself to vote for the link that can be used for finality because that would be a different link with h(t) - h(s) == 1 but h(t) is the same between these votes which is a slash. I must be off the right path so, I'm going to hunker down, light a campfire and wait for help haha
Oh, crap. Ok. its that finality is not necessarily built on finality. Finality can skip several blocks as it is built on justified links with a specific form of link after it.
I think I'm square now.
wanderingbort
@wanderingbort
@djrtwo thanks for the insights!
Danny Ryan
@djrtwo
Hi! havent had a chance to look through your comments. Glad to help! Holler if you have other questions
Eth-Gitter-Bridge
@Eth-Gitter-Bridge
<nagydani> Hi,
Maybe, it is worth posting it here as well. After pestering @Hsiao-Wei Wang (hwwhww) with stupid questions to fill in the gaps in my understanding how Serenity was going to get started, I decided to write it all up so that a) I do not forget b) others might have an easier time figuring it out. Feedback of any kind, very much including criticism is most welcome:
https://medium.com/@daniel_20027/ethereum-serenity-for-dummies-d21dce9c0487
Nico Vergauwen
@kyriediculous
Cool, wil definitely have a read!
Liang ZOU
@liangdzou
Is “Casper the Friendly Ghost” started to implement? Where is the code?
Nick Savers
@nicksavers
Liang ZOU
@liangdzou
thanks :-)
Nick Savers
@nicksavers
@liangdzou Another more recent piece of code is also available, which can be found here https://github.com/cbc-casper
Mamy Ratsimbazafy
@mratsim
FFG != CBC
@liangdzou you can refer to this for more casper resources: https://github.com/status-im/athenaeum/blob/master/ethereum_research_records.json#L265-L323
argh Friendly Ghost != FFG :/ so confused by the names
Liang ZOU
@liangdzou
@nicksavers @mratsim thx for your kind help :-)
daq1130
@daq1130
Hi! I'm quite new to Casper and i'm doing some FFG research now. May I ask is there a way for me to customise my casper contract if I use Harmony docker to run a testnet? let's say, I want to change the transaction rate or block percentage. Because so far from what I ran i realise a lot of things are pre-defined.
Thank you very much