在比特币上「留一句话」的正统做法是 OP_RETURN：一个明写「这是数据不是钱」的专用输出。但早在 2012 年，Greg Maxwell 给出过一条更含蓄的路：把数据的哈希揉进公钥里，造出一枚数学上等价、外观完全普通的地址——链上看不出任何异样，知情者却能用数据原文验证承诺。这就是 Pay to Contract（P2C，付给合约）。它没有成为一个功能按钮，却作为一种技巧活在多个系统的地基里，是「链上承诺」这门手艺的祖师级方案。
构造：一步椭圆曲线加法
回忆椭圆曲线的妙技：公钥等于私钥乘基点，而任何人即使不知道私钥，也能给公钥「加一个已知数」——p 乘 G 再加 k 乘 G，等于「p+k」乘 G，对应的新私钥是 p+k。P2C 用这个性质搭三步：第一步，发送方与收款方约定要承诺的数据原文（哈希前），算出它的哈希 H；第二步，取收款方公钥 P，计算微调量 k = H(P 与 H 拼接的哈希)，得到新公钥 P’ = P + k·G，P2C 输出的锁定脚本就是一枚用 P’ 生成的普通样子；第三步，链上只留下这枚地址——数据本身一个字都不上链。验证是反着走：出示数据原文，重算哈希、重算微调、重算公钥，对得上就证明「这个输出确实承诺了这份数据」。而只有知道 (p+k) 的人花得动这笔钱，承诺不妨碍资金使用。
与 OP_RETURN 的利弊账
把两条路并排放。体积：P2C 不增加输出数量，链上足迹与普通转账几乎无异；OP_RETURN 额外挂一个显式数据字段。隐私：P2C 在链上分析眼里就是一笔普通付款，谁在什么场合用了它，外人默认看不出来；OP_RETURN 一眼可辨。验证：P2C 需要验证者手里有数据原文加公钥来源（通常来自付款方留底或协议约定），OP_RETURN 自带原文、谁都能直接读。灵活性：P2C 承诺的是一个哈希，原文无限大都行但必须自存；OP_RETURN 直接把原文（在限额内）刻上链。一句话总结：P2C 用「必须自证与保管原文」换「体积与低调」，两种数据上链哲学的分歧延续至今——铭文与 Runes 走的是把内容直接刻进输出的张扬路线，P2C 走的是相反路线。
活在哪里
它从未被写进某个大产品的功能清单，但以技巧形态至少有三处活体。其一是承诺-揭示类协议：先付一枚 P2C 输出锁住承诺，时机到了再公布原文证明当时已表态，拍卖与抢先声明类设计常用这个骨架。其二是 Liquid 等基于 Elements 的系统：机密交易的收款地址要把「脚本加盲化公钥」打包进一个看似普通脚本的输出，官方文档与编码提案（blech32）明确把这种 key tweaking 描述为 pay-to-contract 式手法——这是 P2C 最大规模的现役应用。其三是各类链下状态系统（早期状态通道与侧链的存证输出）用 P2C 写周期性的状态摘要。另外，Taproot 的脚本树承诺用的是另一套哈希构造，概念相近、代数不同，常被混为一谈，值得在词条层面分清。
快速问答
问：P2C 输出会被普通钱包看见吗？ 答：能被扫到，但它对不掌握 tweak 逻辑的钱包就是一枚不认识的外来地址；做审计要按协议重算 tweak 才能认领。
问：承诺的数据丢了怎么办？ 答：承诺无法找回即无法出示，等于永久失去证明能力；所以 P2C 系统都强调原文与公钥输入的备份纪律，这是它最容易被忽视的运维成本。
问：为什么它没被钱包直接支持成收付款功能？ 答：因为双方必须在下单前就「承诺什么、怎么验」达成一致，这是协议协调问题而非软件开关问题，大众支付场景不需要这层复杂度。
常见误区
一是把 P2C 理解成数据真写进了链——链上只有地址与哈希的影子，原文必须另有保管。二是把 tweak 想成加密——它是公开的确定性推导，保护不了原文内容，只提供「可验证的绑定」。三是把机密地址与 P2C 划等号；Liquid 的 tweak 沿用的是同源手法，但服务于不同的脚本结构，细节有实质差异。
风险提示：自行构造或识别承诺输出涉及资金安全，务必先在测试网演练；涉及存证用途时原文灭失即证据灭失，请遵守备份与法律规范；本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。