Skip to content
This repository has been archived by the owner on Aug 1, 2020. It is now read-only.

Latest commit

 

History

History
597 lines (466 loc) · 41.4 KB

readme.md

File metadata and controls

597 lines (466 loc) · 41.4 KB

Bitcoin

  • 比特币结合 4 个创新
    • 去中心化的对等网络（比特币协议）
    • 公共交易总帐（区块链）
    • 独立交易确认和货币发行的一套规则（共识规则）
    • 实现有效的区块链全球去中心化共识的机制（工作量证明算法）
  • 比特币单位
    • bitcoin，BTC，1比特币
    • centi-bitcoin，cBTC，1分比特币，百分之一比特币（之前最常用）
    • milli-bitcoin，mBTC，1毫比特币，千分之一比特币（偶尔用）
    • micro-bitcoin，μBTC，1微比特币，1^(-6)比特币（最常用）
    • satoshi，sat，1聪比特币，一亿分之一比特币（最小单位）
  • 每4年发行新比特币的比例降低一半
  • 2140年将达到2100w

一些历史

  • 非对称加密
    • 1976: RSA
    • 1985： ECC 椭圆曲线函数加密
  • P2P
    • 1969: 首次提出
    • 1999: Shawn Fanning 创造全球第一个走红的P2P共享平台 Napster
  • PoW
    • 1997: Adam Back 发明 HashCash 哈希现金
      • 最初创造 HashCash 的目的是对抗 DoS
    • 2004: Hal Finney 创造出了第一个可重复使用的工作量证明系统 Reusable proof of work system
      • 比特币史上的第一笔交易就是发生在中本聪与哈尔芬尼之间，是第一位得到比特币的人。
  • Bitcoin
    • 2008, Satoshi Nakamoto,“Bitcoin：A Peer-to-Peer Electronic Cash System”
    • 2009, 比特币网络运行
      • 北京时间2009年1月4日02:15:05 Genesis block 创世区块
        • 《泰晤士报》当天头版文章标题
        The Times 03/Jan/2009 Chancellor on brink of second bailout for banks

nodes

Network status

设计思想

  • 为什么 block 设计为 1M？
    • 在比特币诞生之初，比特币的发明者中本聪并没有特意限制区块的大小，区块大小在其自身数据结构的控制下最大可以达到 32MB
    • 在比特币早期，有人恶意制造的大量小额转账使网络中有大量的待确认交易，导致正常的比特币转账不能被确认，确认时间被延迟，影响网络正常运转(DDoS)。于是中本聪将比特币的区块大小暂定为1M
    • 在比特币白皮书的第7章，中本聪就明确提出了在比特币容量不够用的时候应该怎样进行扩容。白皮书发布之后，他自己在社区留言的第一个问题，就指出了比特币未来的扩容隐患。
    • 比特币扩容之争
  • 比特币采用SHA-256、RIPEMD-160哈希算法生成密钥，使用SHA-256作nonce碰撞以挖矿。
  • 为什么总体供给是 2100w？
  • 为什么 10 分钟出一个区块？为什么 6 个区块之后就可以认为之前生成的区块被确认了？
  • 为什么交易需要6次确认，coinbase 却需要 100 次才能成熟？
  • 为什么用 base58？为什么不用我们熟知的 base64？
  • 为什么交易速度如此之慢，只有若干 tx / s？
  • 为什么 PoW？现有的方法为什么不可用？（呃，现有有什么方法？）
  • 为什么给矿工生成看似无意义的空区块的空间？
  • 为什么钱包的地址要 hash 一遍，而不是直接用 public key 的 base58?
  • 为什么需要 merkle tree？
  • 为什么用 ECDSA 而不是 RSA？
  • 为什么 double hash？
    • 长度不够可能多0导致碰撞
  • 为什么tx&block hashes用 little endian，而不是 big endian（network order）？
    • 比特币的区块链要靠HASH值来标识区块，这就要求所有系统（不管是什么架构），存储的数据必须每个字节（包括顺序）都完全一致，因此必须规定出一种统一的字节顺序才行。哪一种都可以，但必须选一个。现代计算机 几乎都是使用little endian ，所以内置的数据类型首选little endian。
      • Bitcoin transaction and block hashes are considered little-endian when treating them as integers.
    • Hashes are defined by the standards as being big-endian, and crypto libraries deal with them in that form, so hashes are transmitted in big-endian.
      • On the network they are just 32-byte sequences in the order they are generated by the hash function.
      • blocks show up in big-endian form, and itz the way we humans write numbers down.
      • block hashes in Bitcoin are treated as numbers for the purposes of difficulty calculations, meaning the hash must be below certain threshold in order to pass. It is natural for a human to expect such a number to be displayed on screen with leading zeroes.

图灵完备

图灵完备指的是可以描述一系列操作来描述所有可计算问题。

比特币不是图灵完备的，因为它没有条件判断语句，不能执行循环，也不会产生递归。

P2P

fast sync

Gregory Maxwell, who implemented the assumed valid feature, 跳过 the assumed valid block 之前的 script evaluation，可以使新用户减少 80% 的同步时间。用户仍然要计算 utxo 集来验证币的所有权。

James O’Beirne 在 Bitcoin-Dev mailing list 发了个 帖子 讨论要不要连区块链信息包括 uxto 集也直接下载了。好处是 可以把同步时间减少 95% 甚至更多，坏处是随着区块越来越大，新用户没法 trustlessly verify Bitcoin’s UTXO state，只能信任已有用户。

Verification

比特币节点如何验证一个区块 (适用于 BTC/BCH-ABC/BCH-SV)

当一个节点通过p2p网络获得一个新区块时，都会验证这个区块是不是有效 (CheckBlock 函数) :

  • 验证工作量证明，即验证区块头的哈希值小于当前目标值。
  • 验证 Merkle Root 是否是由区块体中的交易得到
    • 重构区块 Merkle 树得到的树根，看是否和区块头中的 hashMerkleRoot 值相等
  • 验证区块大小是否在设定范围之内
    • BTC 数据区块体不能大于 1M，隔离验证区块不能大于 3M
    • BCH-ABC 区块不能大于 32M
    • BCH-SV 现在是不能大于 128M
  • 验证是否只有一个 Coinbase 交易(一个区块，矿工只能给自己奖励一次)
  • 验证所有的交易，即遍历区块内所有的交易，检查是否是合法的交易。

Transaction

  • 比特币有哪几种交易类型？
    • Generation（挖矿）
      • While regular transactions use the 'inputs' section to refer to their parent transaction outputs, a generation transaction has no parent, and creates new coins from nothing.
    • Pay to Pubkey Hash
    • Pay to Script Hash

UXTO

  • 为什么设计 UTXO？

Script

地址

  • see https://en.bitcoin.it/wiki/Address
    • Address_map.jpg
  • 比特币地址 version 1 (P2PKH)的生成过程是？
    • PubKeyToAddr
      • 第一步，随机选取一个 32 字节的数、大小介于 1 ~ 0xFFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE BAAE DCE6 AF48 A03B BFD2 5E8C D036 4141 之间，作为私钥。
      • 第二步，使用椭圆曲线加密算法（ECDSA-secp256k1）计算私钥所对应的非压缩公钥。
      • 第三步，计算公钥的 SHA-256 哈希值。
      • 第四步，取上一步结果，计算 RIPEMD-160 哈希值。
      • 第五步，取上一步结果，前面加入地址版本号。
      • 第六步，取上一步结果，计算 SHA-256 哈希值。
      • 第七步，取上一步结果，再计算一下 SHA-256 哈希值。
      • 第八步，取上一步结果的前 4 个字节。
      • 第九步，把这 4 个字节加在第五步的结果后面，作为校验。
      • 第十步，用 base58 表示法变换一下地址。
  • bech32
  • Bech32_address --> scriptPubKey in python 
    >>> import segwit_addr
>>> HRP='bc'
>>> good_address='bc1qd6h6vp99qwstk3z668md42q0zc44vpwkk824zh'
>>> typo_address='bc1qd6h6vp99qwstk3z669md42q0zc44vpwkk824zh'
>>> wrong_network_address='tb1q3wrc5yq9c300jxlfeg7ae76tk9gsx044ucyg7a'
>>> segwit_addr.decode(HRP, good_address)
(0, [110, 175, 166, 4, 165, 3, 160, 187, 68, 90, 209, 246, 218, 168, 15, 22, 43, 86, 5, 214])

>>> segwit_addr.decode(HRP, typo_address)
(None, None)

>>> segwit_addr.decode(HRP, wrong_network_address)
(None, None)

>>> witver, witprog = segwit_addr.decode(HRP, good_address)
>>> bytes([witver + 0x50 if witver else 0, len(witprog)] + witprog).hex()
'00146eafa604a503a0bb445ad1f6daa80f162b5605d6'
    • Bech32 addresses have a Human-Readable Part (HRP) that indicates what network the address is for.
      • 数字 1 隔断 HRP 与地址的数据部分
      • HRP bc: mainnet
      • HRP tb: testnet
  • Sending to a P2PKH address vs Sending to a equivalent bech32 P2WPKH address
    • P2PKH
      • for 1B6FkNg199ZbPJWG5zjEiDekrCc2P7MVyC, base58check library will decode that to a 20-byte commitment: 
        6eafa604a503a0bb445ad1f6daa80f162b5605d6
      • This commitment is inserted into a scriptPubKey template: 
        OP_DUP OP_HASH160 OP_PUSH20 6eafa604a503a0bb445ad1f6daa80f162b5605d6 OP_EQUALVERIFY OP_CHECKSIG
      • Converting the opcodes to hex, this looks like: 
        76a9146eafa604a503a0bb445ad1f6daa80f162b5605d688ac
      • This is inserted into the scriptPubKey part of an output that also includes the length of the script (25 bytes) and the amount being paid: 
             amount                           scriptPubKey
|--------------|  |------------------------------------------------|
00e1f505000000001976a9146eafa604a503a0bb445ad1f6daa80f162b5605d688ac
                |
    size: 0x19 -> 25 bytes
  • scriptpubkey vs scriptsigs
    • 在两笔交易中, 按顺序组合并执行, 分别锁定和解锁
    • scriptpubkey 的原因是 地址只不过是公钥的哈希值, 发送方不知道接收方的公钥
    • LockingUnlocking

getaddressinfo

An current example of the descriptor format with key origin information and an error-detecting checksum:

$ bitcoin-cli getaddressinfo bc1qsksdpqqmsyk9654puz259y0r84afzkyqdfspvc | jq .desc
"wpkh([f6bb4c63/0'/0'/21']034ed70f273611a3f21b205c9151836d6fa9051f74f6e6bbff67238c9ebc7d04f6)#mtdep7g7"
  • The address is a Witness Public Key Hash wpkh(), otherwise known as P2WPKH. Descriptors can succinctly describe all common uses of P2PKH, P2SH, P2WPKH, P2WSH, and nested segwit.
  • The key origin is described between the square brackets [].
    • f6bb4c63 is a fingerprint that identifies the key at the root of the path provided. The fingerprint is the first 32 bits of its ripemd(sha256()) hash as defined by BIP32. This makes it easy for tools, such as those used with PSBTs, to work with multisig scripts and other cases where you have multiple signing devices using different keys.
    • /0'/0'/21' is the HD key path, corresponding to m/0'/0'/21' in standard BIP32 notation. This allows a wallet that doesn’t have all of its public keys precomputed to know which private key it needs to generate in order to produce the signature. (Bitcoin Core precomputes its public keys and so usually doesn’t need this information when used as a cold wallet—but hardware wallets with minimal storage and computational speed need HD path information in order to work efficiently.)
  • The actual public key used to generate the P2WPKH key hash is 034ed7...04f6
  • A checksum following a # protects the descriptor string against typos on import, mtdep7g7

mul-sig 多重签名

多重签名用于比如 公司董事会发起转账，对于一个 m-n 地址来说，参与创建者共有 n 人，发出的交易只要有 m 人正确签名就视为有效

比特币中地址其实就是解锁脚本, 多签地址也对应了一个多签脚本，与签名参与者的顺序有关(与参与者的pubkey以及顺序有关)

创建多签脚本:(并不是所有的链都是这个顺序，具体还是看 相应 opcode 在虚拟机中的执行)

m {pubkey1}...{pubkeyn} n OP_CHECKMULTISIG

比如

OP_2 [A's pubkey] [B's pubkey] [C's pubkey] OP_3 OP_CHECKMULTISIG

解锁时:

OP_0 ...signatures...

(OP_0 is required because of a bug in OP_CHECKMULTISIG, a workaround for an off-by-one error in the original implementation; it pops one too many items off the execution stack, so a dummy value must be placed on the stack).

比如

OP_0 [A's signature] [B's or C's signature] [serialized redeem script]

注意: 签名顺序要和多签脚本中pubkey的顺序相同, 验签时会检查签名数量有否满足，然后虚拟机 逐个 按顺序 Verify(pubkey, msg, sig)

Segregated Witness (SegWit) 隔离见证

  1. 把脚本签名(scriptSig)信息从基本结构 (base block) 里拿出来，放在一个新的数据结构当中。做验证工作的节点和矿工也会验证这个新的数据结构里的脚本签名，以确保交易是有效的。

segwit

当审核统计区块大小的时候。脚本签名大小不会被计算在内。

对于 某些交易 ，签名散列增长是平方增长的, 而不是线性增长的。Segwit 通过改变交易哈希签名的计算方式可以解决此问题，使得交易的每个字节只需要至多两次哈希。

为什么不直接用大区块？

其实这两个扩容方法都是可以采取，但是有一个先后问题。先后次序会很大程度影响到比特币的整个网络。那么为什么技术上要先上隔离见证，简单说来直接增大区块容量让下载全节点不适合于普通PC电脑，网络中越少的全节点其实不利于比特币安全。

2.1. 防止了延展性攻击（malleability）。TxID 的计算方法使得任何人可以对交易做微小的改动，不会改变交易的内容，但是会改变TxID，这就是所谓的第三方延展性。之前那个原始交易记录会被认为是无效的交易而失败。不会造成双花，也不会对区块链造成破坏，但是对原始交易记录的发起者会造成困扰，因为如果拿着原始交易记录的哈希值找不到交易的成功记录。尤其是对于一些交易所，如果没有完整的内部日志，可能无法追溯交易记录，导致攻击者利用拼凑的交易记录先成功提币，再申诉说没有提到币，要求再次提币。

2.2 更好的实现 闪电网络 ：闪电网络的具体实现需要创建一系列相互依赖的父子交易记录，需要先对子交易记录签名，然后将子交易记录交换后，再对父交易记录签名并广播。所以，有了隔离见证后，才能更完美的支持闪电网络。

2.3 花费未确认的交易： 如果 Alice 在交易1支付 Bob一些币，Bob 在交易2 使用收到的付款支付给Charlie，然后Alice的付款发生延展性修改,并用不同的txid确认， 那么交易2现在是无效的，而Charlie就不会被支付。如果Bob是值得信赖的，他会重新发出一笔交易给查理；但如果他不是，他可以简单地把这些比特币留给自己。

节省费用

bech32 发送支持允许付款的接收者在重新花费时节省费用。

对于在第一版比特币中实现的传统 P2PKH 地址格式，授权花费的 scriptSig 通常为 107 vbytes。 对于 P2SH 封装的 segwit P2WPKH，这个信息被移动到 witness 见证数据字段，该字段仅消耗 1/4 的 vbytes（27 vbytes），但其 P2SH 开销增加 23 vbytes，总共 50 vbytes。 对于原生 segwit P2WPKH，没有 P2SH 开销，所以共使用 27 个 vbytes。

这意味着，P2SH-P2WPKH 比 P2PKH 节省了 50% 以上的空间，而 P2WPKH 又比 P2SH-P2WPKH 节省了近 50%，或直接比 P2PKH 节省了75%。但是，支出交易不仅包含 scriptSigs 和见证数据，因此我们通常比较节省了多少空间的方式是通过看原型交易。 例如，我们想象一个典型的事务包含一个输入和两个输出（一个到接收者;一个作为找零回到消费者）。 在这种情况下：

  • 支出 P2PKH 的总交易大小为 220 vbytes
  • 支出 P2SH-P2WPKH 的大小为 167 vbytes（节省24％）
  • 支出 P2WPKH 输出的大小为 141 vbytes（与 P2SH-P2WPKH 相比节省16％，与 P2PKH 相比节省35％）

在比较简单的 multisig 交易（那些只使用单个 OP_CHECKMULTSIG 操作码的事务）时会变得复杂，因为 k-of-n multisig 输入的大小取决于签名的数量（k）和公钥的数量（n）。 因此，为了简单起见，我们将仅绘制传统 P2SH-multisig 与封装的 P2SH-P2WSH multisig 大小对比（上到传统 P2SH 支持的15-of-15）。 我们可以看到，切换到 P2SH-P2WSH 可以节省大约 40％（1-of-2 multisig）到大约 70％（15-of-15）。

segwit-multisig-size-p2sh-to-p2sh-p2wsh

然后，我们可以将 P2SH-P2WSH 与原生 P2WSH 进行比较，可以看到每个交易节省约 35 个字节的额外恒定大小，即约 5％ 到 15％。

segwit-multisig-size-p2sh-p2wsh-to-p2wsh.png

上面描述的脚本占了几乎所有与非原生 segwit 地址一起使用的脚本。（更复杂脚本的用户，例如在 LN 中使用的脚本，现在大多使用原生 segwit。）那些效率较低的脚本类型目前占用区块容量的大部分（总区块权重）。切换到原生 segwit 以减少交易的权重可以将费用减少相同的百分比，而无需改变确认所需的时间 - 其他什么都不用改。

但也不是什么改变也没有。由于交易使用较少的块权重，因此可用于其他交易的权重更多。如果可用区块权重的供应增加且需求量保持不变，手续费应该会下降（除非它们已经是默认的最低转发费用）。这意味着更多的人花费原生 segwit 输入不仅降低了那些花费者的费用，而且降低了每个创建交易的人的费用 - 包括支持发送到 bech32 地址的钱包和服务。

别的一些好处:

Lightning Network

浏览器:

Readings:

微支付通道 -> 双向支付通道 -> 闪电网络

比特币白皮书 发表于 2009 年，闪电网络白皮书 发表于 2016 年。闪电网络起源于比特币的扩容问题。闪电网络是基于微支付通道演进而来，创造性的设计出了两种类型的交易合约：序列到期可撤销合约 RSMC（Revocable Sequence Maturity Contract，哈希时间锁定合约 HTLC（Hashed Timelock Contract）。RSMC 用来完成两个节点之间的交易确认，解决了通道中币单向流动问题，HTLC ，用来将多个节点连接成一个网络，解决了币跨节点传递的问题。这两个类型的交易组合构成了闪电网络。

优点

  • 小微支付成为可能
    • 交易金额低至一聪
  • 小额甚至无需手续费
  • 付款实时结算
  • 更好的隐私性：并非每笔交易都会被存在链上
    • 默认使用洋葱路由器进行分享
      • Oninion Routing (with the help of the SPHINX paper) in BOLT 04 is that you as the payer of a network hide who is receiving the money. Also you hide that you are the sender (though every node can send back error messages to you).
        • If you pay a person with these oninion payments and this person is NOT using TOR for their lightning node you will know who the payee is (at least you know the IP address and to some degree where the computer stands) Others on the way do not know this (only the channel partner knows that the payee is involved in the payment process but it is not clear that it is the receipient to the channel partner).
    • 可以配置 tor 代理
      • Tor network is to hide your IP address
  • Securely cross blockchains: payments can be routed across more than one blockchain (including altcoins and sidechains) as long as all the chains support the same hash function to use for the hash lock, as well as the ability the ability to create time locks.
    • 实现原子交换，在通道内能将比特币交换为 Litecoin，Groestl 或 Dogecoin
  • 由于 P2P 网络的特性，所以闪电网络上的交易是不可阻止的。

缺点

  • 节点故障：如果其中一个节点没有响应，用户可能需要等待数小时才能关闭支付通道并再次通过另一条路径重新发送资金
  • 不可离线支付：用户无法向不在线的人进行支付
  • 不适用于大额支付：即使通过不同支付通道的路径可能存在，不同节点的多重签名钱包中的资金也可能不足以转移大额资金
  • 可能会造成支付中继站的中心化
    • 解决办法是多建闪电网络节点
  • 可能存在的攻击
    • 女巫攻击把中继站的资金池掳走，耗时很久才返还

rebalancing

TODO

ECDSA Failures

Colored Coin

比特币分叉

规则改变时, 网络中新旧节点遵守的规则不同

硬分叉

旧节点不接受新节点产生的区块，导致网络分裂为新链和旧链

软分叉

旧节点接受新节点产生的区块（虽然可能潜在风险）

比特币扩容之争

BCH vs BTC

扩大区块 VS 闪电网络

扩大区块
  • 主要支持者:矿工(比特大陆...)
    • 不过，大区块派并不都反对闪电网络，他们中的一部分并不抵触部署闪电网络，但是坚持在建设闪电网络的同时仍然需要扩大区块。
  • 理由:
    • 闪电网络做的隔离见证对原有比特币系统有 巨大改动 ,万一失败
    • 闪电网络毕竟 不是比特币区块链 ，闪电网络可能会被 中心化的机构 控制，导致比特币的中心化。
  • 利益:
    • 希望赚交易费用，而闪电网络把大量小额交易都隔离开了
闪电网络

see Lightning Network

  • 主要支持者:Bitcoin Core
  • 建立在 隔离见证 的基础上
  • 理由:
    • 扩大区块需要进行 硬分叉 ，万一有的用户不升级钱包，就会产生对比特币的分裂，造成混乱；
    • 如果区块变大，以后交易越来越多，普通人的电脑上根本就运行不起这么 大的全节点钱包 ，只有机构的电脑可以运行，就会导致比特币的中心化。
  • 利益:
    • Core团队中的好几名成员都在研发闪电网络的公司Block Stream工作,推广闪电网络可以赚取专利费

香港共识

各退一步 部署隔离见证的同时把区块大小扩大到2M，由Core来主导开发。

纽约共识

Core的几个开发者在共识上签完字后，团队里的其他成员却不认同这个共识，不愿意开发，于是香港共识后来连代码都没写，就这样跳票. 矿主对Core失去了信任, 纽约重新召开一个无core团队参与的大会

纽约共识达成的协议跟香港共识很像，也是隔离见证+2M扩容，SegWit2x。区别是纽约共识中，隔离见证和扩容分成了两步进行：

  • 2017年8月1日 激活隔离见证（SegWit）
  • 2017年11月，区块大小扩容到原来的两倍（2x）。

BCC分叉

Core一看被排挤, 在纽约共识约定的隔离见证部署前，提出UASF（用户激活的软分叉），并声称不会对UASF进行任何的 重放保护 。

但UASF最终因算力小且被 SegWit 兼容，没有真产生分叉，反推动比特大陆投资的矿池 ViaBTC（微比特）团队实施了针对 UASF 的硬分叉 UAHF（用户激活的硬分叉）。

  • 8月1日，ViaBTC 挖出了第一个区块，对比特币区块链进行了硬分叉
  • 产生了比特币的克隆竞争币 比特现金（Bitcoin Cash，BCC，国外又称BCH）
    • 比特币现金的区块大小可以上升到8M
    • 可容纳交易笔数是原来比特币8倍左右
    • 去掉了隔离见证
    • 区块容量大，交易速度的确更快，手续费更低
    • 克隆了比特币原链上的余额, 原比特币用户获得等额比特现金

BCH-ABC vs BCH-SV

BCH-ABC

更偏向智能合约, 利用二层网络方案

  • 短出块时间到2分钟，同时区块奖励也相应减少
    • 不造成增发
    • 2分钟说长不长说短不短
      • 作为线下交易使用是过长了，“买咖啡”类的应用必须依赖零确认
      • 对于扩容前景来说，2分钟又太短了。出块平均时间设置在两分钟，而出块的时间间隔的分布是泊松分布，会有大量的相隔几秒的出块，在 GB ， TB 级的区块的时候，很容易造成来不及传输和验证。
  • 引入虫洞方案，利用二层网络方案使得BCH上可以新发token
    • 通过“摧毁”BCH 来获得，是单向的，有去无回。
    • 不能用零确认的BCH，至少要一确认才能让虫洞上的操作接续下去。
  • 引入DSV操作码
    • DSV 操作码的全称为 OP_CHECKDATASIGVERIFY
    • 允许 BCH 对链外结果和数据进行校验
      • 这个方案非常激进，哪怕是在以智能合约为主要特性的ETH或者EOS都没有直接提供对ORACLE或者说外部数据的连接，更多的是结果上链，判定在链下完成。
      • 这个操作码的加入，对bitcoin的原始设定，矿工按打包字节收费这一基础设定有所更改，因为DSV可能是一个复杂操作，但是在字节数上只显示为一个操作码。另外一点，DSV 更改了矿工的定义，矿工从只提供算力校验链上交易的角色码，转变为校验交易和校验数据的双重角色。

BCH-SV

更偏向原始的比特币方案, 不用二层网络方案

  • 扩容，恢复曾经有但被 core 删掉了的操作码，去掉各种限制（比如一个交易内可以使用操作码的数量限制等）
  • tokenized方案，完全利用 OP_RETURN , 在原有网络上增加 token 协议

量子计算对 bitcoin 的威胁

量子计算中已经比较成型的算法：Shor’s algorithm 和 Grover’s algorithm

Shor’s algorithm 解决因式分解的问题 —— 给定一个整数 N，找到其质因数。把指数级的时间复杂度降维成了 polynomial time，也就是多项式时间。

RSA 的基石就是两个大质数 p 和 q 的合数很难被因式分解出 p 和 q。

Shor 对 RSA 体系的破坏性是显而易见的(整个非对称加密体系下的算法都会受到巨大的冲击)，而且，它的变种，对基于椭圆双曲线的 ECDSA 也有类似的降维杀伤力。

然而你还是能信任你的 bitcoin 钱包。虽然 bitcoin 钱包的私钥和钱包地址都来源于 ECDSA 的私钥和公钥，然而钱包地址并非直接是公钥，而是公钥的 hash。因而，你给一个钱包打钱，并不会需要钱包的公钥；只有这个钱包使用里面的钱（给别人打钱）时，才需要把自己的公钥放在 transaction 里。如果一个钱包只是收钱，那么它是安全的 —— 即便 Shor 算法也需要公钥去逆向私钥。因为公钥没有暴露出来，Shor 算法无法使用。因而即便量子计算破解了非对称加密算法，对于那些没有使用过的冷钱包（code wallet），也无法破解。对于那些需要 multisig 的钱包，也是类似。

如果非得破解冷钱包，那么需要先把钱包地址逆向出来其公钥，而这个操作 Shor 无法完成，只能借助 Grover 算法。

基本上，Grover 对于函数 f(x) = y，只要给定 y，以及 x 取值的一个列表，它可以以 O(sqrt N) 的时间复杂度，找到这个 x。换句话说，随便一个算法，正常情况下暴力破解（在算法的定义域里一个个试），是 O(N)，Grover 将其降低成 O(sqrt N)，对于时间复杂度来说，这算法虽然看上去不错，但大多数情况下只是聊胜于无。

一个 256bit 的公钥, 256bit 数字的取值范围 n_max: 5.78960446186581e+76

sqrt(n_max) = 2.4061596916800453e+38

而 log(n_max) = 176.75253104278605

虽然 sqrt 后量级已经大大减少，但还是 trillion trillion trillion 级别，在一个可以预见的时间内无法破解。所以，即便使用了 Grover 算法，也无法有效地通过钱包地址破解出公钥，进而进一步使用 Shor 算法从公钥破解出私钥。

NewHope 密钥交换协议

该协议 被认为可抵抗量子计算机的攻击，因此今天记录两个对等体之间通信的窃听者将无法在将来解密该数据他们拥有一台快速量子计算机。

Schnorr签名

TODO:

可以用来改善区块链的隐私，同时通过将无关数据移出区块链来提高可伸缩性。

任何多重签名协议，如BitGo或闪电网络使用的协议，都将与普通点对点交易一样小。由此节省的空间总量很难估计，但如果每个人都采用这种方法，预计比特币区块链的容量将增加10-20%。

Schnorr签名可以很容易地扩展到支持固定大小的多签名和阈值签名，以及“无脚本脚本”，这些脚本允许在签名中编码闪电支付通道的语义。而对于ECDSA，这要困难得多。Schnorr签名的批量验证也是可能的，这使得它们的验证速度比比特币的ECDSA签名快得多。

Schnorr的签名，连同Taproot和无脚本脚本，承诺让所有比特币输出看起来都一样，无论它们属于一个人，还是属于许多人，都代表着托管、Liquid挂钩、闪电通道或智能合约。通过这种方式，他们将大大提高比特币的隐私。

无脚本脚本（Scriptless scripts）是扩展两方Schnorr多签名协议的一种方法。该协议允许两个用户联合生成一个签名，使联合签名具有与普通签名相同的大小和使用相同的验证方程。使用无脚本脚本，可以扩展此协议，当最后一方完成签名时，还会向另一方泄露额外的秘密。这个额外的秘密可以像在Lightning HTLC中使用的“哈希原像（hash preimages）”一样使用，而且还有一个额外的好处，那就是它不会出现在区块链上。它还具有更多的代数结构，这使得它在连接多个支付通道时可以“重新盲化”，从而修正了闪电网络的隐私限制，即路径中的每个通道都需要使用相同的路径。

无脚本脚本可以极大地改善隐私，它允许用户创建长路径的支付通道，而不用使用相同的哈希像原将它们链接起来，还可以防止这些哈希显示给区块链。eltoo可以提高可扩展性，它使用的是SIGHASH_NOINPUT，这是比特币的另一个提议，允许闪电用户在一定的空间内无限期地维护支付通道。

Taproot 是为比特币提出的一个提议，所有的输出都用一个签名密钥，可以用一个签名消费。使用多重签名和无脚本脚本，可以使用这些单签名对多方交易、闪电支付通道等进行编码。Taproot还允许这个密钥提交到一个额外的脚本，以防无脚本脚本不够用。但是在合作的情况下，从来没有显示过这个额外的脚本。Taproot 不能隐藏资金流向和具体金额的，只能隐藏合约内容，而且如果双方不愿意合作，可能还是会暴露合约的内容

Graftroot 是另一个被提出的扩展方案，它不太可能很快被包含在比特币中，它进一步允许Taproot签署者签署替代的消费路径，而不是使用Taproot输出中提交的脚本。由于没有对可以签署多少消费策略的限制，在用户有1000条消费路径的情况下，这将大大提高效率。然而，在实践中还不清楚这是否是用户所希望的。

大大提高了多签名的可伸缩性，允许创建具有非常多参与者的多重签名，同时比特币区块链不需要任何空间成本。它们还可以用来在比特币和Liquid之间创建原子交换交易，而且除了普通交易之外，不需要额外的比特币空间成本。

Schnorr签名方案会遇到重放攻击（Replay Attack）的问题，如果不去研究新的机制，目前的MuSig签名方案就无法保护在虚拟机中进行签名的用户。可以被解决： https://zkproof.org/workshop2/main.html

bip-taproot & bip-tapscript

总结 from: https://bitcoinops.org/en/newsletters/2019/05/14/

  • bip-taproot 允许通过 Schnorr-style 签名 或 通过 merklized script 默克尔化脚本 进行花费
  • bip-tapscript 定义了 用于 bip-taproot 中 merkle spend 默克尔花费的脚本语言（与 bitcoin 中现有脚本相近但稍有不同）。
  • 单签 P2PKH 和 P2WPKH 中，生成私钥，派生出公钥，对公钥进行哈希然后生成地址的 witness program。Taproot 中 哈希这一步被省略，所以 地址中会直接包含 公钥。
    • P2WPKH
Object Operation Example result
Private key read 32 bytes from CSPRNG, or using BIP32 HD derivation 0x807d[...]0101
Public key point(0x807d[…]0101), or using BIP32 HD public derivation 0x02e5[...]3c23
Hash ripemd(sha256(0x0202e5[…]3c23)) 0x006e[...]05d6
Address bech32.encode(‘bc’, 0, 0x006e[…]05d6) bc1qd6[...]24zh
* Taproot - Taproot 中 哈希这一步被省略，所以 bech32 地址中会直接包含公钥, 伴随着一点小改变。 33-byte 比特币公钥 以 0x02 或 0x03 开头，以便验证者在secp256k1椭圆曲线上重建密钥的 Y-坐标; bip-taproot 中该值会被减2，于是 0x02 变成 0x00， 0x03 变成 0x01 但含义不变。这样（换成使用低位）的好处是，把剩下的位省下用来将来软分叉。此外， witness version 从P2WPKH/P2WSH 中的 0 变成了 1.
Object Operation Example result
Private key (Same as above) 0x807d[...]0101
Public key (Same as above) 0x02e5[...]3c23
Alter key prefix (key[0] - 2),key[1:33]) 0x00e5[...]3c23
Address bech32.encode(‘bc’, 1, 0x00e5[…]3c23) bc1pqr[...]xg73
+ 花费 P2PKH 或 P2WPKH 需要在 inpu 中包含 公钥。Taproot 中公钥会在花费的 UTXO 中提供，所以可以省略好几个 vbytes。 + 创建 Taproot output 和 创建一个 P2WSH output 占用基本差不多空间；但花费一个单签 Taproot 比起 P2WPKH 节省 40% 的空间。而节省交易体积就有助节省交易费。 + 交易消息摘要中的 double-SHA256 hashing 其实不能提供额外的安全帮助。所以 Taproot 中换成了只进行一次。 + 对 多签来说，Taproot 无论有多少密钥和签名，占用大小都一样。而 P2WSH 中每多一个公钥就要增加 8.5 vbytes，每多一个签名就要增加 18.25 vbytes。 * ![2019-05-taproot-multisig-size](/img/optech/2019-05-taproot-multisig-size.png) + Tapscript 中不再接受 ECDSA 签名。 + Tapscript 中废除了 OP_CHECKMULTISIG 和 OP_CHECKMULTISIGVERIFY。 可以使用 OP_CHECKSIGADD (OP_CSADD) 来替代，并可以显著加速批量验证签名。 + 通过 taproot 和 tapscript，single-sig, multisig, and MAST-based spends 都可以只用同一个 public key 和签名,那么追踪用户在使用 bitcoin 哪一个特性就更难，这算是对抗追踪、对抗审查的一个好事。

RSK

rsk，以前被称为Rootstock，是一个比特币的侧链, layer 2，RSK克隆了以太坊的虚拟机(EVM)，这意味着该平台支持EDCCs（智能合约）。