比特币数据结构解析

区块

区块结构

{
  "version": 1,
  "merkleroot": "10f072e631081ad6bcddeabb90bc34d787fe7d7116fe0298ff26c50c5e21bfea",
  "tx": [
    "10f072e631081ad6bcddeabb90bc34d787fe7d7116fe0298ff26c50c5e21bfea"
  ],
  "time": 1233046715,
   "nonce": 2999858432,
  "bits": "1d00ffff",
  "difficulty": 1,
  "previousblockhash": "00000000a1496d802a4a4074590ec34074b76a8ea6b81c1c9ad4192d3c2ea226",
}

区块hex解析

block: 00000000dfd5d65c9d8561b4b8f60a63018fe3933ecb131fb37f905f87da951a
hex:

0100000026a22e3c2d19d49a1c1cb8a68e6ab77440c30e5974404a2a806d49a100000000eabf215e0cc526ff9802fe16717dfe87d734bc90bbeaddbcd61a0831e672f010bbcc7e49ffff001d0035ceb20101000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0804ffff001d029b01ffffffff0100f2052a0100000043410413e59d83b9055a14263cf4d953dc11fdc767be418325ef592150f16f944030d64a31105e2b5977118f4f3fa67b903b8ccc05b09770a791adfa061511f16e549cac00000000

hex解析:

版本号:01000000
前继block:26a22e3c2d19d49a1c1cb8a68e6ab77440c30e5974404a2a806d49a100000000(默认32个字节需要网络字节序转主机字节序:00000000a1496d802a4a4074590ec34074b76a8ea6b81c1c9ad4192d3c2ea226)

merkle根:eabf215e0cc526ff9802fe16717dfe87d734bc90bbeaddbcd61a0831e672f010(默认32个字节需要网络字节序转主机字节序:10f072e631081ad6bcddeabb90bc34d787fe7d7116fe0298ff26c50c5e21bfea)

时间:bbcc7e49(默认32个字节需要网络字节序转主机字节序:497eccbb,1233046715)

bits:ffff001d(难度目标,默认32个字节需要网络字节序转主机字节序:1d00ffff)

nounce:0035ceb2(默认32个字节需要网络字节序转主机字节序:b2ce3500,2999858432)

交易数量:01

交易body:01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff0804ffff001d029b01ffffffff0100f2052a0100000043410413e59d83b9055a14263cf4d953dc11fdc767be418325ef592150f16f944030d64a31105e2b5977118f4f3fa67b903b8ccc05b09770a791adfa061511f16e549cac00000000

交易

交易结构

交易包含:

{
    version:0x01,
    inCount:1,
    ins:[
        {
            "txid":"74c1a6dd6e88f73035143f8fc7420b5c395d28300a70bb35b943f7f2eddc656d",
            "index":0,
            "scriptSig":"493046022100b687c4436277190953466b3e4406484e89a4a4b9dbefea68cf5979f74a8ef5b1022100d32539ffb88736f3f9445fa6dd484b443ebb31af1471ee65071c7414e3ec007b014104f9804cfb86fb17441a6562b07c4ee8f012bdb2da5be022032e4b87100350ccc7c0f4d47078b06c9d22b0ec10bdce4c590e0d01aed618987a6caa8c94d74ee6dc",
            "sequence":ffffffff
        }
    ],
    outCount:2,
    outs:[
        {
            "value" : 0.01,
            "scriptPubKey":"410403c344438944b1ec413f7530aaa6130dd13562249d07d53ba96d8ac4f59832d05c837e36efd9533a6adf1920465fed2a4553fb357844f2e41329603c320753f4ac"
        }
        {
            "value" : 49.91,
            "scriptPubKey":"4104f9804cfb86fb17441a6562b07c4ee8f012bdb2da5be022032e4b87100350ccc7c0f4d47078b06c9d22b0ec10bdce4c590e0d01aed618987a6caa8c94d74ee6dcac"
        }
    ],
    nLockTime:000000
}

交易hex解析

交易: 131f68261e28a80c3300b048c4c51f3ca4745653ba7ad6b20cc9188322818f25

交易hex:

01000000016d65dcedf2f743b935bb700a30285d395c0b42c78f3f143530f7886edda6c174000000008c493046022100b687c4436277190953466b3e4406484e89a4a4b9dbefea68cf5979f74a8ef5b1022100d32539ffb88736f3f9445fa6dd484b443ebb31af1471ee65071c7414e3ec007b014104f9804cfb86fb17441a6562b07c4ee8f012bdb2da5be022032e4b87100350ccc7c0f4d47078b06c9d22b0ec10bdce4c590e0d01aed618987a6caa8c94d74ee6dcffffffff0240420f000000000043410403c344438944b1ec413f7530aaa6130dd13562249d07d53ba96d8ac4f59832d05c837e36efd9533a6adf1920465fed2a4553fb357844f2e41329603c320753f4acc0aff62901000000434104f9804cfb86fb17441a6562b07c4ee8f012bdb2da5be022032e4b87100350ccc7c0f4d47078b06c9d22b0ec10bdce4c590e0d01aed618987a6caa8c94d74ee6dcac00000000

hex解析

版本号:01000000
vin数量:01
vin交易id:6d65dcedf2f743b935bb700a30285d395c0b42c78f3f143530f7886edda6c174
(txid,默认32个字节需要网络字节序转主机字节序 74c1a6dd6e88f73035143f8fc7420b5c395d28300a70bb35b943f7f2eddc656d)
vin索引:00000000(代表交易(74c1a6dd6e88f73035143f8fc7420b5c395d28300a70bb35b943f7f2eddc656d)的第几个输出)
签名长度:8c(140个字节,280个hex码)
vin的签名:493046022100b687c4436277190953466b3e4406484e89a4a4b9dbefea68cf5979f74a8ef5b1022100d32539ffb88736f3f9445fa6dd484b443ebb31af1471ee65071c7414e3ec007b014104f9804cfb86fb17441a6562b07c4ee8f012bdb2da5be022032e4b87100350ccc7c0f4d47078b06c9d22b0ec10bdce4c590e0d01aed618987a6caa8c94d74ee6dc

// 140字节长度的签名,含有两个部分:签名+公钥
{
    签名长度:49(73个字节,146个hex码)
    签名:3046022100b687c4436277190953466b3e4406484e89a4a4b9dbefea68cf5979f74a8ef5b1022100d32539ffb88736f3f9445fa6dd484b443ebb31af1471ee65071c7414e3ec007b01
    公钥长度:41(65个字节,130个hex码)
    公钥:04f9804cfb86fb17441a6562b07c4ee8f012bdb2da5be022032e4b87100350ccc7c0f4d47078b06c9d22b0ec10bdce4c590e0d01aed618987a6caa8c94d74ee6dc
}
sequence:ffffffff

vout数量:02
vout1金额:40420f0000000000(默认8个字节需要网络字节序转主机字节序,00000000000f4240->1000000->0.01btc)
vout1输出地址长度:43(67个字节,134个hex码)
vout1输出地址:410403c344438944b1ec413f7530aaa6130dd13562249d07d53ba96d8ac4f59832d05c837e36efd9533a6adf1920465fed2a4553fb357844f2e41329603c320753f4ac
vout2金额:c0aff62901000000
vout2输出地址长度:43(67个字节,134个hex码)
vout2输出地址:4104f9804cfb86fb17441a6562b07c4ee8f012bdb2da5be022032e4b87100350ccc7c0f4d47078b06c9d22b0ec10bdce4c590e0d01aed618987a6caa8c94d74ee6dcac
锁定时间:0000000

七 区块同步

涉及协议

inv
getheaders
headers
getdata
block
merkleblock
sendheaders

说明

block广播有多种方式。
方式一:
直接发送block消息

方式二:
发送inv消息。
BF结点通过getdata获取数据
HF结点通过getheaders->headers->getdata获取数据

方式三:
直接发送headers. 跳过了inv和getheaders协议。
HF结点如果prefer这种方式,需要发送sendheaders消息给接受方。sendheaders消息没有body
这种方式再BIP130中提到,在0.12版本加入
是对方式二种HF的改进。

六 数据同步:交易

涉及协议

mempool
inv
getdata
tx

mempool

  • 当一个节点新加入网络时,往往会从其他节点获取保存在内存池中的交易,便于挖矿。此时发送mempool协议
  • 接收方收到mempool后,发送inv,传送txid
  • 一个inv只能发送50,000个交易。在btc core 0.9.0以前,一个mempool只返回一个inv。因此内存池中超出的交易将不会被发送(0.9.0版本后,可以发送多次mempool, 把所有的mempool交易发出去)
  • mempool没有body部分

inv

响应mempool

getdata

接收到inv后调用getdata。类型为MSG_TX

tx

tx消息在以下情况被发送:

  • 响应getdata. 当getdata的类型为MSG_MERKLEBLOCK,MSG_TX时,发送tx
  • 主动发送自身节点产生的tx

五 数据同步: header first

涉及协议

getheaders
headers
getdata
block

说明:

在btc core 0.10.0开始,使用了Header First来作为IBD( initial block download)

getheaders

协议数据和getblocks一样。唯一的区别在于,getblocks是通过inv响应,只能响应最多500个block. getheaders通过headers响应,响应最多2000个block

headers

响应getheaders。结构体包括header的个数,下面就是一个个的block header结构体列表

01 ................................. Header count: 1

02000000 ........................... Block version: 2
b6ff0b1b1680a2862a30ca44d346d9e8
910d334beb48ca0c0000000000000000 ... Hash of previous block's header
9d10aa52ee949386ca9385695f04ede2
70dda20810decd12bc9b048aaab31471 ... Merkle root
24d95a54 ........................... Unix time: 1415239972
30c31b18 ........................... Target (bits)
fe9f0864 ........................... Nonce

00 ................................. Transaction count (0x00)

getdata

获取block数据

block

响应getdata

四 数据同步:block first

涉及协议

getblocks
inv
getdata
block

说明

获取到peer地址加入网络之后。第一件事是下载现有完整区块链。 在0.9.3版本以前,使用blocks first协议方式来作为IBD( initial block download)

getblocks

广播本地block信息
node之间乱发getblocks。广播本地block信息。消息里面包括发送方拥有的最新block hash(可以是多个,倒序排列,最新的block在最前)
接收方接收到block之后,挨个对比接受到的block。 如果本地block高于发送方。则发送inv消息给对方

getblocks协议如下

71110100 ........................... Protocol version: 70001
02 ................................. Hash count: 2

d39f608a7775b537729884d4e6633bb2
105e55a16a14d31b0000000000000000 ... Hash #1

5c3e6403d40837110a2e8afb602b1c01
714bda7ce23bea0a0000000000000000 ... Hash #2

00000000000000000000000000000000
00000000000000000000000000000000 ... Stop hash

inv

广播本地”优越“数据信息,等待对方同步。inv消息在以下情况被发送: * 自主发送,用于中转tx或者block。通过type区分。 * 响应getblocks,发送block hash * 响应mempool. 发送内存池tx hash

02 ................................. Count: 2

01000000 ........................... Type: MSG_TX
de55ffd709ac1f5dc509a0925d0b1fc4
42ca034f224732e429081da1b621f55a ... Hash (TXID)

01000000 ........................... Type: MSG_TX
91d36d997037e08018262978766f24b8
a055aaf1d872e94ae85e9817b2c68dc7 ... Hash (TXID)

getdata

节点接受到inv后. 发送getdata消息,请求数据 getdata的消息格式和inv一样 收到getdata后,返回block,tx,merkle block或者notfound消息 getdata不能获取任意block或者tx,消息。只能获取内存池或者中转的消息,一般而言,只能在inv之后使用

block

block消息在以下情况发送: * 响应getdata消息 * 主动发送,往往是在新挖到矿的时候

三 地址广播

涉及协议

addr
getaddr

getaddr:

没有body.
主动向周围节点获取addr信息

addr:

addr用于广播地址,有两种使用方式,一种是主动广播。一种是getaddr的回应

一个addr消息往往包含节点所知道的多个ip地址

    fde803 ............................. Address count: 1000
    d91f4854 ........................... Epoch time: 1414012889
    0100000000000000 ................... Service bits: 01 (network node)
    00000000000000000000ffffc0000233 ... IP Address: ::ffff:192.0.2.51
    208d ............................... Port: 8333  
    [...] .............................. (999 more addresses omitted)

二 握手协议

涉及协议

version
verack

说明

节点互相连接的时候,最开始的握手协议是版本交换,如下图所示:

A发送version
B发送verack和version
A发送verack. 
完成

version:

    72110100 ........................... Protocol version: 70002
    0100000000000000 ................... Services: NODE_NETWORK
    bc8f5e5400000000 ................... Epoch time: 1415483324

    0100000000000000 ................... Receiving node's services
    00000000000000000000ffffc61b6409 ... Receiving node's IPv6 address
    208d ............................... Receiving node's port number

    0100000000000000 ................... Transmitting node's services
    00000000000000000000ffffcb0071c0 ... Transmitting node's IPv6 address
    208d ............................... Transmitting node's port number

    128035cbc97953f8 ................... Nonce

    0f ................................. Bytes in user agent string: 15
    2f5361746f7368693a302e392e332f ..... User agent: /Satoshi:0.9.3/

    cf050500 ........................... Start height: 329167
    01 ................................. Relay flag: true

verack:

没有body部分
用于反馈对方,everything is ready. go!

一 DNS

比特币节点加入网络,必须要连接至少一台机器。

有两种方式:
* 启动程序时通过添加参数,-connect或者addnode直接指定要连接的机器
* 通过DNS seed

一个dns seed就是一个dns server.

dns server保存了一些活跃的网络节点。 新节点询问dns server得到网络节点地址。断开于dns连接,开始与网络节点连接

有许多开源的bitcoin dns软件。其中之一是https://github.com/sipa/bitcoin-seeder

闪电网络原理

闪电网络

一个比特币的链下扩容解决方案

背景

比特币的交易网络最为人诟病的一点便是交易性能:全网每秒 7 笔的交易速度,远低于传统的金融交易系统;同时,等待 6 个块的可信确认导致约 1 个小时的最终确认时间。

目的

闪电网络的目的是实现安全快速地进行链下小额交易,从而提高交易处理速度

定义

闪电网络是一个分布式网络,通过哈希时间锁定智能合约以支持跨参与者网络的即时付款,同时利用区块链的特性消除将资金托管给第三方带来的风险。主要作为用于即时、高容量的微支付。

结构

  1. RSMC(Recoverable Sequence Maturity Contract)

    保障了两个人之间的直接交易可以在链下完成
    
  2. HTLC(Hashed Timelock Contract)

    保障了任意两个人之间的转账都可以通过一条“支付”通道来完成
    

特点

闪电网络允许网络中的所有参与者通过在节点之间找到一条路径,能够网络中上进行即时且廉价的交易。

  • 快速支付:
  • 无需可信第三方
  • 为区块链减负
  • 洋葱式路由
  • 具有多重签名功能
  • 跨链
  • 小额支付
  • 付款即时结算

原理解析

CLTV与CSV

闪电网络目前解决比特币交易处理速度慢,小额支付交易费过高的链下解决方案。因此闪电网络需要比特币底层支持。闪电网络是基于比特币脚本层的CLTV与CSV实现的。

  • CLTV

    OP_CHECKLOCKTIMEVERIFY。它是对于nLockTime验证的script脚本。nLockTime是整笔交易的锁定时间,如果该交易未达到锁定时间是无法打入区块。nlocktime是一个绝对时间。
    
  • CSV

    OP_CHECKSEQUENCEVERIFY。它是对于nSequence验证的script脚本。一笔交易的input交易在1000高度打包,nSequence=10,这笔交易只能在1010高度后被打包。nSequence是一个相对时间。
    

微支付通道

1.描述

由于微支付通道是闪电网络基础,在解析闪电网络之前,需要先解析微支付通道的概念。

如果买卖双方有大量的小额交易,微额交易,比如1个宽带提供商向外提供带宽服务,按小时付费。那大量的小额交易,不仅会让比特币网络负担沉重,而且手续费也不划算。

有人就提出了,在买卖双方,建立1个支付通道,专门支持双方的小额支付,不需要经过比特币网络。这个通道除了建立、关闭的时候,要和比特币网络通信,其他时间,都是双方点到点的通信。

2.例子

A为用户 B为数据提供商,A用100BTC购买B的100G的数据。但是不是一次到账而是分100次结算。如果是用传统转账产生的交易费是无法承受的。因此需要微支付通道。

3.微支付通道建立

  1. A组成一笔交易,输出到a&b多重签名地址。作为保证金交易(tx1)。tx1这时未被A签名。
  2. A组成一笔退款交易,输入为tx1的输出,输出为a:100,并且带上nLockTime1(表示在锁定时间前该退款交易不能生效)。同时交给B签名,并B签名完成后。再对tx1进行签名。(A可保证如果交易未达成,也可退款)
  3. 将tx1广播到网络中,tx1被打包后。说明通道被建立

4.微支付通道流转

  1. A收到B数据后,现在通道的分配需要修改为A:99 B:1。
  2. 创建tx3,输入为tx1的输出,输出为A:99 B:1。nLockTime为900(每次locktime都要小于上一笔的locktime)
  3. A再把这笔交易发个B,B签名后不广播。(如果B在未收到全部金额时,发现A作弊,可以发送已经分配的金额,获得B应得的金额。如果A发现B作弊,最多损失一部分金额。)
  4. 循环123,最终通道分配方案为A:0 B:100 这是locktime为0说明交易可以立即被打包。

5.微支付通道关闭

通道的关闭有三种情况:

  1. 交易失败,A到期回收自己的保证金,广播tx1
  2. 交易中途失败,B到期只能拿到自己已经获得的金额,广播tx3~tx101
  3. 交易成功,B需要在tx1到期时间前广播最终交易tx102

6.微支付通道优点

  1. 解决小额支付,交易过多导致验证过慢,交易费过高的问题。
  2. 解决线下支付双方不信任的问题,交易双方都不能作弊。A手上拿的有B的把柄,B手上拿的有A的把柄。任何1方中途中断,另我1方,把这个把柄广播到区块链网络,就可以执行合约,拿到属于自己的钱。

7.微支付通道缺点

  1. 通道是单向的
  2. nLockTime的限制。假设B跑路了,A也要等到Refund Transaction的nLockTime到期了,才能拿回自己的钱;同样,假设A跑路了,B也要等到updated Transaction的nLockTime到期了,拿到属于自己的钱。

RSMC通道

1.定义

可撤销的顺序成熟度合同(Recoverable Sequence Maturity Contract)

2.目的

  1. 双向支付,而不是单通道 
  2. 1方中途退出,另外1方要立即拿回钱,而不是等到时间到期才能拿回钱。 同时,应该对主动退出方实行惩罚。
  3. 保证交易双方,任何1方都不能抵赖、反悔。

3.RSMC通道创建

  1. 同微支付通道一样首先A&B需要首先打一笔钱到A&B的公共账户中tx1
  2. A&B都输入了保证金这是需要A&B创建自己的退款交易交给对方签名记为txa1,txb1,txa1’,txb1’。记为c1分配方案
  3. txa1,txb1,txa1’,txb1’准备完成后,A&B在对tx1签名广播打包。

4.RSMC通道流转

  1. 当A&B发生资金周转时,A&B重新创建新的通道资金分配方案,txa2,txb2,txa2’,txb2’。记为c2分配方案
  2. 这时c1与c2都有效,因此需要将前一种状态进行作废。如何作废。有两种方式:将txa1’(txb1’)延迟到账交易中输入A2(B2)私钥交给对方。或者创建一笔新的txa1’’(txb1’)交易交给对方,输出为对方地址。我们将该交易成为保证交易(表示我现在想变成新的交易状态,为了促进最新交易 我放弃之前的退款交易。如果我作弊那么你可以拿到我的钱)

5.RSMC通道关闭

RSMC通道的关闭为当交易的一方广播通道的最后一个状态分配方案交易时,发送者一方延迟一段时间获得金额,另外一方立即获得金额。

HTLC通道

1.定义

带时钟的哈希锁定合约( Hashed Timelock Contract)

2.目的

  1. 为未建立通道的双方提供安全的支付 

3.浅析

当A给C转账时,需要通过与B的RSMC通道转给B金钱,然后B通过与C的RSMC通道转给C金钱。

如何保证当B收到金钱时,B一定转给C金钱。通过一个锁定脚本。只有B收到解锁脚本后B才能花费A转给B的金钱。从而实现A与C之间的HTLC通道。

4.简例

A需要给C转1BTC。

  1. C首先产生一个随机数R,然后hash(R),得到H,并把H交给A
  2. A知道通过B可以转账,那么向B发出一笔交易,但是需要在规定时间内拿到正确计算出H的值的。超过规定时间A可以收回资金。
  3. B这时向C发起一笔交易输出脚本,但是需要在规定时间内拿到正确计算出H的值的。超过规定时间B可以收回资金。