chainparams: sync the public dogecoin_chainparams with the internal one

[xanimo]

dogecoin_chainparams is declared twice by design — once in the public libdogecoin.h so the installed header stays self-contained, once in the internal chainparams.h. The objects are defined once, in chainparams.c, against the internal declaration and read through the public one. That arrangement works only if the two describe the same layout.

They had drifted. The public copy was missing genesisblockchainwork, strict_id, auxpow_id, pow_limit and minimumchainwork.

Only the first matters for layout, and it matters a lot: it sits in the middle, not at the end, so this was not a harmless truncation. Every field after it landed 32 bytes early.

	public header	actual object
offsetof(default_port)	84	116
offsetof(dnsseeds)	88	120
sizeof	2136	2236

genesisblockchainwork itself is at offset 84 — exactly where the public header put default_port. So a consumer writing the obvious thing:

#include <dogecoin/libdogecoin.h>
printf("%d\n", dogecoin_chainparams_main.default_port);   /* wanted 22556 */

read the first four bytes of the chainwork instead. dnsseeds shifted with it, so the seed list read into the middle of a hostname, and anything that stack-allocated or copied a dogecoin_chainparams was short by 100 bytes. None of it warns — the declaration is self-consistent, just not the one the object was built with.

Blast radius

In-tree code was not miscompiled. I checked every src/ and test/ file that includes libdogecoin.h without also including chainparams.h:

• src/context.c does see the short declaration, but only stores, compares and returns const dogecoin_chainparams* — no field is read through it
• test/context_tests.c reads chainname, which is at offset 0, before the divergence

So this is an installed-header bug, and the people it hit are downstream consumers, not us. Ed's #396 happens to remove both of those in-tree exposures by switching them to include chainparams.h directly — complementary, but it does not touch this.

Change

Adds the missing fields in the order chainparams.c defines them, plus a comment on the declaration saying the two move together. No behaviour change inside the library, per the above. It is an ABI-visible change to the installed header, in the sense that it makes the header agree with an object that has been 2236 bytes all along — consumers need a recompile, and after it they get the right answers.

Test

test/chainparams_abi_tests.c includes only libdogecoin.h and reads the exported objects the way a consumer does. Including both headers to compare them directly is not possible — C forbids redefining a struct tag even identically — so the test checks values instead. They agree only if the declaration a consumer sees matches the one the objects were built with.

Verified against both drift modes rather than assumed:

• remove a field from the public copy → fails at compile time
• insert a field the internal copy lacks → compiles clean with no warning, fails at runtime, default_port reading 1684366707

It asserts on minimumchainwork rather than pow_limit deliberately, so it fails on layout drift only and not on the pow_limit byte-order change proposed in #398.

Registered in both build systems. 79/79 under CMake and autotools.

Noted, not fixed here

auxpow_id is typed dogecoin_bool (a uint8_t) but holds the AuxPoW chain ID — 0x62 on all three networks, not a boolean. Dogecoin's fits in a byte so nothing is broken today, but a chain ID above 255 would truncate silently. Retyping it is a separate change; the test asserts the value it actually holds rather than true.

[edtubbs]

ACK, good catch on the layout drift and great regression coverage as well.