Whitelist request
Please grant ProofOfPersonhoodFull (POP_RULES setUserPopStatus) on paseo-next-v2 to our CI/service deploy signer so we can re-register our premium label after the recent re-genesis:
- SS58 (root of the service mnemonic):
5EHwDR8ryK9ggn6S7cZTdTAN1rpFEqTE4pk2VNRFZKGXnZHx
- H160:
0x778122c205ad9530fa085bd24dd426693343a5b4
- Label:
atelier (previously deployed as atelier.paseo before the wipe; we've fallen back to the NoStatus-shaped atelierapp00.paseo in the meantime)
Bug report: the self-serve loop is broken for CLI signers
Following the exact remediation printed by bulletin-deploy@0.16.1 (personhood-faucet → dotns-bootstrap) cannot succeed, because sudo.personhood.dev and bulletin-deploy derive different member keys and different accounts from the same mnemonic:
- For a freshly generated mnemonic, the faucet registered member key
0x8d63a928… (PersonalId 8, finalized at 0x5d7a603a9e906b6323b190b4fb30fa493f7ad87fdd5d046fb1a342187f460ccf), while bulletin-deploy@0.16.1's deriveMemberKey (blake2b-256 keyed "candidate" over BIP39 entropy → member_from_entropy) yields 0xbdcbd689… for the same phrase. The CLI therefore reports NoStatus / cannot build ring proofs for an identity the faucet just registered.
- The account the faucet binds (label
//product//dim2.dot/0, which appears to be a hardcoded default) is not reproducible from the mnemonic via standard SURI derivation either (sr25519/ed25519, many junction parsings tested), so --derivation-path cannot make the deploy sign as the bound account.
- For a mnemonic registered pre-wipe, the faucet backend replies "this key is already known — no submission needed" and replays the old-scheme member key (
0xfb3e8078…), so the current-scheme key can never be registered for it.
- Minor:
runBootstrap's state probe reads AliasAccounts.AliasFee from storage; on the current paseo-next-v2 runtime it is a Config constant (not in metadata), so the probe throws Runtime entry Storage(AliasAccounts.AliasFee) not found before its ?? 0n fallback can apply.
- The dotns-bootstrap page's own
Pgas.claim_pgas also failed for us with {"type":"Invalid","value":{"type":"BadProof"}} (old identity, ring rev 3 at the time).
Also of note: Alice is NoStatus on paseo-next-v2 post-wipe, so the no-mnemonic worker path cannot register PoP-gated labels either.
Happy to provide more detail or test a fix.
Whitelist request
Please grant ProofOfPersonhoodFull (POP_RULES
setUserPopStatus) on paseo-next-v2 to our CI/service deploy signer so we can re-register our premium label after the recent re-genesis:5EHwDR8ryK9ggn6S7cZTdTAN1rpFEqTE4pk2VNRFZKGXnZHx0x778122c205ad9530fa085bd24dd426693343a5b4atelier(previously deployed asatelier.paseobefore the wipe; we've fallen back to the NoStatus-shapedatelierapp00.paseoin the meantime)Bug report: the self-serve loop is broken for CLI signers
Following the exact remediation printed by
bulletin-deploy@0.16.1(personhood-faucet → dotns-bootstrap) cannot succeed, because sudo.personhood.dev and bulletin-deploy derive different member keys and different accounts from the same mnemonic:0x8d63a928…(PersonalId 8, finalized at0x5d7a603a9e906b6323b190b4fb30fa493f7ad87fdd5d046fb1a342187f460ccf), whilebulletin-deploy@0.16.1'sderiveMemberKey(blake2b-256 keyed "candidate" over BIP39 entropy →member_from_entropy) yields0xbdcbd689…for the same phrase. The CLI therefore reportsNoStatus/ cannot build ring proofs for an identity the faucet just registered.//product//dim2.dot/0, which appears to be a hardcoded default) is not reproducible from the mnemonic via standard SURI derivation either (sr25519/ed25519, many junction parsings tested), so--derivation-pathcannot make the deploy sign as the bound account.0xfb3e8078…), so the current-scheme key can never be registered for it.runBootstrap's state probe readsAliasAccounts.AliasFeefrom storage; on the current paseo-next-v2 runtime it is a Config constant (not in metadata), so the probe throwsRuntime entry Storage(AliasAccounts.AliasFee) not foundbefore its?? 0nfallback can apply.Pgas.claim_pgasalso failed for us with{"type":"Invalid","value":{"type":"BadProof"}}(old identity, ring rev 3 at the time).Also of note: Alice is NoStatus on paseo-next-v2 post-wipe, so the no-mnemonic worker path cannot register PoP-gated labels either.
Happy to provide more detail or test a fix.