by

Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Apr 06 2018 21:05
    @holiman banned @PhunioBCC
  • Oct 21 2017 21:22
    @jpitts banned @vickyissabox_twitter
  • Oct 10 2017 22:29
    @jpitts banned @etherchamp2
MJ Dillon
@mjdillon
if "rent" is done deterministically, then the next time the contract is accessed, a validator would check if there is enough Eth to pay the rent since the last activity at that then-current size
Micah Zoltu
@MicahZoltu
Unless you store a full history of that, you will need to make sure to deduct anytime a state change occurs.
MJ Dillon
@mjdillon
right
Micah Zoltu
@MicahZoltu
:+1:
MJ Dillon
@mjdillon
any activity, even if it's a 0 change in size, would update that amount to the current amount
and a validator could delete it from state if the rent is due
I still don't like the idea or rent, but if it's calculable, people could determine long in advance when it would be deleted
and any account could just send Eth to a contract to keep it alive
ironically, updating/checking the state counter by doing that.
err, state-size
perhaps there could be a financial incentive to the miners to delete stale state entries.
it really would need to be infantesimally small for it not to destroy the idea of interconnected smart contracts
and frankly, the involatile gas market, even after the surge in the price of Eth scares me that the network would be too expensive to function properly
Ankit Chiplunkar
@ankitchiplunkar_twitter
I wanted to download the whole blockchain in humanreadable format, but I get an error after EIP155.
Link below is a detailed question:
https://ethereum.stackexchange.com/questions/15849/scraping-ethereum-blockchain-in-human-readable-format-csv
cdetrio
@cdetrio
@ankitchiplunkar_twitter the develop branch of pyethereum/pyethapp doesn't yet have EIP155 support. try the state_revamp_with_p62 branch
Micah Zoltu
@MicahZoltu
@mjdillon Gas prices aren't a function of ETH price. They are a function of miner/validator rewards and block time.
So IF you believe that moore's law allows us to "ignore the state bloat problem" then you necessarily must believe that the cost to store something on chain for "longer than anyone will care" must necessarily be cheaper than current storage costs (assuming current storage costs are accurately priced). So either a no-rent system will fail, or a rent system will succeed indefinitely for the same price.
I don't believe that it logically makes sense to believe that "infinite storage duration" is going to be cheaper than "insanely long storage duration".
IMO this leaves the only remaining arguments for non-rent solutions:
  1. solution complexity costs
  2. risk that someone forgets to pay rent on some storage they depend on
From what I have heard, the second is the one everyone is afraid of, and I do believe it will happen.
Micah Zoltu
@MicahZoltu
I also believe that working in blockchains is a place filled with dragons and that is something that I accept in exchange for having a truly free economy, including free from leechers, attackers, bad engineers, etc. because the system has a mechanism for culling them over time (by causing them to bleed money).
I'm not looking to smart contracts for happy pony space where anyone can put whatever badness they want up and expect it to probably generally work. If you want that go write code on the internet.
Mahen Rathod
@MahenRathod_twitter
@All, looking for getting industry certification on Ethereum. Can you suggest the best ones?
MJ Dillon
@mjdillon
@MicahZoltu I don't disagree with the way you feel about dragons and danger, but part of the appeal of these systems is on chain elements working with one another. Bits and bobs dissappearing over time adds another level of potential problems, and rightly scares people.
Micah Zoltu
@MicahZoltu
Yeah, I recognize the fear. I remember the left-pad issue. :)
None the less, I do not think that it is fair to punish the entire ecosystem (storage prices are way higher than necessary) because some people are afraid.
MJ Dillon
@mjdillon
True, but while something is being designed is the time to ask "is there a better way to do this?"
Micah Zoltu
@MicahZoltu
Yeah, I am looking forward to hearing of a solution to the storage problem that doesn't punish everyone but also isn't rent. :)
Roland Kofler
@rolandkofler
What I still don't understand is what validator selection algo will be chosen. Nothing proposed is as elegant as Hashcash. It is especially interesting because deterministic pseudorandom selection means I can predict the next validators. If I can predict them then I can coerce/ bribe them.
Filippo Merli
@Fi3
I do not understand how the proposal mechanism illutstrated here https://medium.com/@VitalikButerin/minimal-slashing-conditions-20f0b500fc6c works.
For example: must the validator use a message like PREPARE and COMMIT to propose an hash? Something like [PROPOSE, epoch, HASH, epoch_source]
SE question: https://ethereum.stackexchange.com/questions/15837/casper-proposal-mechanism
Ben Mahala
@Lisk115
you prepare and commit an existing blockhash to finalize it. validators generate new blockhashes depending on the selection algo. Every validator can prepare and commit (and get rewards) every block.
Filippo Merli
@Fi3
ty. If a validator propose a bockhash that is not finalised the validator is slashed?
Ben Mahala
@Lisk115
No, you're only slashed if you equivocate (eg send conflicting prepares and commits).
Filippo Merli
@Fi3
ok ty. Last thing what happen if a validator propose an hash that can not be finalised? Are there consequences?
Ben Mahala
@Lisk115
No, not as a slashing condition anyway, but I don't know the current details of block generation. There would probably be something to keep people from spamming bad blockhashes out of order. Probably would keep other nodes from even accepting it.
you're not rewarded for generating blockhashes (I believe), just from sending valid prepares and commits.
And it is done on chain. There's a work in progress casper contract somewhere around here. Let me see if I can find it
Filippo Merli
@Fi3
very clear ty vm :)
Nick Johnson
@Arachnid
@rolandkofler There is no 'next validator'; all validators participate in all blocks.
Roland Kofler
@rolandkofler
@Arachnid brilliant. So it is majority voting? The FAQ mentions "Majority beacon" by bentov. Is it that?
Nick Johnson
@Arachnid
More or less. Nodes commit to hashes, and when a majority commit to a given hash, that's the one that's agreed on
Jeremy
@dulcetdiver
Hey friends, can you guys give me some feedback on how the ethereum guide is looking? I'm finally adding in ethereum and how it works. What do you all think? https://docs.google.com/document/d/1W-oEkQeOVuy7auVo3V4Li_cGROzzWQf9DYDycME87z8/edit?usp=sharing
Roland Kofler
@rolandkofler
Interesting. voting instead of sampling secures the network faster as you don't need to wait famous 6 bitcoin confirmations to get enough nodes opinions.
Roland Kofler
@rolandkofler
Is it mandatory for PoS that Validators have known identities?
Roland Kofler
@rolandkofler
Proof of stake consensus fits more directly into the Byzantine fault tolerant consensus mould, as all validators have known identities
Nick Johnson
@Arachnid
I don't see how you could do PoS without it
Roland Kofler
@rolandkofler
How will I register my identity as a validator? Will the entire network know my Identity?