pocx: render bech32 P2WPKH addresses in user-facing account/signer messages#2
Merged
Merged
Conversation
…ssages
Operator-facing log lines and JSON-RPC errors that referenced a plot or
the effective signer printed the 20-byte hash160 as raw 40-char hex,
forcing operators to manually re-encode the value to map it back to the
pocx1q... form their wallet, get_assignment, and the rest of the chain
tooling display.
Render those identifiers via EncodeDestination(WitnessV0KeyHash{...}),
mirroring the pattern already used in get_assignment
(src/pocx/rpc/assignments.cpp). Address HRP follows the active chain, so
testnet/regtest produce tpocx1.../rpocx1... respectively.
The hex form is still computed and passed to wallet lookup APIs
(interfaces::Wallet::haveAccountKey, signPoCXBlock,
pocx::mining::HaveAccountKey), so the wallet-check contract is unchanged
- only the human-facing strings are reformatted.
Touched messages:
- src/pocx/rpc/mining.cpp (submit_nonce):
* "Plot %s has assignment, checking key for effective signer: %s" log
* "Wallet holding key for effective signer %s is locked..."
JSONRPCError(RPC_WALLET_UNLOCK_NEEDED)
* "No private key available for effective signer %s (plot: %s)"
JSONRPCError(RPC_INVALID_ADDRESS_OR_KEY)
- src/pocx/mining/scheduler.cpp:
* "[Scheduler] Trying %zu wallet(s) for effective signer %s" log
- src/pocx/mining/block_builder.cpp:
* "[BlockBuilder] Building block for account %s (...)" log
* "[BlockBuilder] Plot: %s, Effective signer: %s at height %d" log
- src/pocx/mining/wallet_signing.cpp:
* "Account ID: %s -> CKeyID: %s" -> "Signing for account %s"
(the original printed the same hash twice in different reversed-hex
forms; collapsed to a single bech32 line)
* "No ScriptPubKeyMan found that can sign for account %s" log
Refs PoC-Consortium/bitcoin-pocx#3
JohnnyFFM
added a commit
that referenced
this pull request
May 10, 2026
…ssages (#2) Operator-facing log lines and JSON-RPC errors that referenced a plot or the effective signer printed the 20-byte hash160 as raw 40-char hex, forcing operators to manually re-encode the value to map it back to the pocx1q... form their wallet, get_assignment, and the rest of the chain tooling display. Render those identifiers via EncodeDestination(WitnessV0KeyHash{...}), mirroring the pattern already used in get_assignment (src/pocx/rpc/assignments.cpp). Address HRP follows the active chain, so testnet/regtest produce tpocx1.../rpocx1... respectively. The hex form is still computed and passed to wallet lookup APIs (interfaces::Wallet::haveAccountKey, signPoCXBlock, pocx::mining::HaveAccountKey), so the wallet-check contract is unchanged - only the human-facing strings are reformatted. Touched messages: - src/pocx/rpc/mining.cpp (submit_nonce): * "Plot %s has assignment, checking key for effective signer: %s" log * "Wallet holding key for effective signer %s is locked..." JSONRPCError(RPC_WALLET_UNLOCK_NEEDED) * "No private key available for effective signer %s (plot: %s)" JSONRPCError(RPC_INVALID_ADDRESS_OR_KEY) - src/pocx/mining/scheduler.cpp: * "[Scheduler] Trying %zu wallet(s) for effective signer %s" log - src/pocx/mining/block_builder.cpp: * "[BlockBuilder] Building block for account %s (...)" log * "[BlockBuilder] Plot: %s, Effective signer: %s at height %d" log - src/pocx/mining/wallet_signing.cpp: * "Account ID: %s -> CKeyID: %s" -> "Signing for account %s" (the original printed the same hash twice in different reversed-hex forms; collapsed to a single bech32 line) * "No ScriptPubKeyMan found that can sign for account %s" log Refs PoC-Consortium/bitcoin-pocx#3
JohnnyFFM
added a commit
that referenced
this pull request
May 10, 2026
…ssages (#2) Operator-facing log lines and JSON-RPC errors that referenced a plot or the effective signer printed the 20-byte hash160 as raw 40-char hex, forcing operators to manually re-encode the value to map it back to the pocx1q... form their wallet, get_assignment, and the rest of the chain tooling display. Render those identifiers via EncodeDestination(WitnessV0KeyHash{...}), mirroring the pattern already used in get_assignment (src/pocx/rpc/assignments.cpp). Address HRP follows the active chain, so testnet/regtest produce tpocx1.../rpocx1... respectively. The hex form is still computed and passed to wallet lookup APIs (interfaces::Wallet::haveAccountKey, signPoCXBlock, pocx::mining::HaveAccountKey), so the wallet-check contract is unchanged - only the human-facing strings are reformatted. Touched messages: - src/pocx/rpc/mining.cpp (submit_nonce): * "Plot %s has assignment, checking key for effective signer: %s" log * "Wallet holding key for effective signer %s is locked..." JSONRPCError(RPC_WALLET_UNLOCK_NEEDED) * "No private key available for effective signer %s (plot: %s)" JSONRPCError(RPC_INVALID_ADDRESS_OR_KEY) - src/pocx/mining/scheduler.cpp: * "[Scheduler] Trying %zu wallet(s) for effective signer %s" log - src/pocx/mining/block_builder.cpp: * "[BlockBuilder] Building block for account %s (...)" log * "[BlockBuilder] Plot: %s, Effective signer: %s at height %d" log - src/pocx/mining/wallet_signing.cpp: * "Account ID: %s -> CKeyID: %s" -> "Signing for account %s" (the original printed the same hash twice in different reversed-hex forms; collapsed to a single bech32 line) * "No ScriptPubKeyMan found that can sign for account %s" log Refs PoC-Consortium/bitcoin-pocx#3
JohnnyFFM
added a commit
to PoC-Consortium/bitcoin-pocx
that referenced
this pull request
May 15, 2026
Add scripts/mining/test-regtest-submitnonce-key-gate-v2.sh covering every
branch of the receive-path probe (HaveAccountKey) plus the multi-wallet
iteration semantics:
A Absent watch-only descriptor; expect -5 + bech32 + no raw-hex regression
B Locked encrypted+locked privkey; expect -13 + walletpassphrase hint
C Available unlocked privkey; expect exit 0 + raw_quality/poc_time
D Multi Locked + Available, Locked loaded first
(probe must traverse past Locked to pick Available)
E Multi Available + Locked, Available loaded first
(later Locked must not downgrade an earlier Available)
D + E together prove the {Locked, Available} probe outcome is order-
independent, ruling out "break on first Locked" and "Locked overrides
later" regressions. Each case loads its wallets in isolation and unloads
between cases so the probe state under test is unambiguous.
Regression guards for:
#4 (PR PoC-Consortium/bitcoin#3) - Absent/Locked split
#3 (PR PoC-Consortium/bitcoin#2) - bech32 rendering
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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
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
Operator-facing log lines and JSON-RPC errors that referenced a plot or the effective signer printed the 20-byte hash160 as raw 40-char hex, forcing operators to manually re-encode the value to map it back to the
pocx1q…form their wallet /get_assignment/ the rest of the chain tooling display. This PR renders those identifiers viaEncodeDestination(WitnessV0KeyHash{…})— same pattern already used inget_assignment(src/pocx/rpc/assignments.cpp:104-108).Address HRP follows the active chain, so testnet/regtest produce
tpocx1…/rpocx1…respectively.The hex form is still computed and passed to wallet lookup APIs (
interfaces::Wallet::haveAccountKey,signPoCXBlock,pocx::mining::HaveAccountKey), so the wallet-check contract is unchanged — only the human-facing strings are reformatted.Refs PoC-Consortium/bitcoin-pocx#3
Touched messages
src/pocx/rpc/mining.cpp(submit_nonce):JSONRPCError(RPC_WALLET_UNLOCK_NEEDED)"Wallet holding key for effective signer %s is locked…"JSONRPCError(RPC_INVALID_ADDRESS_OR_KEY)"No private key available for effective signer %s (plot: %s)"src/pocx/mining/scheduler.cpp:src/pocx/mining/block_builder.cpp:src/pocx/mining/wallet_signing.cpp:Before / after
Before:
After (mainnet):
(testnet →
tpocx1…, regtest →rpocx1….)Test plan
cmake --build build).submit_nonce, confirm the error string containsrpocx1…for both identifiers.submit_noncefor a plot it does hold, confirm theRPC_WALLET_UNLOCK_NEEDEDerror containsrpocx1….tpocx1…) and mainnet (pocx1…) if available.