先明确研究对象与主张
“椭圆算法”在这里应明确为椭圆曲线密码学相关算法。核验前，应把研究主张写清楚：讨论的是曲线参数、签名算法、交易中的验签规则，还是软件实现的速度与安全性？这些问题需要不同证据，不能用同一份介绍文档全部回答。
两个来源分别支持什么
Bitcoin Developer Guide 的 Transactions 页面以 P2PKH 交易说明公钥哈希、签名与脚本验证的关系，并介绍 ECDSA 与 secp256k1 的使用。这支持理解该交易类型的授权机制，不能直接推广为所有区块链、所有交易类型都采用同样方案。
RFC 6090 汇总椭圆曲线密码学的基础算法，范围限定于特征大于三的有限域，并列出互操作性、实现验证和安全考虑等章节。它属于信息类 RFC，不能仅凭 RFC 编号将其称为互联网标准轨规范。
让结论与证据逐项对应
研究声称算法符合定义时，需要对应公式、参数和适用条件；声称用于某种交易时，需要对应协议及脚本规则；声称性能提高时，则需要实验记录。两个不同发布主体的来源可以补充背景，但来源数量不能替代对同一结论的直接支持。
核验记录应包含文献名称、章节位置、版本信息以及具体支持的主张。只有目录或节选时，能确认主题被列出，尚不能确认章节中的测试方法、数据或结论。
实现与实验应怎样核验
实现核验需要明确曲线参数、输入编码、消息处理方式及签名验证条件，并保留可复核的输入、预期输出和实际结果。有效签名能通过，只覆盖正常路径；错误消息、异常编码等情况是否按规则被拒绝，也需要证据。
性能比较需要交代硬件、软件版本、编译设置、测试任务和统计方法。签名生成与验签属于不同任务，结果不能直接混比。实验材料不足时，结论应限定在已展示的条件内。
常见问题与适用边界
验签成功是否证明整笔交易有效？交易指南明确保留其他验证条件，因此签名检查通过只是其中一环。基础算法文档是否证明具体产品安全？还需要实现、密钥处理和运行环境方面的证据。
两份参考文献是否足以证实研究成果？关键在于它们是否直接支持目标主张。基础文档适合解释概念与规则；具体优化、安全保证或项目成果，需要对应的证明、代码或实验材料，不能由一般原理推定。