341–350 of 465 posts
Earlier quoted context omitted.
what happens when everyone on the chain discards old transactions?
That would be bad. Archive nodes are needed.
Except, you know, "trust us, this will never happen". Given that blockchain size is now 346GB while it handles a fraction of a fraction of a fraction of the number of transactions that the rest of the world runs.
Earlier quoted context omitted.
No matter what your validating gives you in the end you can only accept the current final state of the running network or not use it at all. I'm a bit of a blockchain noob, but isn't this the opposite of how blockchain works? What I mean is, yes, you can design it the way you're saying, but doesn't that open you up to double-spend attacks and enforced centralization? You need a central ledger at that point, since you…
If you have a final state double-spend attacks are actually impossible. They are based on the fact that someone can insert a transaction then "overwrite" it by providing a longer chain where the transaction didn't happen or went somewhere else. This is only ever possible if there is no final state. Also not sure why you would need centralization for what. Simplified a final state is when a majority declares it as fin…
Earlier quoted context omitted.
Yes everyone with a passing familiarity knows this. People knowledgeable see the obvious scaling problems
The only people who claim Ethereum can't scale are those who claim Lightning Network can scale, and have aggressively silenced any one who says otherwise within the Bitcoin space for the last six years, while declaring themselves to be the only experts on the issue.
The really obvious weakness in any blockchain setup is the software. Whoever controls the software upgrade channel will always have potential control of the blockchain, whether that's the official entity in charge, or some intermediary. If you want really widespread distribution of full nodes, you need to make a consumer-friendly distribution of the node software, and package it and keep it updated in a way that regu…
I agree, updating full node software is a problem for normal users. However, if we can develop a core set of first layer software that's stable enough, it could go many years without needing an update. And individual users may only need to update some of those times. So at least the burden could be arbitrarily low. But we certainly shouldn't have set-and-forget auto updating software - that would be a huge security flaw.
Earlier quoted context omitted.
Miners control bitcoin more than people realize.
Less than most actually. Most have no practical means to act against the interest of pools, whose operators have most of the real control that people ascribe to miners.
One thing blockchain scalability conversations often miss is the concept of induced demand [1]. City streets and computer hardware and blockchain throughput. We dream that 'make bigger, make faster' will alleviate congestion in all of these places, and make our commute and compute as fast and cheap as we want it to be. But in practice, commuters are programmers are blockchain users. For commuters, if more lanes get a…
Earlier quoted context omitted.
The only people who claim Ethereum can't scale are those who claim Lightning Network can scale, and have aggressively silenced any one who says otherwise within the Bitcoin space for the last six years, while declaring themselves to be the only experts on the issue.
Who cares who claims what? It's more important to hear the reasons behind the claims. Vitalik makes excellent points about tolerances and safety margins needed in decentralized networks like this. People who call for increasing the key parameters almost never acknowledge the fact that things aren't as simple as what some fast machines can process in ideal conditions.
Vitalik is consistently one of the most interesting people to follow in the blockchain space. Even his (5+ year) old writing is quite interesting, if nothing else to see how Ethereum's research thinking has evolved over time. A few questions re: why "Ethereum is not going further than quadratic [sharding]." The first reason given: there's a minimum number of nodes required for shard for safety guarantees. So, a coupl…
It is always preferred to require less resources. There must be a healthy balance. If Ethereum accomplishes what a lot of us hope, allowing home-hobbyists to run nodes and at least break-even in staking or profit a small amount will be crucial. Relying on goodwill from a small amount of technically-adept-yet-centralized operators is how we get to the Tor situation where everyone knows the government runs most of the…
I'm talking about being paid crypto for hosting a tor node, and charged crypto for using a tor node. Using privacy technologies like ring signatures of course.
Earlier quoted context omitted.
When I talk to people in the world about what about blockchains they find exciting, the aspect of permanence really is one of the things that people find attractive. I agree it's use-case dependent, but the problem is that once you go down the use-case-dependence rabbit hole, developers and users have to really think "am I creating something permanent or not"? And once you have to think even a little bit, you lose 50…
> Definitely nothing is permanent, but you can get pretty close to "permanent unless civilization collapses" Let's be honest here and acknowledge that we're talking about "permanent unless your particular fork of one particular blockchain collapses". There's a vast chasm between that and all of civilization.
Earlier quoted context omitted.
>I dont care how my coins was moved 10 years ago. The only storage that is relevant for me, now, for value transfer is the current undisputed state I don't have anything to add, but this has always struck me as inelegant, especially for Ethereum, which is more of a dApp platform. Can someone point me towards something that can run dApps and maintain current state with distributed consensus _without_ a blockchain (or…
> Also, what's wrong with truncating the chain after X blocks? I would say nothing. Truncating history isn't explicitly built into the protocol, but that's what most users do in practice. I believe Geth and Parity both prune old state by default. There are "achive" nodes that store all history, but they're in the minority. Bitcoin Core also has options for pruning old state, and for disabling some validation of old h…
As part of your expected obligations of the network, you're asked to seed those blocks.