feat(consensus): raise registration PoW target to 28 bits at HF4 (anti wallet-spam) - #76
Closed
DDerona wants to merge 2 commits into
Closed
feat(consensus): raise registration PoW target to 28 bits at HF4 (anti wallet-spam)#76DDerona wants to merge 2 commits into
DDerona wants to merge 2 commits into
Conversation
…i wallet-spam) Client-side registration miners were optimized (increment-optimized nonce search) and now hash ~10-20x faster, which makes mass wallet registration cheap again and enables regpool flooding / wallet-spam attacks that previously occurred. The historical 24-bit target was calibrated around the old slow hashing, so this restores the per-wallet cost of registration. - Add MAJOR_HF4_HEIGHT to mainnet/testnet config (TODO: set real height). - Add transaction.RegistrationPoWSolved(bits) helper; 28 bits = 3 zero bytes plus a zero high nibble on byte 3 (16x harder than 24 bits). - Enforce the 28-bit target at HF4 in the mempool and block validation; keep the 24-bit rule before the fork. The fork rule is derived from chain height through a single registrationPoWRequiredBits(height, hf4) helper so it lives in one place. - CLI and webwallet registration miners always target 28 bits: a 28-bit winner also satisfies the 24-bit check, so wallets stay valid on both sides of the fork, and Engram can keep its optimized loop (old hardware still registers in ~30-50 min instead of hours). 🤖 Generated with Codebuff Co-Authored-By: Codebuff <noreply@codebuff.com>
The 1.1GB build/ directory from `go build -o build/...` was untracked and unprotected, so an accidental `git add .` would stage a gigabyte of binaries. Ignore it. 🤖 Generated with Codebuff Co-Authored-By: Codebuff <noreply@codebuff.com>
Author
|
Closing as superseded by #122 — the HF5 registration-activation cooldown (availability-style: a wallet becomes usable 50 blocks ≈ 15 min after registration, layered on top of this HF4 PoW bump). Keeping this PR's PoW discussion as the motivating context. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Raises the registration PoW target from 24 to 28 leading zero bits at a new HF4, restoring the per-wallet anti-spam cost of wallet registration after client-side mining loops were optimized (~10-20x faster hashing). This addresses a wallet-spam / regpool-flooding attack class that has occurred before.
⛔ REQUIRED BEFORE MERGE
MAJOR_HF4_HEIGHTis currently a placeholder:90000003000000Set the real activation heights before this merges. The fork rule stays dormant until then (the placeholder values are far in the future), but shipping with placeholder heights would be unsafe.
What changed
config:MAJOR_HF4_HEIGHTadded for mainnet/testnet (TODO: real height).transaction:RegistrationPoWSolved(bits)helper — 28 bits = 3 zero bytes plus a zero high nibble on byte 3 (16x harder than the historical 24).blockchain: mempool and block validation enforce 28 bits at HF4 and keep the 24-bit rule before the fork, via a singleregistrationPoWRequiredBits(height, hf4Height)helper.dero-wallet-cli/webwallet: registration miners always target 28 bits.Why "always 28" on the client
A 28-bit winner trivially satisfies the 24-bit consensus check, so wallets mined at 28 remain valid on both sides of the fork — a wallet mining 24-bit right at the fork could be rejected. Optimized clients (Engram) keep their fast loop while old hardware still registers in ~30-50 min instead of hours, and the per-wallet spam cost returns to pre-optimization levels.
Verification
MAJOR_HF4_HEIGHT = 0(fork active from genesis):go build ./...andgo test ./transaction/pass.