Articles about 'Ethereum'

…a piece of open source software called an Ethereum node collects together a random, unordered collection of transactions, and after throwing out the invalid ones, puts the rest in a well-defined order.

The system then seals this newly ordered list for the rest of human history (modulo re-orgs) by creating a 32-byte block hash that stands in a one-to-one correspondence to that ordered list.

The system then quickly moves on to a newly growing collection of unordered transactions, leaving behind it a trail of sealed blocks.

This the second in a series of two articles detailing Ethereum’s issuance. Read the first part, which discusses the blockReward calculation. Also, see the code base for the actual code. This article discusses the uncleReward.

Uncle Reward

Previously, we looked at the ungrammatical second sentence in Section 11.3 of Ethereum’s Yellow Paper. In the first article, we discussed the first half of that sentence concerning blockReward. In this article we discuss the remaining half of that sentence (shown below) which details the uncleReward.

Recently, there was a dustup on Crypto Twitter (started here, carries on here) about Ethereum’s money supply. The claim was made that Ethereum’s money supply was not easily available, nor was it widely agreed upon.

News flash: Both of these claims are right.

At one point, our project, TrueBlocks, was mentioned, so I thought I’d write an article (which has grown into two articles and a code base) exploring the issue.

While the work we present here doesn’t necessarily make the numbers easier to get (fix the node!), the numbers are accurate to 18-decimal places and verified to the on-chain account balances at every block. We used TrueBlocks to do that.

• The Liberal Radicalism Mechanism for Producing Public Goods [Tabarrok]
• Experiments With Liberal Radicalism [Singh]
• Liberal Radicalism: Breaking down Buterin, Hitzig and Weyl
• Some Gentle Criticisms on Vitalik/Gitcoin CLR [van Ness]
• A Simple Way to Fund Public Goods [van Ness]
• Radical Market, ZK, Privacy and More [Buterin]
• Wikipedia: Quadratic Voting

Eth Research

• A Proposal to Improve Pairwise Coordination Subsidies
• Pairwise Coordination Subsidies: A New Quadratic Funding Design [Buterin]
• A Strange Kind of Pairwise-Bounded Quadratic Funding
• Negative Votes in Quadratic Funding [Buterin]
• On Collusion [Buterin]

Round 2

• Gitcoin Grants: $50K Open Source Fund

Round 3

• Gitcoin’s Q3 Match: $100K+ to OSS projects
• CitCoin’s $4.6m in Results
• Review of Gitcoin Quadratic Funding Round 3
• Gitcoin’s Q3 Match: The Radical Results

Round 4

• Review of GitCoin Quadratic Funding Round 4 [Buterin]

Round 5

• Gitcoin Grants Round 5 Retrospective
• Top Gitcoin Grants For $250k Matching Round 5

News

• Vitalik Buterin Lauds Public Participation in Gitcoin Grants CLR Round 3
• Vitalik Buterin on Effective Altruism [and] Public Goods
• Vitalik Buterin Highlights Grants for Open Source

Tweets

• Vitalik Tweet: Link to Round 3 Analysis
• Gitcoin Tweet about Offering Private Goods

Other

• Grants Round 3 CLR — Data Analysis Bounty

There is no more angst-ridden profession than being a member of a bomb squad. You’ll know what I’m talking about if you’ve ever seen the movie The Hurt Locker. In a recent Gitter post in the All Core Devs channel, Alexey Akhunov says of the difficulty bomb that it, “…forces people to make rushed decisions and be reckless, without real emergency…” This is true currently, but we can do better.

In a previous article, I mentioned two questions that arise each time we discuss the Ethereum difficulty bomb: “How soon will the block times become intolerable?” and “For how many blocks should we reset the bomb?” I presented in that article a simple method to decide the second of these two questions. In this article, I extend that argument and run through an example. I then try to show why, if we adopted the method I’m proposing, we could answer the first question more predictably, removing some the ‘angst’ or ‘emergency’. Later this week, I will write an article analyzing the current situation and making a prediction of when the block times will become intolerable.

All about the Ethereum Difficulty Calculation

Special thanks to a first-rate Tuftian and data scientist, Ed Mazurek, for early versions of the R code used in this article.

Each time the Ethereum time bomb goes off, two related questions arise. The first question (and arguably the more important) is, “When will blocks get so slow, they will be intolerable”. The second question is, “How long should we delay the bomb this time?”

This is a very short take on something I’ve been thinking about for quite a while. “Why do I give a shit about decentralization? Should I compromise?” Here’s why I come down emphatically on the side of “Yes, I give a shit, and no you should never compromise!”.

Blockchain-like technologies (that is, decentralizing, trustless technologies) bring to the world, for the first time in human history, a way to help us solve the prisoner’s dilemma.

I had a wonderful experience at EdCon in Toronto this week. Mostly because of all the great new people I met and the many people I reacquainted myself with. The Ethereum community is freakin’ cool.

Here’s an example. In between speakers, the person sitting in front of me stood up, turned around, looked down at his seat and, using his pointing finger, counted the number of seats between him and the left isle. He then counted the number of seats between himself and the right isle. Finding that the right-most path was shorter, he existed the auditorium in that direction. He didn’t care which way he went — he cared only about being efficient.

I recently wrote a piece discussing how I defeated the Ethereum DDos attack using TrueBlocks. Doing this was important because it freed me from the pain of a slow RPC. Speed allows me to analyze the Ethereum data iteratively. I can find more interesting stuff.

The Ethereum dataset is big (and growing). I want to be able to scan through the entire thing. I want to be able to do this on a laptop. This last fact makes it impossible for me to create a separate, independent copy of the data. If I want to do data analysis, I have to do it against the node’s data directly.