Live data from Hacker News

Mainnet Merge Announcement

blog.ethereum.org

341–350 of 609 posts

Re: Mainnet Merge Announcement

#341
post #151

What we see in the Tezos chain (liquid/delegated proof-of-stake) is that big custodial wallets for the exchanges have grown to be the largest block bakers: https://thestackreport.xyz/articles/top-tezos-block-producer... With ethereum the staking mechanism is a bit more complex, my understanding is you lock your stake for quite a while so maybe its too risky for the exchanges, but wouldn't be surprised that exchanges…

There’s already a bunch of delegated staking options for ETH2, including Lido, RocketPool and Coinbase.[1]

Once withdraws are enabled this landscape may change. There is a lot more work that needs to be done to improve decentralized staking pools, if they continue to expand they can consume large percentage of the total staked Eth with less concern than centralized staking services like Coinbase.

One of the big problems with Tezos is that the governance is tied to the stake. This means in practice most users will not have much of a say in governance because the largest stakers will consume most of the votes. The only thing that has stopped this so far is that large CEX stakers are voting Pass, but this act of goodwill may not always be the case in the future.

[1] https://research.paradigm.xyz/staking

Re: Mainnet Merge Announcement

#342

Earlier quoted context omitted.

It's determined by the majority of validators. There's two ways this can go - either the majority of validators enforce OFAC sanctions, effectively giving OFAC authority over the entire Ethereum network since validators who go against it will be slashed, or the majority of validators don't enforce sanctions, in which case validators with any presence in the US must put themselves in legal jeopardy to avoid getting sl…

Sorry that's not correct. See https://news.ycombinator.com/item?id=32582316

[deleted]

Re: Mainnet Merge Announcement

#343

Earlier quoted context omitted.

Compared to similarly functioning systems that are decentralized and distributed? Yes.

Bitcoin and Etherium are probably amongst the most inefficient cryptocurrencies on the market.

Is this analysis based on technical details of protocols? Or their economics? If latter, then I must object. Tx on one chain is not the same as tx on other chain. They are not interchangeable.

Re: Mainnet Merge Announcement

#344

Earlier quoted context omitted.

It's a worthy ideal but it doesn't shape up in reality. 75% of current eth clients are one implementation[0]. Beacon is a little better but it looks like it could be heading that way (with Prysm already being well over half). I would have loved to contribute to client diversity but my experience with non-geth and non-prysm clients has been so bad I did what it looks like everyone else does - throw my hands up and jum…

Client diversity has improved in recent months, particularly consensus clients: https://clientdiversity.org/

For beacon that is definitely better than the last time I looked. However geth is still 75% and relevant to the topic of the merge, roughly 88% of current clients aren't ready for it[0]!!!

It will be interesting to see what these numbers look like when the merge actually happens...

[0] - https://ethernodes.org/merge

Re: Mainnet Merge Announcement

#345
post #228

Earlier quoted context omitted.

Never. PoW is a fundamental part of what makes bitcoin valuable.

It's also fundamentally limits the growth potential of BTC. In a PoW system, the amount of work done must be proportional to the total value of all BTC (if not, it would make 51% attacks feasible). So if BTC uses an Argentina's worth of energy now, if the value of BTC grew 10X it would have to use on the order of 10 Argentina's worth of electricity. Obviously, that is not sustainable, and it ensures BTC can never gro…

Have you seen a graph of global energy use over time? It goes up.

Re: Mainnet Merge Announcement

#346
post #290

Earlier quoted context omitted.

I should point out that because Ethereum is a dark forest[0], slashers will collapse to a subset of stakers. More specifically, anyone who is not a staker is at the mercy of the mempool[1] to broadcast their slashing transaction and at the mercy of other stakers to correctly record it. There is no economic incentive to do so, and no way to constrain the software such that stakers cannot manipulate the slashing messag…

This isn't exactly correct: 1. Every full node is part of this dark forest, maintains its own mempool, and gossips the mempool to others. You do not have to be a validator or miner to run a full node; just run an Ethereum client. 2. There are indirect economic incentives to 'watch the watchmen': a slashable staking violation that doesn't get slashed breaks the Ethereum security model, and is expected to be an extreme…

Every full node can still manipulate the transaction to make it look like they are slashing rather than the person who originally reported the fraud. This is also a "hey why not, its free money" kind of incentive.

I do agree that there probably will be altruistic validators in some cases, but the economic incentives work against them. The history of cryptocurrency has trended towards doing the minimum amount of validation work that satisfies network consensus[0]. It's entirely possible that the market just shrugs its shoulders and says that a violation of the Ethereum security model just isn't actually that bad. Consider the relative lack of concern over MEV[1] and automated arbitrage bots, and the fact that the valuation of the coin is entirely unconnected to any security issues it may or may not have. It may just wind up being the case that the network just... tolerates a handful of people getting screwed.

[0] For example, Bitcoin miners accept new blocks by literally joining other mining pools purely to steal their previous block hash. It's significantly faster than waiting for a full 4MB block to get P2P gossiped around the world, but the downside is that you can't actually validate any of the data in that block. This effectively means that miners aren't full nodes anymore, and the result has been several long chainsplits and reorgs whenever a softfork occurs.

[1] Miner Extractable Value

Re: Mainnet Merge Announcement

#347

Earlier quoted context omitted.

node software is pretty bad but alot of us run custom clients and know there is major room for improvement, with Go-Ethereum being the worst one this doesn't address what you need to do for the merge but definitely look into node software thats not written in Go. The rust ones are 10x faster and use 90% less time and space to sync (an archive node) than Go-Ethereum writing node software doesnt make money so its negle…

Agreed! Have any pointers? I've looked around plenty and all of the non-go clients I've tried (for mainnet and beacon) have had pretty serious issues - wrong/invalid data, missing blocks, various other weird edge cases, stability, etc. It definitely is neglected. Alchemy isn't worth $10B because they're just running geth... It's a vicious circle - node software sucks so anyone serious that needs things to "just work"…

pay attention to gitcoin grants

contribute code to projects like Akula and Silkworm

continue raising awareness about shitty open source node software underpinning all of this

Re: Mainnet Merge Announcement

#348

Earlier quoted context omitted.

I know what the technical meaning is, but if you're going to argue for the usefulness of crypto you need to argue why the consensus that crypto achieves is actually useful, instead of just acting as if this is obvious.

No, you don't need to demonstrate that at all. This could just as easily be a decentralized database for counting the number of jellybeans that exist on pluto and that word would still mean the same thing.

Yes you do. If you wish to argue that 'if crypto then useful', and you want to use the proposition 'if crypto then consensus', then you also need to provide something to support the proposition 'if consensus then useful'. You can substitude jellybeans on pluto or whatever else you want in the middle, the point is there are two steps necessary to the argument and only one is actually well supported.

Re: Mainnet Merge Announcement

#349

I can be anti-crypto and still appreciate this. First - clearly reducing the environmental impact of anything by this much is pro-humanity. (Although having the impact to begin with is another story.) Secondly from a sheer technical coordination perspective there's a feeling of pulling off a complex dance. Makes it hard for any of us to claim our workloads aren't testable!

> First - clearly reducing the environmental impact of anything by this much is pro-humanity. How long until BTC follows suit?

Satoshi consensus is essentially the bible to their cultural ideology.

You can bridge bitcoin to another chain with faster finality, smart contracts, and environmental consensus.

But at the end if the day there will still be a huge amount of people who will never deviate from the core ideology.

Re: Mainnet Merge Announcement

#350

Earlier quoted context omitted.

Let me make sure I get this right: if you have two chains, one is mined by 49% hash power, the other is mined by 51% hash power, you think the 51% one won't be the longer one?

As I've explained in nearly every comment, one is mined by 100% hashpower, the other is mined by 51% hashpower. The 49% are still using the other blocks, too.

This is where your mistake is: they can't be using the other blocks as well, because they are erasing their own (uncensored) transactions by doing so.

Let's say that MiningPoolA controls 51% of hashpower, and MiningPoolB controls 49%. MiningPoolA is refusing to mine transactions from/to some wallet W.

  Time T1:
    MiningPoolA: OldChain -- Block1(no W)
    MiningPoolB: OldChain -- Block1'(W receives 1BTC) still in progress

    Any client will accept the chain with Block1 (no transactions from/to W)

  Time T2 - if MiningPoolB tries to compete
    MiningPoolA: OldChain -- Block1(no W) -- Block2 (no W)
    MiningPoolB: OldChain -- Block1'(W receives 1BTC) -- Block2' (parent=Block1') still in progress
  
    Any client will accept the chain with Block1 (no transactions from/to W), and MiningPoolB will never be able to catch up

  Time T2 - if MiningPoolB decides to accept MiningPoolA's chain, but add the transaction in the second block:

    MiningPoolA: OldChain -- Block1(no W) -- Block2 (no W)
    MiningPoolB: OldChain -- Block1(no W) -- Block2' (parent=Block1, adds transaction W receives 1BTC) still in progress
    
    Any client will accept the chain with Block1 (no transactions from/to W), and MiningPoolB will never be able to catch up

If a mining pool had 51+% of hashpower, they would always be mining the longest chain, no one would be able to compete with them and publish another block (in principle, at least; in practice, since mining is not entirely deterministic, someone else will occasionally win the lottery and propose a new block faster).
Post reply on HN