Final Request From the GPU Mining Community

core-devs
mining

#21

EIP-1295 will be discussed during tomorrow’s developer call. I will be presenting it.

I will address your claim that “Uncle rates are driven by latency - a product of centralization” is patently false.

Latency is the single driver of Uncles.

With centralization of work package distribution (mining pools), there is latency introduced that can be otherwise avoided when solo mining. Hence, latency is a product of centralization.

Mining nodes are hit with three levels of latency:

Latency with the Ethereum node network — the time it takes for the mining node to receive notification that a new pending block is available.
Latency with the miners — the time it takes for the mining pool to send new work packages to its miners + the time it takes for a miner to send a potential solution back to the mining pool.
Latency in propagating a “solved” block — the time it takes for a mining pool to distribute its valid block solution to 51pct of the Ethereum network.

There are some areas where a mining pool/node CAN minimize latency:

Invest in low-latency fiber connectivity.
Invest in best-in-class compute servers (including SSD storage).
Increase their exposure to the Ethereum network (connect to more peers).
Trim their transaction queue size to minimize computing requirements.

There are some areas where a mining pool/node CANNOT manage latency:

**The latency of its miners to the pool itself (think home internet latency).**
The latency of network peer connections.
The block propagation advantage larger pools have to their own miners.

Let’s quantify some of the latency:

Mining node block propagation — 200ms to 500ms
Block Import / Transaction Processing — 100ms to 150ms
Mining pool to miner latency — 100ms to 500ms
Miner to mining pool latency — 100ms to 500ms

This puts our aggregate range of latency from 400ms to 1650ms.

If a target block round is 15sec, it’s possible a valid block may not be propagated for 1.65sec!!! That’s an 11pct delay under normal operating conditions! That also defines the lower boundary of the network wide uncle rates.


#22

@AtLeastSignificant You hyper aggressive tone belies you motives. Over and out.


#23

Top line incentives - yes - I did a bad job not defining this - I mean only block rewards that are not ommer related.


#24

This is correct. What is incorrect is that latency is a product of centralization. It’s the product of decentralization, no?

Now that I’ve read your comment though, I think I misunderstood the original statement because the argument you make I would call an issue with the decentralization of miners with respect to pools, but you’re saying the existence of pools (centralized block creation) is the issue. Same thing. I agree with your expanded explanation, and I see why you called it a problem with centralization now. Thanks for the detailed response


#25

Why, whenever we discuss lowering the block reward, do we only talk about whole numbers of ether?

Instead of 5 to 3, or 3 to 2, why not 3 to 2.9, and then after X thousand blocks 3.9 to 3.8, X thousand blocks later to 3.7. That code would take four minutes to write, so it’s not a technical issue. Is it a lack of imagination or something else? Is it because we would become central bankers if we did that?

Why not lower issuance 1 Szabo per block for the next 1,000,000 blocks (which would be about 1 ether over the next half year)?

This decision is based on seat of the pants arguments, and if we’re going to be central bankers anyway, why not experiment with small moves and have time to react to adverse effects in between?


#26

Honestly, we don’t talk about whole number or anything particularly creative because it doesn’t matter. You can’t guarantee security with issuance unless you have one that adapts to spot price, and that will never happen.


#27

Why all the hulaballoo about issuance then?


#28

Ignorance? People upset with the price and thinking decreasing “inflation” will somehow help? From what I’ve seen, the majority of the hulaballoo is coming from investors, not developers or technologists.


#29

So they made a decision to reduce issuance from 3 to 2 and postpone difficulty bomb. Anti-ASIC algo change not going to happen now at least until 8 months from now. My guess it will never happen. I am going to laugh my ass off when Ethererum is < $100 when they try to reduce the issuance and the network goes to zero hash. Good luck guys, just sold all my Ethereum from over 2 years of mining. See you below $100.

Next time listen to your miners six months ago and fork ASICs off. You did not want a fork to get in the way of Casper release this year and then drug your feet to even get Casper done. The ASICs killed Ethereum as miners had to liquidate holdings to pay for costs. RIP ETH.


#30

Why even spend the time to write this?

I’m just as disappointed in the decision, as well as how it was reached, but I’m confident that the developers and community aren’t consciously sacrificing the network and will stand by and let it be cannibalized by ASICs.

As far as I’m concerned, I did pretty much all I could do to educate the community and voice an opinion to those who actually matter. I never expected it to change anything, but seeing as how many developers bent to the public “outcry” for their vote, maybe that’s just how governance works now.


#32

Please check if you can suggest changes to make this list shorter: What has to be done to get ProgPoW on Ethereum.