1

Maybe I am wrong and am misunderstanding something, but there is no validation done by the PoS chain.

During the merge... let's say it happens at block #151... the PoW chain passes the blockchain over to the PoS chain to start processing transactions.

Since there is no mechanism in the beaconchain to validate the PoW chain, there is no way for the PoS chain to know that it is receiving a correct chain.

This means that the miner who processes block #151 can modify transactions and pass it along to the PoS chain without them ever knowing.

I have brought this up to some people who watch my youtube channel and they say "but we will know and stop the merge from happening if it happens"

But how? How will anyone know?

Lets say the miner rewrites a block from an account that hasn't been used in years and no one is actively watching. No one is going to notice that. And there is no mechanism in any of the software to notice this.

The solution, I think, would be to not have any transactions occur at block #151. To force geth pass an empty block to the PoS chain at the block height the merge happens. This way we can be sure that no block manipulation has occurred at the merge.

Can someone please either tell me how I'm wrong and this isn't a concern, or pass this on to a dev to look at and do something about?

Thank you.

Itération 122442
  • 2,052
  • 1
  • 12
  • 33
AltcoinXP-Anthony
  • 31
  • 4
  • 1
    Saying you were banned in several places isn't a good introduction. The merging process isn't finished yet. It is likely the problem is known and it will be considered in the design. Perhaps the merge won't be in a single block but it will during a period of time. – Ismael Oct 02 '21 at 18:45

2 Answers2

1

This means that the miner who processes block #151 can modify transactions and pass it along to the PoS chain without them ever knowing.

The only transactions a miner can alter are their own (which is no different to the expected behaviour). All users with transactions in that block will have their transactions pre-signed so they cannot be altered - the worst that could happen is transactions being re-ordered.

Lets say the miner rewrites a block from an account that hasn't been used in years and no one is actively watching. No one is going to notice that. And there is no mechanism in any of the software to notice this.

How do you propose that the miner signs a transaction with a private key for an account that hasn't been used in years and the miner presumably does not know?

michaelb
  • 11
  • 2
0

This was resolved a week or so ago in the merge spec. They are using a difficulty level instead of block height to determine when the merge will happen. This makes it less likely for a miner to push an incorrect chain to eth2, because they cannot guess when that difficulty level will be achieved.

The answer that michaelb gave is incorrect, a miner can change any transaction in the chain, not just their own. And private keys do not matter when that miner is the one who is validating those key pairs and the eth2 chain is not. If there is only one person who can prove the truth, they cannot be trusted.

Edit: I am being asked to edit my comment for blatant false information. Michaelb states that the reason I am incorrect is because all validators need to be synced with the eth1 client (with agreed consensus) at time of merge. That is incorrect. The eth1 client is the execution client, it does no validation or consensus. Even pre-merge these is no code or requirement that geth and similar eth1 clients have consensus on which blocks are valid (other than at previous block heights of past forks). Sure, you can update geth for that requirement (and require all validators to be on that client or else they will slash and fork), but this was not in the spec at the time of my post (and I'm unaware it's in the spec now, though I don't see why it wouldn't be implimented). I did not spread blatantly false information. I posted correct information at the time of my post to a problem that was not resolved (nor even even mentioned by devs) at the time of my post.

AltcoinXP-Anthony
  • 31
  • 4