郑君的学习笔记

要比昨天进步一点点

发表于 更新于 分类于 本文字数： 1.9k 阅读时长 ≈ 2 分钟

scriptPubKey (“output script”)
pay2pubkey tx: OP_CHECKSIG
Pay2PubKeyHash Tx: OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
Pay2ScriptHash Tx: OP_HASH160 OP_EQUAL

When technical docs refer to the redeemScript, it is referring to the script in the ScriptSig (yet another poorly named element) of the input of a transactions. There is only a redeemScript when redeeming a P2SH.

scriptSig (“input script”)
Pay2PubKeyHash:
Pay2ScriptHash: …

P2SH BIP16

scriptSig: [signature] {[pubkey] OP_CHECKSIG}
scriptPubKey: OP_HASH160 [20-byte-hash of {[pubkey] OP_CHECKSIG} ] OP_EQUAL

  1. [signature] and {[pubkey] OP_CHECKSIG} are pushed onto the stack
  2. OP_HASH160 hashes {[pubkey] OP_CHECKSIG}
  3. The same hash comes from the scriptPubKey onto the stack
  4. Consequently OP_EQUAL gives True
  5. The script is popped off the stack, leaving only [signature] on the stack.
  6. The deserialized script is added, leaving [signature] [pubkey] OP_CHECKSIG
  7. The transaction is validated again, that is, a normal signature verification occurs against the specified public key.

Provably Unspendable/Prunable Outputs

The standard way to mark a transaction as provably unspendable is with a scriptPubKey of the following form:

scriptPubKey: OP_RETURN {zero or more ops}

OP_RETURN tx
https://bchain.info/BTC/tx/1a2e22a717d626fc5db363582007c46924ae6b28319f07cb1b907776bd8293fc

txid 1a2e22a717d626fc5db363582007c46924ae6b28319f07cb1b907776bd8293fc
01000000015db413e8393e51026b492cb0547e5910afe81c72ea6008a357075a3ff1584075010000006a473044022055bcb36c829a614451787fe8c9bfb3798b683809b65b92037a015eccb5ff659702202461d2c708a4fd57c839e43634e8c02935d7b7d1db5b978432b0674c44645ed10121032c1ea520c25c4e66831cd395a3cd26f0e0a1472a3103fc8a4a63ef10e92d123cffffffff010000000000000000166a14215477656e74792062797465206469676573742e00000000

“!Twenty byte digest.”

Freezing funds until a time in the future

Using OP_CHECKLOCKTIMEVERIFY it is possible to make funds provably unspendable until a certain point in the future.

scriptPubKey: <expiry time> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptSig: <sig> <pubKey>

发表于 更新于 分类于 本文字数： 955 阅读时长 ≈ 1 分钟

BIP141

Segregated Witness, or SegWit Bitcoin Improvement Proposal number BIP141

The declared purpose was to prevent nonintentional bitcoin transaction malleability, allow optional data transmission, and to bypass certain protocol restrictions (such as the block size limit) with a soft fork.[2]

It was also intended to mitigate a blockchain size limitation problem that reduces bitcoin transaction speed.

It does this by splitting the transaction into two segments, removing the unlocking signature (“witness” data) from the original portion and appending it as a separate structure at the end.[3] The original section would continue to hold the sender and receiver data, and the new “witness” structure would contain scripts and signatures. The original data segment would be counted normally, but the “witness” segment would, in effect, be counted as a quarter of its real size.

隔离见证做了什么改动？

隔离见证就是把脚本签名(scriptSig)信息从基本结构 (base block) 里拿出来，放在一个新的数据结构当中。做验证工作的节点和矿工也会验证这个新的数据结构里的脚本签名，以确保交易是有效的。
当审核统计区块大小不能超过1M的时候。脚本签名大小不会被计算在内。

隔离见证重新整理了每个交易内容的布局方式。把脚本签名从交易内容的结构里面拿出来，放到了最下面，并有一个指针Pointer指向它。

a5ca0713.png

发表于 分类于 本文字数： 626 阅读时长 ≈ 1 分钟

ref

Conclusions
Bitcoin’s long-running debate over acceptable uses of the block chain has received some much needed clarity. Applications can now inexpensively add a 40 byte data payload to transactions using the OP_RETURN script function. On a technical level, OP_RETURN doesn’t enable anything that wasn’t previously possible. Instead, OP_RETURN provides a standard interface through which new services can potentially be layered onto the block chain, and a central point of focus for future work on integration tools.

This move brings the vision of Bitcoin as a universal platform for mediating complex agreements one step closer to reality. The extent to which the Bitcoin community will embrace this vision remains an open question.

发表于 更新于 分类于 本文字数： 4k 阅读时长 ≈ 4 分钟

change history

2014-03-19 Bitcoin Core version 0.9.0 released

  • OP_RETURN feature
    这个特性不是认可在区块中存储数据，而是创建一个可证明，可裁剪的 output，避免已经提交的一些存储模式，
    例如：在 unspendable TX outputs 中保存图片等任意数据。避免 UTXO database 膨胀影响使用。

在区块中存储非交易数据现在仍然是个坏主意，保存在其他地方更有效率并且成本也更低。

  • Autotools build system
  • Bitcoin-cli
  • Transaction Fees

2014-04-08 Bitcoin Core version 0.9.1 released

No code change, just dependencies

2014-06-16 Bitcoin Core version 0.9.2 released

  • Gitian OSX build
  • GUI

2014-06-19 Bitcoin Core version 0.9.2.1 released

not found potential fork feature

2014-09-27 Bitcoin Core version 0.9.3 released

not found potential fork feature

2015-02-16 Bitcoin Core version 0.10.0 released

BIP 66: strict DER encoding for signatures

2015-04-27 Bitcoin Core version 0.10.1 released

not found potential fork feature

2015-05-19 Bitcoin Core version 0.10.2 released

not found potential fork feature

2015-07-12 Bitcoin Core version 0.11.0 released

  • Change the default maximum OP_RETURN size to 80 bytes
  • Implement BIP62 rule 6
  • Implement BIP66

2015-10-14 Bitcoin Core version 0.10.3 released

2015-10-15 Bitcoin Core version 0.11.1 released

2015-11-13 Bitcoin Core version 0.11.2 released

BIP113 specifies a soft fork

2016-02-23 Bitcoin Core version 0.12.0 released

2016-04-15 Bitcoin Core version 0.12.1 released

This release includes a soft fork deployment to enforce BIP68, BIP112 and BIP113 using the BIP9 deployment mechanism.

2016-08-23 Bitcoin Core version 0.13.0 released

  • From 0.13.0 on, Windows XP is no longer supported.
  • C++11 and Python 3
  • Newly created wallets will use hierarchical deterministic key generation according to BIP32 (keypath m/0’/0’/k’). Existing wallets will still use traditional key generation.
  • Segregated Witness not activate yet
  • Removal of internal miner

2016-10-27 Bitcoin Core version 0.13.1 released

Implement NULLDUMMY softfork (BIP147) (jl2012)

2017-01-03 Bitcoin Core version 0.13.2 released

2017-03-08 Bitcoin Core version 0.14.0 released

2017-04-22 Bitcoin Core version 0.14.1 released

2017-06-17 Bitcoin Core version 0.14.2 released

2017-09-14 Bitcoin Core version 0.15.0 released

2017-09-19 Bitcoin Core version 0.15.0.1 released

fix gui bug

2017-11-11 Bitcoin Core version 0.15.1 released

2018-02-26 Bitcoin Core version 0.16.0 released

  • Segwit Wallet
  • HD-wallets by default
    Due to a backward-incompatible change in the wallet database, wallets created with version 0.16.0 will be rejected by previous versions. Also, version 0.16.0 will only create hierarchical deterministic (HD) wallets. Note that this only applies to new wallets; wallets made with previous versions will not be upgraded to be HD.

    2018-06-15 Bitcoin Core version 0.16.1 released

    2018-07-29 Bitcoin Core version 0.16.2 released

List of Bitcoin consensus fork

ref.
after 0.8.6 version there is six soft fork has been done

Date Activation Block Number BIP Number or Software Version Description Type Outcome
4 July 2015 363,731 BIP66 Strict DER signature upgrade means Bitcoin is no longer dependent on OpenSSL’s signature parsing. Softfork 95% threshold over a 1,000-block period. A chainsplit occurred, lasting six blocks, as some miners signaled support for BIP66 but had not upgraded and were SPY mining. The new softfork rules chain eventually took the lead.
14 Dec 2015 388,380 BIP65 Check Lock Time Verify enables funds to be locked until a specific time in the future. This is Bitcoin’s first new function. Softfork Successful rollout using a 95% threshold.
4 July 2016 419,328 BIP68，BIP112，BIP113 Relative lock-time enables a transaction output to be banned for a relative amount of time after the transaction.CheckSequenceVerify.Median time-past removes the incentive for a miner to use a future block timestamp to grab more transaction fees. Softfork Successful rollout using 95% versionbits signaling.
23 July 2017 477,800 BIP91 This temporary softfork makes signaling for the SegWit upgrade mandatory. Softfork Softfork successfully activated with an 80% miner threshold over a 336-block period, although only a tiny minority of users enforced BIP91 rules, which have since expired. Therefore, the risk of a chainsplit was elevated in this period.
01 Aug 2017 478,479 BIP148 This temporary softfork makes signaling for the SegWit upgrade mandatory for a two week period following 1 August 2017. Softfork Flag-day softfork appeared to succeed with no issues, although only a minority of users enforced BIP148 rules, which have since expired. Therefore, the risk of a chainsplit was elevated in this period.
24 Aug 2017 481,824 BIP141，BIP143，BIP147 The segregated-witness (SegWit) upgrade. Softfork Rollout using 95% versionbits signaling.

发表于 分类于 本文字数： 641 阅读时长 ≈ 1 分钟

bitcoin JSON-RPC

listaddressgroupings

listaddressgroupings

Lists groups of addresses which have had their common ownership
made public by common use as inputs or as the resulting change
in past transactions

Result:
[
  [
    [
      "address",            (string) The bitcoin address
      amount,                 (numeric) The amount in BTC
      "account"             (string, optional) DEPRECATED. The account
    ]
    ,...
  ]
  ,...
]

Examples:
> bitcoin-cli listaddressgroupings
> curl --user myusername --data-binary '{"jsonrpc": "1.0", "id":"curltest", "method": "listaddressgroupings", "params": [] }' -H 'content-type: text/plain;' http://127.0.0.1:8332/

发表于 分类于 本文字数： 2.4k 阅读时长 ≈ 2 分钟

getwork

2012年末 废弃
Getwork
getwork is a JSON-RPC method sent over a HTTP transport.
getwork 比较方便也非常好理解，直接连接到矿池挖矿。只需要填入矿池地址、端口、用户名、密码就可以了
端口 8332
getwork has been removed in v0.10.0

because it does not easily support mining at hash rates above 4 GH/s.
superceded by the newer getblocktemplate mining protocol

POW 的计算就是算区块头的 hash 值，使其小于目标值。

int32_t nVersion;       //版本号，4字节
uint256 hashPrevBlock;  //前一个区块的区块头hash值，32字节
uint256 hashMerkleRoot; //包含进本区块的所有交易构造的Merkle树根，32字节
uint32_t nTime;         //Unix时间戳，4字节
uint32_t nBits;         //记录本区块难度，4字节
uint32_t nNonce;        //随机数，4字节

nVersion，区块版本号，只有在升级时候才会改变。
hashPrevBlock，由前一个区块决定。
nBits，由全网决定，每2016个区块重新调整，调整算法固定。
因此以上3个字段可以理解为是固定的，对于每个矿工来说都一样。

矿工可以自由调整的地方是剩下的3个字段。
nNonce，提供2^32种可能取值。
nTime，其实本字段能提供的值空间非常有限，因为合理的区块时间有一个范围，这个范围是根据前一个区块时间来定，比前一个区块时间太早或者太超前都会被其他节点拒绝。值得一提的是，后一个区块的区块时间略早于前一个区块时间，这是允许的。一般来说，矿工会直接使用机器当前时间戳。
hashMerkleRoot，理论上提供2^256种可能，本字段的变化来自于对包含进区块的交易进行增删，或改变顺序，或者修改Coinbase交易的输入字段。

矿池通过修改 coinbase 交易里面的 extraNonce，让每个矿工计算不同的header

比特币挖矿的逻辑过程如下：

  1. 打包交易，检索待确认交易内存池，选择包含进区块的交易。矿工可以任意选择，甚至可以不选择（挖空块），
    因为每一个区块有容量限制（当前是1M），所以矿工也不能无限选择。对于矿工来说，最合理的策略是首先根据手续费对待确认交易集进行排序，然后由高到低尽量纳入最多的交易。
  2. 构造 Coinbase ，确定了包含进区块的交易集后，就可以统计本区块手续费总额，结合产出规则，矿工可以计算自己本区块的收益。
  3. 构造hashMerkleRoot，对所有交易构造Merkle树。
  4. 填充其他字段，获得完整区块头。
  5. Hash运算，对区块头进行SHA256D运算。
  6. 验证结果，如果符合难度，则广播到全网，挖下一个块；不符合难度则根据一定策略改变以上某个字段后再进行Hash运算并验证。

此外难度有最低限制，也就是说 有个最大值，比特币最低难度取值nBits=0x1d00ffff，
对应的最大目标值为：0x00000000FFFF0000000000000000000000000000000000000000000000000000

rpc request

{"method":"getwork","params":[],"id":1}

不带参数调用getwork，返回数据如下：

{
"midstate" : "9226a024e0b77f61d49fd5ffdf828c6b5c4330c61ea2778c606a8e49d4ad8bd6",
"data" :"00000002e9337bac28ee28a949d2140f9fb0a0ab740acfd739d7bcf67ca31c2301db858ad2ca54d92c8c1cded715922c4df2b07d9f10fa1a6cf3db7e949b320615761ed4581c76f21b12d87500000000000000800000000000000000000000000000000000000000000000000000000000000000000000000000000080020000",
"hash1" :"00000000000000000000000000000000000000000000000000000000000000000000008000000000000000000000000000000000000000000000000000010000",
"target" : "00000000000000000000000000000000000000000000000075d8120000000000"
}

Data字段

共128字节（80区块头字节 + 48补全字节），因为SHA256将输入数据切分成固定长度的分片处理，每个切片64字节，
输入总长度必须是64字节的整数倍，输入长度一般不符合要求，则根据一定规则在元数据末端补全数据。
其实对于挖矿来说，补全数据是固定不变的，这里没必要提供，外部挖矿软件可以自行补齐。
甚至连nNonce字段都不需要提供，data最少只需要提供前面的76字节就够了。nTime字段也是必不可少的，外部挖矿程序需要参照节点提供的区块时间来调节nTime。

发表于 更新于 分类于 本文字数： 214 阅读时长 ≈ 1 分钟

GitHub

The control flow for a typical web application, API server or a microservice looks as follows:

Request -> Route Parser -> [Optional Middleware] -> Route Handler -> [Optional Middleware] -> Response

setup an auth0 account for free

发表于 分类于 本文字数： 1.1k 阅读时长 ≈ 1 分钟

use screen management remote process with ssh

// new a seesion named sessionName
screen -S sessionName
// list all sessions
screen -ls
// reconnect to session witch named sessionName
screen -r sessionName
// remote detach a session named sessionName
screen -d sessionName
// detach current session and reconnect to session that named sessionName
screen -d -r sessionName
// clear dead session
screen -wipe

under the session all command start by ctrl + a (C - a)

C-a ? -> 显示所有键绑定信息
C-a c -> 创建一个新的运行shell的窗口并切换到该窗口
C-a n -> Next，切换到下一个 window
C-a p -> Previous，切换到前一个 window
C-a 0..9 -> 切换到第 0..9 个 window Ctrl+a [Space] -> 由视窗0循序切换到视窗9
C-a C-a -> 在两个最近使用的 window 间切换
C-a x -> 锁住当前的 window，需用用户密码解锁
C-a d -> detach，暂时离开当前session，将目前的 screen session (可能含有多个 windows) 丢到后台执行，并会回到还没进 screen 时的状态，此时在 screen session 里，每个 window 内运行的 process (无论是前台/后台)都在继续执行，即使 logout 也不影响。
C-a z -> 把当前session放到后台执行，用 shell 的 fg 命令则可回去。
C-a w -> 显示所有窗口列表
C-a t -> Time，显示当前时间，和系统的 load
C-a k -> kill window，强行关闭当前的 window
C-a [ -> 进入 copy mode，在 copy mode 下可以回滚、搜索、复制就像用使用 vi 一样
C-b Backward，PageUp
C-f Forward，PageDown H(大写) High，将光标移至左上角 L Low，将光标移至左下角 0 移到行首 $ 行末 w forward one word，以字为单位往前移 b backward one word，以字为单位往后移 Space 第一次按为标记区起点，第二次按为终点 Esc 结束 copy mode
C-a ] -> Paste，把刚刚在 copy mode 选定的内容贴上

发表于 分类于 本文字数： 59 阅读时长 ≈ 1 分钟

create network

official doc
docker network create [OPTIONS] NETWORK