先明确“老地址”核验的对象
通常所说的比特币老地址，主要是以公钥哈希为基础的传统地址格式，例如与P2PKH输出相关的地址。资料显示，地址并不是公钥本身，而是对公钥进行哈希后，再加入网络版本信息和错误检测校验和，并编码成便于传输的字符串。因此，核验网络参数时，实际要确认的是：地址编码中携带的版本字段是否属于目标网络，以及解码后的数据能否形成预期的锁定脚本。
这项核验只能说明一个地址字符串在某个网络规则下是否格式有效，不能证明该地址属于某个矿工、矿池或特定历史人物，也不能仅凭地址格式判断其是否曾经收款、是否仍有余额。交易历史和UTXO状态需要另行通过区块链数据核对。
网络参数包含哪些信息
传统地址通常由版本字段、哈希载荷和校验和组成。版本字段用于区分网络或地址用途；哈希载荷通常来自公钥哈希；校验和用于发现输入错误。验证程序应将这些部分分别解析，而不是只根据首字符作经验判断。
地址类型也必须单独确认。P2PKH输出的锁定脚本会对提供的公钥执行哈希，并要求结果等于输出中预先指定的公钥哈希，随后再验证签名。由此可见，一个看似有效的地址还要与相应的脚本类型匹配，不能把所有传统地址都按同一种脚本解释。
RFC 4648讨论了Base编码中的字符表、填充、非字母字符和规范表示等问题，但它并不定义比特币使用的Base58地址格式。因此，不能拿Base64或Base32解码器直接处理比特币老地址，也不能因为某个字符串符合一般Base编码特征，就断定其网络参数正确。
推荐的核验流程
第一步，固定核验目标。明确要判断的是主网、测试网络还是其他兼容网络，并同时记录预期地址类型。若目标网络未确定，任何“属于某网络”的结论都应保留条件。
第二步，检查字符集。使用与比特币地址相匹配的Base58解码规则，拒绝不属于该字符表的字符，并避免自动删除空格、换行或其他非编码字符。RFC 4648强调，不同编码对非字母字符的处理可能不同；宽松清洗可能掩盖复制错误，甚至造成错误解析。
第三步，拆分解码结果。将结果区分为版本字段、哈希载荷和校验和，检查长度和结构是否符合目标地址类型。版本字段不能只按首字符猜测，应该与所使用网络的正式参数表逐项比较。
第四步，重新计算并比对校验和。只有校验和一致，才能说明字符串在该编码规则下没有明显的传输或录入错误。校验和通过并不等于地址一定属于目标网络，因为不同网络可能使用相似的编码结构；还必须继续比较版本字段。
第五步，生成脚本并交叉验证。对于P2PKH，应依据解码出的公钥哈希构造对应的锁定脚本，再与链上交易输出的脚本进行比较。若脚本类型、哈希值或网络解释不一致，就不能把地址认定为同一个有效目标。
第六步，结合链上事实。若问题涉及某个“挖矿老地址”是否真实使用过，应进一步核对交易中的输出索引、交易标识和UTXO状态。地址格式核验只能验证编码与脚本层面的关系，不能替代交易记录核查。
适用条件与安全边界
上述方法适用于能够明确识别编码规则、网络参数和地址类型的传统地址。对于脚本哈希、隔离见证或其他新格式，应使用对应的地址解码与脚本规则，不能把传统P2PKH流程直接套用。
如果地址来自截图、网页复制或OCR识别，首先应保留原始字符串，不要擅自改变大小写、删除字符或补充符号。RFC 4648关于规范编码和字符表的讨论说明，编码数据的细微变形可能影响唯一表示；虽然比特币Base58不是RFC 4648定义的编码，但“严格区分字符表和规范处理”的原则同样适合作为核验习惯。
不要向任何核验工具输入私钥、助记词或签名材料。验证地址网络参数只需要公开的地址字符串，以及在需要进行链上交叉验证时使用公开交易数据。
常见问题
问：地址首字符能否直接决定网络？答：不能作为唯一依据。首字符只是编码结果的外观，最终仍应解码并检查版本字段、校验和及地址类型。
问：校验和正确是否代表地址属于主网？答：不代表。校验和主要用于发现数据错误，网络归属还要看版本字段与目标网络参数是否一致。
问：能否用RFC 4648的Base64工具核验？答：不能。RFC 4648规范的是Base16、Base32和Base64等编码，比特币传统地址使用的Base58规则需要专门的解码实现。
问：核验出一个有效老地址，是否能证明它是矿工地址？答：不能。地址格式不会记录所有者身份或职业。只有结合公开交易、区块奖励相关输出及其他独立证据，才可能对其历史用途作进一步分析。