BitVM中文社区
白皮书BTC Layer2生态BitVM生态BTC 2024 会议BTC测试网水龙头社交媒体
  • 社区介绍
  • 成员招募
  • BitVM
    • 📖英文白皮书
    • 📖中英文白皮书
    • 📖BitVM白皮书-详细讲解
    • 🍀BitVM项目概况
    • 🌾基础知识
      • BitVM论文中图1解析
      • 隔离见证的好处
      • Schnorr 签名:简介
      • 谨慎日志合约(DLC):比特币的可扩展智能合约
      • 什么是比特币默克尔化抽象语法树(MAST)?
      • 什么是多重签名钱包(Multisig)?
      • 什么是门限签名(TSS)?
      • 什么是图灵完备
      • 区块、链
      • UTXO与普通账户模型
      • UTXO Vs 普通账户模型
      • PoW共识
      • PoS共识机制
      • 哈希与加密算法
      • 点时间锁合约(PTLC)
      • 基于 Taproot 的闪电通道
      • Taproot 及 MuSig2 回顾
      • Taproot是什么(比特币升级Taproot)
      • SegWit和Taproot是什么?二者之间的差异与各自优势
      • DPoS共识机制
      • 比特币脚本研究
      • 零知识证明介绍
      • Optimistic Rollups
      • Rollup:详解ZK Rollups、Optimistic
  • 👨重要人物
    • Robin Linus
  • BitVM精选文章
    • 与BitVM有关的重要信息
    • BitVM:比特币层计算的突破
    • BitVM 入门
    • 深入探讨BitVM - 表达图灵完备比特币合约的计算范式
    • BitVM and Bridges-侧链桥
    • What is BitVM?
      • What is BitVM? with Robin Linus and Super Testnet (SLP520)
      • BitVM是什么?与Robin Linus和Super Testnet详细讲解
    • Robin Linus on BitVM
      • BitVM:Bitcoin的链下合约
      • BitVM:Off-chain Bitcoin Contracts
      • PPT中文版
      • PPT英文版
    • BitVM:图灵完备的 Taproot 智能合约
    • BitVM 在比特币上实现智能合约
    • 全面解析ZK Rollups和Optimistic Rollups
    • Optimism Rollup原理详解【以太坊L2方案】
    • 要在比特币上计算任何内容,资深开发者们怎么看BitVM?
    • BitVM 是什么?图文讲解
    • BitVM 脑洞大开,复杂概念和落地可行性剖析
    • BitVM:开启比特币的智能合约时代
  • 🆚生态对比
    • 从比特币应用编程理解 CKB 的可编程性
    • BitVM 与 RGB 协议:瞄准比特币生态的“双星”
    • 什么是 RGB 协议?
    • 牛市第一响:BTC L2将造就alpha之王
    • 比特币L2的机会
  • BitVM项目
    • BitVM项目概览
    • Bitlayer
      • Bitlayer 介绍
      • Bitlayer快速了解
      • 一文了解 Bitlayer:构建比特币计算层
      • Bitlayer Research:DLC 原理解析及其优化思考
    • zkBase
      • 为什么市场需要 ZKBase?
      • 了解 ZKByte:基于零知识证明和 BitVm 的比特币 Layer2 拓展解决方案
    • Bitstake
      • Bitstake 简介:基于 BitVM 的权益证明桥
    • Citrea
      • Citrea 概述:比特币首个 ZK Rollup
  • Runes
    • 作者
    • 优质文章
      • 为什么说 Runes 符文赛道即将爆发?
      • 超越BRC20?一文读懂比特币符文协议Runes的前世今生
      • 解读Runes协议:两大发行方式、文化与玩法
      • xiyu 对 Runes 协议的解读:提供了一种在比特币网络上创建和转移符号化资产的方法
      • 解读Runes协议:发展历程及其最新「公开铭刻」发行机制的拓展
      • Ordinals创始人Cesay:首次全面介绍Runes协议
      • Runes预挖矿概念:一文读懂Rune Kingdom符文龙
      • Runes是一个Bitcoin Token Standard协议
      • 一文读懂 Runes 与 BRC20 等同质化代币协议的对比
      • Ordinals创始人首谈Runes协议细节:前10个Runes只支持Open mint
      • 一文看懂BRC20、Atomicals、RUNE等协议的独特之处
    • 视频
      • No129. 什么是符文Runes协议?Runes协议几个关注度高的项目介绍
      • 比特币牛市行情下个热点赛道布局 | 符文协议 runes protocol | 什么是符文协议Runes
      • 被譽為下一個「銘文」的「符文」是什麼?Runes協定主網上線時間已定?|秒懂符文
  • btc
    • 📖白皮书
      • 中英文
      • 注解版
    • 📖《精通比特币》第二版
      • 原版序言
      • 中文版序言
      • 译者序
      • 第二版更新内容
      • 术语
      • 目录
      • 第一章 介绍
      • 第二章 比特币工作原理
      • 第三章 比特币核心
      • 第四章 密钥和地址
      • 第五章 钱包
      • 第六章 交易
      • 第七章 高级交易和脚本
      • 第八章 比特币网络
      • 第九章 区块链
      • 第十章 挖矿和共识
      • 第十一章 比特币安全
      • 第十二章 区块链应用
      • 附录A-1 比特币白皮书吴忌寒翻译
      • 附录A-2 比特币白皮书李笑来翻译
      • 附录B、交易脚本语言操作符,常量和符号
      • 附录C:比特币改进提案(BIP)
      • 附录D:Bitcore
      • 附录E:pycoin库、实用密钥程序ku和交易程序tx
      • 附录F:Bitcoin Explorer(bx)命令
    • 📖《精通比特币》第三版
    • 🌾精选文章
      • BTC生态扩容方案巡礼(1):铭文何去何从
      • BTC生态扩容方案综述
  • 培训
    • Web3技术培训
  • BTC 生态项目汇总
    • 图文版
  • 比特币 二层
    • Rollup
      • Bitlayer
      • QED Protocol
      • BitVM
      • Bison
      • B² Network
        • B² Network技术实现:基于零知识证明验证承诺的比特币ZK-Rollup
      • Chainway
      • bl2
      • Rollux
      • BOB
      • Hacash.com
      • BeL2
      • LumiBit
        • 详解原生比特币 Layer 2 网络 LumiBit
    • 比特币侧链
      • BEVM
        • BEVM Founder自述:为什么以及如何做BTC Layer2 ?
        • 以BTC为Gas且兼容EVM的BTC Layer2
      • MAP Protocol
      • Merlin Chain
      • Chain-key Bitcoin (ckBTC)
      • SatoshiVM
        • 比特币 L2 新机会?详解 SatoshiVM 及测试网交互流程
      • Rootstock
      • Libre
      • Stacks
      • Liquid Network
      • Babylon
      • BitBolt
      • Drivechain
      • RGB++
        • RGB++:为正统比特币L2添砖加瓦
        • RGB++ Protocol Light Paper
        • 从RGB到RGB++:CKB如何赋能比特币生态资产协议
        • 一文了解提出 RGB++ 协议的比特币二层:CKB
        • RGB++:比特币 L2 资产的新思路
    • 数据可用性
      • Veda
      • Nubit
    • 状态通道
      • OmniBOLT
      • Lightning Network
    • 客户端验证
      • BiHelix
      • RGB
    • 其他
      • Path Protocol
      • Bool Network
      • Dovi
      • Bitfinity Network
      • U Protocol
      • Botanix
        • Botanix protocol
      • AiPTP
  • BTC 基础设施
    • 链下索引
      • UniSat
      • Rooch Network
    • 资产协议
      • Layer1
        • Ordinals序列协议
          • BRC20.com
          • LRC-20/LTC-20
          • ORC-20
            • Ordinals
          • BRC-100
          • SRC-20(STAMPS 协议)
            • SRC20 OpenStamp
          • Runes 协议
          • Pipe 协议
          • Tap Protocol
        • Atomical原子协议
          • ARC-20
            • Atomicals Protocol
      • Layer2
        • BitVM
        • Lightning Network
        • RGB
        • Nostr Assets Protocol
    • 资产桥
      • DLC.Link
      • Liquidium
      • BoringDAO
      • GoWrap
      • XLink
      • MultiBit
      • UniRouter
      • VMPX
      • OrdBridge
      • BRCport
      • SoBit
      • BitSwap
      • SaxBridge
      • Ordinfinity
      • Shell Trade
    • 预言机
      • 概览
        • 预言机赛道大全图谱(经典收藏)
        • OKX Ventures研报:重新思考预言机,看到及未被看到的
      • Chainlink
        • 万字拆解 Chainlink 2.0 构成背景、技术原理、经济模型与未来挑战
        • Chainlink (LINK) 资金面情况及近期发展动态
      • Band Protocol
        • 投资 Band Protocol (BAND) – 您需要了解的一切
      • Pyth Network
        • Pyth Network 研报:Solana 生态预言机发展现状与前景分析
      • Supra
        • Supra万字研究报告: Intralayer中间件,能否撼动Link预言机龙头地位?
  • twitter-space
    • 怎么样的 BTC Layer2 更有机会胜出?
      • 全文
    • BTC Layer2 技术创新盘点
      • 全文
    • 比特币L2混战:从业者 / 市场如何选择?
      • 全文版
      • 精简
  • BTC Layer2 周报
    • BTC Layer2 68个项目盘点
    • 2024.3.11 - 2024.3.17
    • 2024.3.4 - 2024.3.10
    • 2024.2.19 - 2024.2.25
  • BitVM 周报
    • 2024.3.18 - 2024.3.24
    • 2024.3.11 - 2024.3.17
    • 2024.3.4 - 2024.3.10
    • 2024.2.26 - 2024.3.3
  • BTC 2024 会议
    • 比特币复兴 2024:按主题演讲和专题小组分段
由 GitBook 提供支持
在本页
  • 直观来说,Schnorr 签名是如何工作的?
  • Schnorr 签名的定义
  • Schnorr 签名的特性
  • 结论

这有帮助吗?

  1. BitVM
  2. 基础知识

Schnorr 签名:简介

上一页隔离见证的好处下一页谨慎日志合约(DLC):比特币的可扩展智能合约

最后更新于1年前

这有帮助吗?

作者:Nadav Kohen

来源:

中文来源:

img

欢迎阅读 Suredbits 撰写的 Schnorr 签名系列博客!

本文中我会解释 Schnorr 签名是什么、直观上它是如何工作的。到了下一篇文章,我会给出证据,证明这种方案是安全而且正确的。除了这两部分,本系列博客剩下的文章会介绍 Schnorr 签名能够支持的多种签名方案以及它们的应用场景。

在开始阅读之前,建议你先检查一下自己是否熟悉下列几个概念,因为我的讲解预设了读者具备有关它们的一些基础知识:

虽然本系列博客的主旨是一般化地讲解 Schnorr 签名,但本系列的主要动机是 Schnorr 签名即将引入比特币区块链;比特币区块链当前使用着一种名为 ECDSA 的签名算法,我们会经常比较这两者。

Schnorr 签名系列

直观来说,Schnorr 签名是如何工作的?

免责声明:本章节不是安全性证明或相关的具有严格含义的内容,只是尝试讲解有关 Schnorr 签名工作方式的一些直觉。

那么,先假设我们生已经发现,在我们这个世界里,离散对数问题在椭圆曲线上是难解的 —— 即,假设 x 是一个很大的数,而 G 是椭圆曲线上的一个点,仅知道 x * G 我们很难反推出 x。所以,我们可以使用 x * G = X 来作为私钥 x 的公钥。已经明确了我们想利用这一事实来创造一种数字签名方案,但还没开发出来。那我们可以尝试什么思路呢?

我们先想一想,我们的签名方案要实现什么样的目标?我们希望一个数字签名同时承诺了一个人的私钥和被签名的那条消息。我们也希望,签名不会泄露关于签名者私钥的任何信息。最后,我们希望有一种办法,只需使用公开的信息就能验证签名的正确性。

把我们的私钥和消息都看成是编码为数字的数据;我首先想到的将它们结合在一起从而能承诺它们两者的两种办法:加法 (x + m) 和乘法 (x * m)。注意,两种操作最后都会对某个数字 p 求模,因为我们不想让签名的体积很大,而且希望密钥只需是 256 位(二进制位),所以我们在稍小于 2256 的数字中选出一个吉利的作为 p(参见 secp256k1 的 p 值定义)。这两种结合的办法当然满足我们想要的第一种属性(承诺),但都不满足我们想要的第二种属性,因为无论是加法后模 p 还是乘法后模 p,都是可以反推的,这样就会泄露我们的私钥!不过,也许我们仍然可以通过添加一个额外的混淆步骤来保存这两种方法之一,那么,给定加法 (x + m) 或乘法 (x * m),我们能做什么 “调整” 来隐藏我们的私钥呢?我们可以生成一个完全随机的数 k,使之与我们的 x 和 m 相结合。现在,到底该用哪种方法,就变成了一个可以用试错来解决的问题了,因为不论如何它都能提供可靠的计算方法来满足我们想要的前两种属性,但不是所有的结合方法都能让签名可以验证。

在尝试了这三个数字的多种加法乘法苏荷之后,我们选中了 s = k + m * x,它既使用 m * x 承诺了消息和密钥,又使用随机的密钥 k 隐藏起了这些信息。这种结合方式与其它方式相比,最大的区别在于:只要把这个数字转化为(椭圆曲线上的)一个点,我们就得到了一种很棒的结构,只需使用公钥就可以验证签名:给定椭圆曲线上的一个标准点 G 用于生成公钥(需要所有参与者都知晓;见 secp256k1 曲线的 G 值定义);我们可以用 G 乘上我们的签名,得到:

这里 R = k * G 就是 k 的公钥,而 X = x * G 是 x 的公钥。所以只需要公开的信息就能验证我们的签名(假设 R 已经公开)!

我们要做的最后一个事情是优化,使用 H(m) (就是 m 的哈希值)来替代 m,因为 m(要签名的消息)可能非常大。这个替换式可以接受的,因为 H(m) 仍然承诺了 m,所以我们的签名也是(承诺了 m)。

因此,我们现在的签名方案,在给定私钥 x 和消息 m 时,是生成一个随机数 k,并公开 s = k + H(m) * x 和 R = k * G。验证者可以通过检查 s * G = R + H(m) * X 是否成立来验证签名的有效性(如前所述,s 和 R 是签名的内容,而 m 是被签名的消息,X 是签名者的公钥)。

至此,我觉得我们已经没有问题了,但在我们尝试正式分析和证明这个方案的安全性之前,我们先来尝试攻击它。我想到的第一种攻击是伪造攻击:不知道这个私钥的人,想伪造这个私钥的签名。作为这种类型的攻击者,我们知道 X(x 的公钥)和 m(待签名的消息),尝试生成一个能够通过验证的有效签名。换句话来说,仅知 X 和 m,我们想搞出一组(R, s)来通过签名验证。回想我们的验证等式 s * G = R + H(m) * X,我们知道它等价于:R = s * G – H(m) * X(这是通过在等式两边都减去 H(m) * X 得到的)。但是,且慢,我们已经知道了 H(m) * X ,那只需要选出 s(就能凑出这个等式来了) —— 那么,我们只需选出一个随机数作为 s,再根据算式 s*G – H(m) * X 的结果来设定 R,就成了。也就是说,我们可以生成任意的 s 值,然后根据这个值来计算 R 值;只用到了公开的信息,就可以任意创建有效的数字签名 …… 大事不妙啊。

跟前面一样,我们发现,这个方案还是可以挽救的,我们只需要调整一些东西来打破这种攻击。从目前来看,要说显然可以哪种办法会有点牵强,但我们会在证明 Schnorr 签名安全性的讨论(下一篇文章)中介绍它的真正起源,也许能让下一个选择理解起来更加自然。

可以尝试的其中一种思路是使得 s 依赖于 R,从而打破等式 R = s * G – H(m) * X。办法之一是在我们哈希那条消息时使用 R,也就是让 s = k + H(R, m) * x,此处的 H(R, m) 就是拿 R 作为消息 m 的前缀,一起去做哈希计算(有时候会写成 H(R||m),这里的 || 表示拼接)。这就打破了我们的伪造攻击,因为现在,给定一个随机的 s,找出一个 R 使得 R = s * G – H(R, m) * X 成立是很难的,因为 R 也参与了哈希值的生成,除了暴力破解之外,没有更好的办法来找出合适的 R。

我想重申,这不是 Schnorr 签名实际上的安全形态,因为仍有其它方式可以伪造签名。但它确实看起来能应对明显的攻击,可以证明是安全的。我们成功地 “发明” 了 Schnorr 签名!

Schnorr 签名的定义

如果你有一个公私钥对 (x, X = x * G),那么该私钥对一条消息 m 的 Schnorr 签名是一对数值 (R, s),其中 k 是一个随机的密钥:

分析一下,对每一个签名,签名者都生成一个随机的数值作为 k 的值,k 本质上就是这个签名的一次性私钥。签名者计算出 R,也就是 k 的公钥,一般我们称之为 nonce。接下来,我们取 R 和 m 一起的哈希值。这个哈希值才是实际上被签名的东西:被哈希的对象包括消息和一个公开的数值,所以这个哈希值是对这条消息和 R 的承诺。后面我们会看到,我们需要对 R 的承诺来保证这种签名方案是安全的。最后,签名者使用私钥与这个哈希值执行乘法(模 p)运算;得出的结果再与一次性私钥 k 做加法(模 p)运算,得出的结果就是 s。R 与 s 一道构成了签名的内容,这个签名本质上就是证明,知道 x 的某人签名了消息 m,而 R 是一次性公钥,与普通的公钥 X 一样都是验证这个签名所需的数据。在比特币中,签名 (R, s) 会被编码成 64 个字节,前面 32 个字节表示 R, 后面 32 个字节表示 s。

这只是故事的一半:签名的生成。签名生成之后,任何知道消息 m 和公钥 X 的人都应该能够验证这个签名。签名的验证就是检查下列等式是否成立:

你可以看出, m 和 X 必须是验证者已知的,而 R 和 s 就是签名。

这些就是围绕 “山寨” Schnorr 签名的全部计算了!生成一个签名要用到一个(一次性)的私钥、一次哈希计算、一次乘法和一次加法。而验证签名只需要得到一个哈希值,运用两次点乘法和一次点加法。有了这些知识,你现在应该能够自己阅读和理解 BIP-340 的主要内容了:它基本上就是我在这里讲述的方案的更详细的版本,它会更关心这些数据是如何编码的、 k 值是如何生成的,等等。

虽然多了解一些 Schnorr 签名以便实现它们是很棒的事,但我们还想挖得更深一些!Schnorr 签名有一些什么样的特点呢?它跟(比特币现在使用的)ECDSA 签名相比如何?在它们的工作原理背后,有一些什么样的直觉?我们怎么知道它们是安全的?甚至于,对这些东西来说,“安全性” 到底意味着什么?我们一个一个来回答这些问题。

Schnorr 签名的特性

首先,我们来列举一下大部分签名方案都有的一些共同特点。

Schnorr 签名看起来就像随机数。具体来说,k 合 x 都是随机数,而 H(R, m) 应该也是个随机数,因为它是哈希函数的一个输出;不严格地来说,把一堆随机数组合在一起也会给我么一个随机数。这里的意思,无论被签名的消息实际是什么样的、签名者是谁,(这些因素都不会使签名的值产生明显的偏差),s 看起来都差不多。注意,这只是一个说法,并不能证明 Schnorr 签名不会泄露有关签名者私钥的任何信息。不过,我们后面详解其安全性时,还会讲到这个属性。

Nonce 绝对不可以重复使用!我把密钥对 (k, R) 称为一次性密钥是有理由的:如果你在签名两条不同的消息时用上了同一个 (k, R) 密钥对,你就会完全泄露你的私钥。我们来看看你要是犯了这个错误,攻击者可以如何获得你的私钥:攻击者一开始获得了 X(你的公钥),R(被重用的 nonce 值),m1 (第一条消息),s1(第一个签名),m2 (第二条消息),s1(第二个签名);回想一下,s 值是对某条消息和私钥 x 的承诺,但经过了随机数 k 的调整。因此,如果攻击者把两个 s 值相减,那用来隐藏私钥 x 的随机数调整,就完全没有效果了(因为 nonce 重用意味着两个调整的效果是相同的)!攻击者可以依次计算:

s_1 – s_2 = (k + H(R, m_1) * x) – (k + H(R, m_2) * x) (根据定义)
        = H(R, m_1) * x – H(R, m_2) * x             (因为 k - k)
        = (H(R, m_1) – H(R, m_2)) * x             (有相同乘数)

让我所说,k 的调整(隐藏)效果没有了之后,两个签名的差值就只剩下了 H(...)*x,也就是两个哈希值的差值乘以 x。最后,因为这两个哈希值都是已知的(它们是公开信息的哈希值),所以我们可以利用这个等式:

这个式子中只有 x 是不公开的了。攻击者可以根据下面的式子解出 x:

任何人只要看到了你重用了一个 nonce ,就知道了你的私钥,可以拿走你所有的比特币!BIP 340 试图通过在生成 k 时使用消息作为密钥生成函数的其中一个输入,来保证 nonce 不会被重用:如果消息改变了,那 nonce 也会跟着改变。

这两种属性对 ECDSA 和许多其它类型的签名协议也是一样的,实际上我们会看到,这两种属性实际上也是 Schnorr 签名安全性的一部分。现在,我们来看看 ECDSA 与 Schnorr 的两个最主要的区别,这些区别使得 Schnorr 更为独特和优秀。

Schnorr 签名体积比 ECDSA 更小,计算和验证起来更快。在比特币现在使用的 ECDSA 签名方案中,一个签名(DER 编码)是 70 或 71 字节长;而 Schnorr 签名的长度是 64 字节。此外,计算和验证 Schnorr 签名都比 ECDSA 签名快得多。

Schnorr 签名是线性的。这是 Schnorr 与众不同的关键之处,使之能支持我们将在这系列博客中介绍的大部分方案。线性是签名函数的属性(签名函数以密钥和一条消息作为输入,输出签名),也就是说:

这个等式的意思是,如果有两方签名同一条消息,并将他们的签名加起来,就可以得到他们的聚合密钥的一条有效签名!使之成真需要一个略微改动过的 Schnorr 签名版本:令总 nonce 值 R = R1 + R2 (也就是每一个 nonce 值的和),并在生成消息哈希值时使用 R(而非参与方各自的 nonce 值),由此可得:

    SchnorrSign(x_1, k_1, m) + SchnorrSign(x_2, k_2, m)
= (k_1 + H(R, m) * x_1) + (k_2 + H(R, m) * x_2)
= (k_1 + k_2) + H(R, m) * (x_1 + x_2)
= SchnorrSign(x_1 + x_2, k_1 + k_2, m)

换句话说,因为我们把签名方案修改成使用同一条哈希值,加总两个签名的结果相当于把两个随机数相加以及把两个私钥相加,这就给了我们一个很棒的线性签名函数。

而 ECDSA 并没有同样的属性。我们会在本系列博客的后续篇章中探究这种线性属性的用场。

最后,如 BIP 340 所说,“在取得所有这些好处时,它几乎没有缺点”。Schnorr 是最简单的基于椭圆曲线的签名方案,而比特币只会从中获益,别无所失。

结论

本文中我们定义了 Schnorr 签名,讨论了它的一些属性,拿它跟 ECDSA 作了比较,甚至还搞出了一段我们凭直觉为自己发明了(大部分)Schnorr 签名的 “假历史”。此外,我还偷偷塞进了我们将用来证明 Schnorr 是一种安全签名方案的许多线索:nonce 重用会泄露私钥、我们的幼稚方案 k + H(m) * x 无法抵御伪造攻击。我们会使用这些事实和其它的一些事实来证明 Schnorr 是安全的,就在下一篇文章;然后我们会讨论如何利用 Schnorr 和它的线性属性做出许多很酷的事情,敬请期待!

(完)

—— 也就是只关心余数的数学(译者注:对正数来说,“模 n” 或 “对 n 求模” 即求除以 n 的余数,故求模运算的结果必定小于 n)

—— 密码学领域的这部分

—— 只需 阅读/略读 至 “How to prove you know x” 部分即可,因为后续的部分在本文中都有讲解

What are Schnorr Signatures – Introduction

𝑠∗𝐺=(𝑘+𝑚∗𝑥)∗𝐺=𝑘∗𝐺+(𝑚∗𝑥)∗𝐺𝑠∗𝐺=(𝑘+𝑚∗𝑥)∗𝐺=𝑘∗𝐺+(𝑚∗𝑥)∗𝐺s∗G=(k+m∗x)∗G=k∗G+(m∗x)∗G

𝑅=𝑘∗𝐺𝑅=𝑘∗𝐺R=k∗G

𝑠=𝑘+𝐻(𝑅,𝑚)∗𝑥𝑠=𝑘+𝐻(𝑅,𝑚)∗𝑥s=k+H(R,m)∗x

𝑠∗𝐺=?𝑅+𝐻(𝑅,𝑚)∗𝑋𝑠∗𝐺=?𝑅+𝐻(𝑅,𝑚)∗𝑋s∗G=?R+H(R,m)∗X

𝑠1–𝑠2=(𝐻(𝑅,𝑚1)–𝐻(𝑅,𝑚2))∗𝑥𝑠1–𝑠2=(𝐻(𝑅,𝑚1)–𝐻(𝑅,𝑚2))∗𝑥s1–s2=(H(R,m1)–H(R,m2))∗x

𝑥=(𝑠1–𝑠2)𝐻(𝑅,𝑚1)–𝐻(𝑅,𝑚2)𝑥=(𝑠1–𝑠2)𝐻(𝑅,𝑚1)–𝐻(𝑅,𝑚2)x=(s1–s2)H(R,m1)–H(R,m2)

𝑆𝑖𝑔𝑛(𝑥1,𝑘1,𝑚)+𝑆𝑖𝑔𝑛(𝑥2,𝑘2,𝑚)=𝑆𝑖𝑔𝑛(𝑥1+𝑥2,𝑘1+𝑘2,𝑚)𝑆𝑖𝑔𝑛(𝑥1,𝑘1,𝑚)+𝑆𝑖𝑔𝑛(𝑥2,𝑘2,𝑚)=𝑆𝑖𝑔𝑛(𝑥1+𝑥2,𝑘1+𝑘2,𝑚)Sign(x1,k1,m)+Sign(x2,k2,m)=Sign(x1+x2,k1+k2,m)

🌾
求模运算
哈希函数
公钥和椭圆曲线
Schnorr Signature Security: Part 1 – Schnorr ID Protocol
Schnorr Signature Security: Part 2 – From IDs to Signatures
Schnorr Multi-Signatures – MuSig
Scriptless Scripts – Adaptor Signatures
Batch Verification
Schnorr Threshold Sigantures
Flexible Round-Optimized Schnorr Threshold – FROST
Schnorr Blind Signatures
Taproot Upgrade – Activating Schnorr
https://suredbits.com/introduction-to-schnorr-signatures/
https://www.btcstudy.org/2021/11/20/introduction-to-schnorr-signatures-by-suredbits/#Schnorr-%E7%AD%BE%E5%90%8D%E7%9A%84%E7%89%B9%E6%80%A7