Hacker News new | past | comments | ask | show | jobs | submit login

Can you just hash a new solution to the puzzle with the new proposed block?



Solution has to depend on the proposed block, so that a solution is not reusable for the next block


The solution is also announced in cleartext, so you can check against previous solutions.


The problem is that when a miner announces a block with a solution, an attacker could immediately announce their own alternative block with the same solution and there would be a chance that the network would take up their block first.


But if the legitimate miner announces & signs a hash of the solution well beforehand, they can prove theirs is the legitimate solution.


Then that adds a delay to each block being broadcast to the network. It also means that the longer a miner waits to broadcast the block, the more time a different miner has to finish a proof-of-work and claim the next block first. Miners are all racing each other, so they're all going to try to wait the most minimum amount.

The logic around only accepting a block if you previously saw a signed hash is vulnerable to sybil attacks. An attacker could run thousands of nodes on the p2p network, never relay anyone else's signed hashes, steal the proof-of-works from completed blocks and then broadcast signed hashes of its own blocks with the stolen pows and then broadcast those blocks. Many users might find themselves connected to only nodes run by the attacker and would get tricked into accepting the attacker's chain.

The proof-of-work not depending on the blockchain state means that a miner could queue up lots of complete proof-of-works and then mint a ton of blocks with them all at once to do a 51% attack.

Any solution to this is either going to be centralized or look like proof-of-stake, and at that point, the proof-of-work is extra and not actually load-bearing at all.


Ok, not being usable for the next block is not enough. It must not be usable for any other block. Competing chains, forks, other miners stealing your rewards, etc. Has to depend on the hash of the previous block, and also the transaction where you send the reward to yourself (-> even if someone else "steals it", you get the reward so it doesn't matter).




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: