karlfloersch/casper_chat_log.txt

## casper_chat_log.txt
09:08:37	 From Joseph Chow : (Time 1 seems dangling in these slides)
09:09:01	 From jonchoi : +1
09:10:04	 From lanerettig : BTC POW currently burns as much energy as Ecuador… not a tiny country
09:11:18	 From jonchoi : yep also worth mentioning PoS uses potential value at loss as the incentive as opposed to realized opex in PoW
09:12:04	 From lanerettig : what does “finality” really mean in a world where someone can disagree, rewind, and fork anyway?
09:12:30	 From @M : I think it means they can’t rewind and fork?
09:12:46	 From danny : it would require manual intervention
09:12:53	 From danny : can always fork :)
09:16:09	 From @M : Is Phil’s question presenting a difference between a “protocol changing fork”, and a reorganization which just rewinds and builds on a previous block?
09:19:53	 From aparnakrishnan : Is there any reason for choosing 50 blocks to be the epoch?
09:20:18	 From danny : tradeoff between protocol overhead and time to finality
09:20:36	 From Joseph Chow : "attempt" at finality (every 50 blocks)?  what if not successful?
09:20:42	 From narush : try again next epoch
09:20:57	 From narush : + maybe some punishments for not achieving it.
09:21:09	 From lanerettig : yea the punishments increase as time since finality increases
09:21:19	 From Philip Daian : 50 blocks seems insanely short w 5 sec block times
09:21:27	 From jonchoi : yep. danny is correct. for more detailed discussion: https://medium.com/@VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735
09:22:09	 From Philip Daian : committee rotation every 4 mins?
09:22:13	 From aparnakrishnan : How long are we assuming block propagation at the network level takes?
09:22:16	 From Philip Daian : also I don't see anything about network delay
09:22:17	 From Philip Daian : yeah
09:22:19	 From lanerettig : 12 sec
09:22:22	 From lanerettig : +/-
09:22:31	 From aparnakrishnan : How does 5 second block times work then?
09:22:35	 From narush : yeah, ffg doesn’t change block time for now
09:22:50	 From danny : pow block times would be the same
09:22:53	 From danny : +1
09:23:00	 From Philip Daian : 12 sec for propagation also seems very low
09:23:13	 From Philip Daian : for block interval maybe
09:23:23	 From jonchoi : yep, same block time, where is the 5 sec block time coming from?
09:23:31	 From aparnakrishnan : Which means lower bound on block creation would still be bounded by 12 seconds? (unless more forking?)
09:23:34	 From Philip Daian : from what I hear 5 seconds is the post-PoW goal
09:23:42	 From lanerettig : this is the original analysis: https://blog.ethereum.org/2014/07/11/toward-a-12-second-block-time/
09:23:59	 From jonchoi : 50 block epochs. 2 phase voting for justification + finality. so 50 + 50 + 25 (avg time for the subsequent epoch), 125 block to finality from checkpoint creation.
09:24:09	 From jonchoi : ~35 min
09:24:37	 From aparnakrishnan : Would network propagation delays still be an issue in pure POS?
09:25:03	 From Philip Daian : it's an issue in any possible block proposal protocol I can imagine
09:25:07	 From danny : ys
09:25:09	 From danny : yes*
09:25:10	 From Philip Daian : especially if you're going to be slashing for lack of availability
09:25:20	 From Philip Daian : but even if it's just forfeiting rewards
09:25:47	 From yondonfu : If PoW remains the underlying proposal mechanism, why would miners change their fork choice rule if they know their block rewards will decrease over time - couldn’t they just ignore validator checkpoints and fork off to a non-FFG chain?
09:26:38	 From narush : clients will likely follow this new fork choice at least
09:27:33	 From @M : Maybe the designers are OK with miners creating a non-POS fork, and the assumption is that the POW+POS fork will just be so much more valuable that POW-only will be a minority?
09:29:56	 From Joseph Chow : (let's try to remember to save this chat too, before the zoom call is ended)
09:34:33	 From aparnakrishnan : Could someone who is providing evidence of forking be censored?
09:34:57	 From jonchoi : @yondonfu, great question. per @maurelian, (1) ethereum has long been public about plan to move to PoS, and it can be safely assumed that current price and support “bakes in” a significant level of support around that plan, or else it could have already forked per your point, (2) it is the role of the community and the foundation/research team to continue to make sure that PoS is compelling to all stakeholders in the ecosystem
09:35:00	 From danny : certainly, but they have at least 4 months to get the slashing condition in
09:35:18	 From lanerettig : also, all validators should report on slash able behavior that they see
09:35:27	 From lanerettig : so you’d have to censor all of the honest validators
09:35:35	 From jonchoi : yep, pretty conservative withdrawal period
09:35:48	 From jonchoi : although tbd :)
09:36:21	 From aparnakrishnan : any reasoning for the current withdrawal period?
09:36:37	 From lanerettig : pretty sure ETC isn’t planning to move to PoS, so ppl who don’t like it can go there :)
09:37:20	 From alexisgauba : reasoning behind 4% as finders fee?
09:37:28	 From jonchoi : @aparna, still being optimized but it’s erring on the side of conservatism. tradeoff between liquidity (lower req return for validators and lower issuance vs conservatism to hold bad actors accountable
09:39:09	 From danny : and the frequency with which clients need to sign on to remain synced to chain
09:41:30	 From jonchoi : yes, thank you for mentioning that. although at a magnitude of 4 months, the main tradeoff is not as much about online/offline
09:41:51	 From lanerettig : … unless the validator goes to antarctica
09:41:54	 From lanerettig : or north korea
09:42:06	 From danny : not just validators. clients in general
09:42:33	 From Joseph Chow : I missed what was the difference from the top and the bottom here...why/how does one side get penalized more ?
09:42:47	 From jonchoi : oh i see, for signaling slashing conditions
09:42:50	 From narush : validators are penalized more if they are not voting
09:42:57	 From Joseph Chow : the block after the finalized has the same number of votes
09:43:06	 From aparnakrishnan : How do you decide in the case of a 50-50 split which chain gets penalized more?
09:43:44	 From Joseph Chow : yeh the numbers are 50-50 here on this slide...
09:44:16	 From danny : depends on which chain. if you are signing on a chain, you’ll get less penalized
09:45:06	 From jonchoi : @alexisgauba. rough number explored by vitalik a while back. hasn’t been revisited yet because it’s not as high pri at the moment. again, tradeoff between incentivizing “policing” vs deadweight losses around large redistributions
09:47:38	 From @M : I know this is a basic question, but “What can be said about two forked chains, which both have 2/3 votes at the same checkpoint/height?”
09:48:54	 From danny : at least 1/3 validators get slashed. thus high cost to attack
09:48:54	 From Joseph Chow : i think that means 1/3 of all validators double voted
09:49:18	 From narush : ya, slashed by the NO_DBL_VOTE slashing rule.
09:50:19	 From @M : right, so at least 1/3 are heavily penalized on _BOTH_ chains, thus removing any incentive to support more than one.
09:50:34	 From @M : ya?
09:50:38	 From narush : yep
09:50:47	 From @M : TY\
09:50:48	 From jonchoi : yes. related to this is griefing factor analysis
09:50:48	 From narush : heavily penalized == all their money gone
09:51:08	 From jonchoi : level of slashing TBD actually.
09:51:27	 From jonchoi : we’re exploring “soft slashing” instead of draconian slashing
09:51:56	 From danny : soft slashing if didn’t result in two finalized blocks?
09:52:02	 From danny : and hard if so?
09:52:13	 From jonchoi : slashing amount / penalty will be a function of (1) validator action / byzantine behavior *and* (2) protocol failure
09:52:14	 From jonchoi : yes
09:52:31	 From narush : oh, cool
09:52:46	 From narush : goof to know thx
09:52:54	 From yondonfu : this is not consensus specific but…I assume slashing logic can be baked into clients as an option so anyone that wants to be a finder can watch validators for bad behavior. If a lot of people do this and try to simultaneously trigger a slashing condition, only one of those transactions will succeed while the rest will fail leading the network being flooded with failed transactions right?
09:53:50	 From jonchoi : @narush yes recent development. more coming soon!
09:53:56	 From @M : good question by @yondon
09:57:13	 From narush : a bit like the validators dilemma I guess
09:58:19	 From @M : oh, the contract is the validator.
09:58:59	 From narush : I’m not sure this is a huge concern - can toss out tx once one “slashing proof” gets included in the chain
09:59:53	 From yondonfu : ah right so part of the logic for miners when proposing blocks might just be to throw out other slashing tx if one is already included
10:00:34	 From narush : sure, or if I was a miner would just ignore all slashing proofs from anyone else and publish them from myself (if there is a finders fee :) )
10:00:53	 From @M : ^ that one
10:00:58	 From yondonfu : Lol true
10:01:05	 From danny : which isn’t that bad.. the bulk of the work was done. bad dude was slashed
10:01:22	 From @M : Though, why not process a bunch of tx you know the answer to?
10:01:35	 From @M : REVERT helps here of course.
10:01:45	 From jonchoi : sorry i was multitasking earlier and couldn’t respond. @lane re: finality. it matters for sharding more so than tx finality. read my casper 101 which has more details about why explicit finality matters.
10:01:55	 From narush : I doubt slashing proof will be regular transactions, though
10:02:18	 From narush : “Yeah, gonna slash this validator, right after the BAT ICO is over…”
10:02:28	 From @M : isn’t casper a contract you’d call?
10:02:34	 From @M : for a slash report?
10:02:52	 From jonchoi : @lane re: why 2/3. it has to do with mathematical proof that is underlying BFT theory. specifically that you need to 2n+1 nodes to tolerate n malicious nodes
10:03:07	 From jonchoi : so that’s actually a trade off and we can have different M of N thresholds
10:03:27	 From Martain de la Lundfalafel : Phil do you have your pos idea written up anywhere?
10:03:34	 From jonchoi : 2/3 is the simplest of those, but our threshold for bad actors would decrease as we have higher numbers
10:03:46	 From jonchoi : more info: https://bitcoin.stackexchange.com/questions/58907/byzantine-fault-tolerant-consensus-why-33-threshold
10:03:52	 From lanerettig : @jon thanks!@
10:04:20	 From jonchoi : https://medium.com/@jonchoi/ethereum-casper-101-7a851a4f1eb0
10:04:25	 From jonchoi : search “explicit finality"
10:06:06	 From jonchoi : @yondonfu re: participation
10:06:07	 From jonchoi : https://ethresear.ch/t/casper-macroeconomic-participation-constraint/217
10:06:30	 From yondonfu : @jonchoi cool, thanks!
10:06:51	 From jonchoi : tl;dr we don’t think about participation as a top down % of people with ETH that participate
10:07:07	 From jonchoi : it’s more about exploring the market’s assessment of required risk-adjusted return
10:07:19	 From jonchoi : and making sure that # and mix that we attack is reasonable.
10:07:38	 From narush : does that require changing parameters in the casper contract after launch?
10:07:44	 From jonchoi : key numbers: # of validators, $ of total deposits etc
10:08:03	 From jonchoi : narush, yep. test then prod or prod1 then prod 2 :)
10:08:28	 From jonchoi : think we should be able to have a pretty good hypothesis before launching foreal but yes we should optimize the “fixed income” numerator over time
10:08:30	 From lanerettig : Phil can’t hear you
10:09:08	 From jonchoi : “mix that we attract”**
10:10:44	 From jonchoi : LOL
10:11:23	 From @M : So, I see in the latest version of the paper that a vote message includes the “signature of〈s,t,h(s),h(t)〉from the validatorν’s private key”
10:11:35	 From @M : doesn’t that preclude voting from a contracts?
10:13:23	 From narush : so actually
10:13:50	 From narush : if you check out the casper contract, it actually makes a call to a signature contract to check the signature on the message
10:14:43	 From narush : (doubt this is a final thing), but the idea is that you essentially have some contract saying “yes this is a valid signature on the message from me” based on some rules
10:15:04	 From @M : is there like an ecsign precompile for contracts I forgot about?
10:15:18	 From Joseph Chow : got to go, but please save the chat too
10:15:26	 From narush : I mean, the contract will never be able to sign.
10:15:45	 From narush : but it can define some validity rules.
10:15:58	 From @M : Thus, I cannot put my ETH into a contract to delegate voting
10:16:02	 From jonchoi : oh jeez.
10:16:03	 From jonchoi : lol
10:16:14	 From narush : sure, you just have to delegate to someone (or some validity rules)
10:16:27	 From @M : Ok, I see.
10:16:44	 From narush : ok, gtg, thanks Karl! this was awesome!
10:16:45	 From @M : just some kind delegation mechanism within the casper contract.
10:18:03	 From lanerettig : when a validator signs on via deposit (https://github.com/ethereum/casper/blob/master/casper/contracts/simple_casper.v.py#L241) they can specify any “validation address,” i.e. it doesn’t have to be the address of the contract itself
10:21:07	 From Hsiao-Wei Wang : 👏
	09:08:37 From Joseph Chow : (Time 1 seems dangling in these slides)
	09:09:01 From jonchoi : +1
	09:10:04 From lanerettig : BTC POW currently burns as much energy as Ecuador… not a tiny country
	09:11:18 From jonchoi : yep also worth mentioning PoS uses potential value at loss as the incentive as opposed to realized opex in PoW
	09:12:04 From lanerettig : what does “finality” really mean in a world where someone can disagree, rewind, and fork anyway?
	09:12:30 From @M : I think it means they can’t rewind and fork?
	09:12:46 From danny : it would require manual intervention
	09:12:53 From danny : can always fork :)
	09:16:09 From @M : Is Phil’s question presenting a difference between a “protocol changing fork”, and a reorganization which just rewinds and builds on a previous block?
	09:19:53 From aparnakrishnan : Is there any reason for choosing 50 blocks to be the epoch?
	09:20:18 From danny : tradeoff between protocol overhead and time to finality
	09:20:36 From Joseph Chow : "attempt" at finality (every 50 blocks)? what if not successful?
	09:20:42 From narush : try again next epoch
	09:20:57 From narush : + maybe some punishments for not achieving it.
	09:21:09 From lanerettig : yea the punishments increase as time since finality increases
	09:21:19 From Philip Daian : 50 blocks seems insanely short w 5 sec block times
	09:21:27 From jonchoi : yep. danny is correct. for more detailed discussion: https://medium.com/@VitalikButerin/parametrizing-casper-the-decentralization-finality-time-overhead-tradeoff-3f2011672735
	09:22:09 From Philip Daian : committee rotation every 4 mins?
	09:22:13 From aparnakrishnan : How long are we assuming block propagation at the network level takes?
	09:22:16 From Philip Daian : also I don't see anything about network delay
	09:22:17 From Philip Daian : yeah
	09:22:19 From lanerettig : 12 sec
	09:22:22 From lanerettig : +/-
	09:22:31 From aparnakrishnan : How does 5 second block times work then?
	09:22:35 From narush : yeah, ffg doesn’t change block time for now
	09:22:50 From danny : pow block times would be the same
	09:22:53 From danny : +1
	09:23:00 From Philip Daian : 12 sec for propagation also seems very low
	09:23:13 From Philip Daian : for block interval maybe
	09:23:23 From jonchoi : yep, same block time, where is the 5 sec block time coming from?
	09:23:31 From aparnakrishnan : Which means lower bound on block creation would still be bounded by 12 seconds? (unless more forking?)
	09:23:34 From Philip Daian : from what I hear 5 seconds is the post-PoW goal
	09:23:42 From lanerettig : this is the original analysis: https://blog.ethereum.org/2014/07/11/toward-a-12-second-block-time/
	09:23:59 From jonchoi : 50 block epochs. 2 phase voting for justification + finality. so 50 + 50 + 25 (avg time for the subsequent epoch), 125 block to finality from checkpoint creation.
	09:24:09 From jonchoi : ~35 min
	09:24:37 From aparnakrishnan : Would network propagation delays still be an issue in pure POS?
	09:25:03 From Philip Daian : it's an issue in any possible block proposal protocol I can imagine
	09:25:07 From danny : ys
	09:25:09 From danny : yes*
	09:25:10 From Philip Daian : especially if you're going to be slashing for lack of availability
	09:25:20 From Philip Daian : but even if it's just forfeiting rewards
	09:25:47 From yondonfu : If PoW remains the underlying proposal mechanism, why would miners change their fork choice rule if they know their block rewards will decrease over time - couldn’t they just ignore validator checkpoints and fork off to a non-FFG chain?
	09:26:38 From narush : clients will likely follow this new fork choice at least
	09:27:33 From @M : Maybe the designers are OK with miners creating a non-POS fork, and the assumption is that the POW+POS fork will just be so much more valuable that POW-only will be a minority?
	09:29:56 From Joseph Chow : (let's try to remember to save this chat too, before the zoom call is ended)
	09:34:33 From aparnakrishnan : Could someone who is providing evidence of forking be censored?
	09:34:57 From jonchoi : @yondonfu, great question. per @maurelian, (1) ethereum has long been public about plan to move to PoS, and it can be safely assumed that current price and support “bakes in” a significant level of support around that plan, or else it could have already forked per your point, (2) it is the role of the community and the foundation/research team to continue to make sure that PoS is compelling to all stakeholders in the ecosystem
	09:35:00 From danny : certainly, but they have at least 4 months to get the slashing condition in
	09:35:18 From lanerettig : also, all validators should report on slash able behavior that they see
	09:35:27 From lanerettig : so you’d have to censor all of the honest validators
	09:35:35 From jonchoi : yep, pretty conservative withdrawal period
	09:35:48 From jonchoi : although tbd :)
	09:36:21 From aparnakrishnan : any reasoning for the current withdrawal period?
	09:36:37 From lanerettig : pretty sure ETC isn’t planning to move to PoS, so ppl who don’t like it can go there :)
	09:37:20 From alexisgauba : reasoning behind 4% as finders fee?
	09:37:28 From jonchoi : @aparna, still being optimized but it’s erring on the side of conservatism. tradeoff between liquidity (lower req return for validators and lower issuance vs conservatism to hold bad actors accountable
	09:39:09 From danny : and the frequency with which clients need to sign on to remain synced to chain
	09:41:30 From jonchoi : yes, thank you for mentioning that. although at a magnitude of 4 months, the main tradeoff is not as much about online/offline
	09:41:51 From lanerettig : … unless the validator goes to antarctica
	09:41:54 From lanerettig : or north korea
	09:42:06 From danny : not just validators. clients in general
	09:42:33 From Joseph Chow : I missed what was the difference from the top and the bottom here...why/how does one side get penalized more ?
	09:42:47 From jonchoi : oh i see, for signaling slashing conditions
	09:42:50 From narush : validators are penalized more if they are not voting
	09:42:57 From Joseph Chow : the block after the finalized has the same number of votes
	09:43:06 From aparnakrishnan : How do you decide in the case of a 50-50 split which chain gets penalized more?
	09:43:44 From Joseph Chow : yeh the numbers are 50-50 here on this slide...
	09:44:16 From danny : depends on which chain. if you are signing on a chain, you’ll get less penalized
	09:45:06 From jonchoi : @alexisgauba. rough number explored by vitalik a while back. hasn’t been revisited yet because it’s not as high pri at the moment. again, tradeoff between incentivizing “policing” vs deadweight losses around large redistributions
	09:47:38 From @M : I know this is a basic question, but “What can be said about two forked chains, which both have 2/3 votes at the same checkpoint/height?”
	09:48:54 From danny : at least 1/3 validators get slashed. thus high cost to attack
	09:48:54 From Joseph Chow : i think that means 1/3 of all validators double voted
	09:49:18 From narush : ya, slashed by the NO_DBL_VOTE slashing rule.
	09:50:19 From @M : right, so at least 1/3 are heavily penalized on _BOTH_ chains, thus removing any incentive to support more than one.
	09:50:34 From @M : ya?
	09:50:38 From narush : yep
	09:50:47 From @M : TY\
	09:50:48 From jonchoi : yes. related to this is griefing factor analysis
	09:50:48 From narush : heavily penalized == all their money gone
	09:51:08 From jonchoi : level of slashing TBD actually.
	09:51:27 From jonchoi : we’re exploring “soft slashing” instead of draconian slashing
	09:51:56 From danny : soft slashing if didn’t result in two finalized blocks?
	09:52:02 From danny : and hard if so?
	09:52:13 From jonchoi : slashing amount / penalty will be a function of (1) validator action / byzantine behavior and (2) protocol failure
	09:52:14 From jonchoi : yes
	09:52:31 From narush : oh, cool
	09:52:46 From narush : goof to know thx
	09:52:54 From yondonfu : this is not consensus specific but…I assume slashing logic can be baked into clients as an option so anyone that wants to be a finder can watch validators for bad behavior. If a lot of people do this and try to simultaneously trigger a slashing condition, only one of those transactions will succeed while the rest will fail leading the network being flooded with failed transactions right?
	09:53:50 From jonchoi : @narush yes recent development. more coming soon!
	09:53:56 From @M : good question by @yondon
	09:57:13 From narush : a bit like the validators dilemma I guess
	09:58:19 From @M : oh, the contract is the validator.
	09:58:59 From narush : I’m not sure this is a huge concern - can toss out tx once one “slashing proof” gets included in the chain
	09:59:53 From yondonfu : ah right so part of the logic for miners when proposing blocks might just be to throw out other slashing tx if one is already included
	10:00:34 From narush : sure, or if I was a miner would just ignore all slashing proofs from anyone else and publish them from myself (if there is a finders fee :) )
	10:00:53 From @M : ^ that one
	10:00:58 From yondonfu : Lol true
	10:01:05 From danny : which isn’t that bad.. the bulk of the work was done. bad dude was slashed
	10:01:22 From @M : Though, why not process a bunch of tx you know the answer to?
	10:01:35 From @M : REVERT helps here of course.
	10:01:45 From jonchoi : sorry i was multitasking earlier and couldn’t respond. @lane re: finality. it matters for sharding more so than tx finality. read my casper 101 which has more details about why explicit finality matters.
	10:01:55 From narush : I doubt slashing proof will be regular transactions, though
	10:02:18 From narush : “Yeah, gonna slash this validator, right after the BAT ICO is over…”
	10:02:28 From @M : isn’t casper a contract you’d call?
	10:02:34 From @M : for a slash report?
	10:02:52 From jonchoi : @lane re: why 2/3. it has to do with mathematical proof that is underlying BFT theory. specifically that you need to 2n+1 nodes to tolerate n malicious nodes
	10:03:07 From jonchoi : so that’s actually a trade off and we can have different M of N thresholds
	10:03:27 From Martain de la Lundfalafel : Phil do you have your pos idea written up anywhere?
	10:03:34 From jonchoi : 2/3 is the simplest of those, but our threshold for bad actors would decrease as we have higher numbers
	10:03:46 From jonchoi : more info: https://bitcoin.stackexchange.com/questions/58907/byzantine-fault-tolerant-consensus-why-33-threshold
	10:03:52 From lanerettig : @jon thanks!@
	10:04:20 From jonchoi : https://medium.com/@jonchoi/ethereum-casper-101-7a851a4f1eb0
	10:04:25 From jonchoi : search “explicit finality"
	10:06:06 From jonchoi : @yondonfu re: participation
	10:06:07 From jonchoi : https://ethresear.ch/t/casper-macroeconomic-participation-constraint/217
	10:06:30 From yondonfu : @jonchoi cool, thanks!
	10:06:51 From jonchoi : tl;dr we don’t think about participation as a top down % of people with ETH that participate
	10:07:07 From jonchoi : it’s more about exploring the market’s assessment of required risk-adjusted return
	10:07:19 From jonchoi : and making sure that # and mix that we attack is reasonable.
	10:07:38 From narush : does that require changing parameters in the casper contract after launch?
	10:07:44 From jonchoi : key numbers: # of validators, $ of total deposits etc
	10:08:03 From jonchoi : narush, yep. test then prod or prod1 then prod 2 :)
	10:08:28 From jonchoi : think we should be able to have a pretty good hypothesis before launching foreal but yes we should optimize the “fixed income” numerator over time
	10:08:30 From lanerettig : Phil can’t hear you
	10:09:08 From jonchoi : “mix that we attract”**
	10:10:44 From jonchoi : LOL
	10:11:23 From @M : So, I see in the latest version of the paper that a vote message includes the “signature of〈s,t,h(s),h(t)〉from the validatorν’s private key”
	10:11:35 From @M : doesn’t that preclude voting from a contracts?
	10:13:23 From narush : so actually
	10:13:50 From narush : if you check out the casper contract, it actually makes a call to a signature contract to check the signature on the message
	10:14:43 From narush : (doubt this is a final thing), but the idea is that you essentially have some contract saying “yes this is a valid signature on the message from me” based on some rules
	10:15:04 From @M : is there like an ecsign precompile for contracts I forgot about?
	10:15:18 From Joseph Chow : got to go, but please save the chat too
	10:15:26 From narush : I mean, the contract will never be able to sign.
	10:15:45 From narush : but it can define some validity rules.
	10:15:58 From @M : Thus, I cannot put my ETH into a contract to delegate voting
	10:16:02 From jonchoi : oh jeez.
	10:16:03 From jonchoi : lol
	10:16:14 From narush : sure, you just have to delegate to someone (or some validity rules)
	10:16:27 From @M : Ok, I see.
	10:16:44 From narush : ok, gtg, thanks Karl! this was awesome!
	10:16:45 From @M : just some kind delegation mechanism within the casper contract.
	10:18:03 From lanerettig : when a validator signs on via deposit (https://github.com/ethereum/casper/blob/master/casper/contracts/simple_casper.v.py#L241) they can specify any “validation address,” i.e. it doesn’t have to be the address of the contract itself
	10:21:07 From Hsiao-Wei Wang : 👏