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

Latest commit

 

History

History
293 lines (235 loc) · 19 KB

readme.md

File metadata and controls

293 lines (235 loc) · 19 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

设计思想

  • 为什么 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

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？

地址

  • 比特币地址的生成过程是？
    • 第一步，随机选取一个 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

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)

Lightning Network

浏览器:

Relative Lock Time Allows a transaction to be time-locked, preventing its use in a new transaction until a relative time change is confirmed.

Breach Remedy Transaction:[1] the transaction Alice creates when Mallory attempts to steal her money by having an old version of the channel state committed to the blockchain. Alice's breach remedy transaction spends all the money that Mallory received but which Mallory can't spend yet because his unilateral spend is still locked by a relative locktime using OP_CSV. This is the third of the maximum of three on-chain transactions needed to maintain a Lightning channel; it only needs to be used in the case of attempted fraud (contract breach).

Relative locktime:[7] the ability to specify when a transaction output may be spent relative to the block that included that transaction output. Enabled by BIP68 and made scriptable by BIP112. Lightning uses relative locktime to ensure breach remedy transactions may be broadcast within a time period starting from when an old commitment transaction is added to the blockchain; by making this a relative locktime (instead of an absolute date or block height), Lightning channels don't have a hard deadline for when they need to close and so can stay open indefinitely as long as the participants continue to cooperate.

Revocable Sequence Maturity Contract (RSMC):[1] a contract used in Lightning to revoke the previous commitment transaction. This is allowed through mutual consent in Lightning by both parties signing a new commitment transaction and releasing the data necessary to create breach remedy transactions for the previous commitment transaction. This property allows Lightning to support bi-directional payment channels, recover from failed HTLC routing attempts without needing to commit to the blockchain, as well as provide advanced features such as PILPPs.

比特币白皮书 发表于 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 网络的特性，所以闪电网络上的交易是不可阻止的。

缺点

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

ECDSA Failures

Colored Coin

比特币分叉

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

硬分叉

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

软分叉

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

比特币扩容之争

BCH vs BTC

扩大区块 VS 闪电网络

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

nodes