-
Notifications
You must be signed in to change notification settings - Fork 0
Bitcoin Mining & Scripts
0012338jason edited this page Oct 29, 2024
·
10 revisions
- 第一代:CPU(很多部分閒置,浪費)
- 第二代:GPU(很多部分閒置,浪費)
- 現在:ASIC 礦機(Application Specific Integrated Circuit)
- 單獨礦工要挖出區塊的機率很低
- 單獨礦工的收入不穩定
- 讓礦工的收入穩定
- 當有礦工成功挖到區塊時,礦主再依所有礦工提交的工作量證明分配收益
-
有沒有可能礦工挖到合法區塊時,把它丟棄不提交?
- 有可能,對礦工而言並沒有經濟上好處,但礦池之間存在競爭關係,可能會是礦池之間的破壞行為
-
大型礦池讓 51% attack 發生的可能性提高
- forking attack:等到最長鏈完成六次確認後,再分叉並透過較大的算力使分叉的鏈追趕上成為最長鏈
- boycott attack:出現想要抵制的交易時,立刻分叉
- 交易結構
"result":{
"txid": "921a...dd24", //交易的ID
"hash": "921a...dd24", //交易的hash
"version": 1, //比特幣協議的版本
"size": 226, // (bytes)
"locktime": 0, //設定交易的生效時間
"vin": [...],
"vout": [...],
"blockhash": "0000000000000000002c510d...5c0b",
"confirmations": 23,
"time": 1530846727, //交易產生的時間
"blocktime": 1530846727 //區塊產生的時間
}
"vin":[{
"txid": "c0cb...c57b", //幣的來源交易的哈希值
"vout": 0, //幣的來源交易是區塊的第幾個輸出
"scriptSig": { //輸入腳本,之後用"input script"替代
"asm": "3045...0018",
"hex": "4830...0018"
},
}],
"vout": [{
"value": 0.22684000, //單位是 BTC
"n": 0,
"scriptPubKey": { //輸出腳本,之後用"output script"替代
"asm": "DUP HASH160 628e...d743 EQUALVERIFY CHECKSIG",
"hex": "76a9...88ac",
"regSigs": 1, //此輸出需要幾個簽名
"type": "pubkeyhash",
"addresses": ["19z8LJkNXLrTv2QK5jgTncJCGUEEfpQvSr"] //輸出的地址
}
},{
"value": 0.53756644,
"n": 1,
"scriptPubKey": {
"asm": "DUP HASH160 da7d...2cd2 EQUALVERIFY CHECKSIG",
"hex": "76a9...88ac",
"regSigs": 1,
"type": "pubkeyhash",
"addresses": ["1LvGTpdyeVLcLCDK2m9f7Pbh7zwhs7NYhX"]
}
}]
- 要驗證 "TX: B
$\to$ C" 這個交易的幣的來源正確性 - 將輸入腳本和輸出腳本拼接起來執行
- 形式
- input script:
- PUSHDATA(Sig)
- output script:
- PUSHDATA(PubKey)
- CHECKSIG
- input script:
- 腳本執行
- step1
- step2
- step3: 用 PubKey 檢查 Sig 是否正確
- step1
- 形式
- input script:
- PUSHDATA(Sig)
- PUSHDATA(PubKey)
- output script:
- DUP
- HASH160
- PUSHDATA(PubKeyHash)
- EQUALVERIFY
- CHECKSIG
- input script:
- 腳本執行
- step1
- step2
- step3
- step4: 將 PubKey 從 stack 中取出取哈希後再放入 stack 中
- step5
- step6: 若 stack 最上面兩個 PubKeyHash 相同,則取出
- step7: 用 PubKey 檢查 Sig 是否正確
- step1
使用P2SH時,複雜的腳本詳細說明了花費輸出(贖回腳本)的條件,但不是在output script中顯示。只有它的hash在output script中,這將費用和複雜性的負擔從交易的發送者轉移到了接收者(消費者)。
-
input script 要给出一些簽名(數目不定)及一段序列化的 redeemScript
- 驗證時分兩步:
- 驗證這段序列化的 redeemScript 是否與 output script 中的哈希值匹配?
- 反序列化並執行 redeemScript ,驗證 input script 中給出的簽名是否正確?
- redeemScript 的形式
- P2PK 形式
- P2PKH 形式
- 多重簽名形式
- 驗證時分兩步:
-
形式
- input script:
- ...
- PUSHDATA(Sig)
- ...
- PUSHDATA(serialized redeemScript)
- output script:
- HASH160
- PUSHDATA(redeemScriptHash)
- EQUAL
- input script:
-
用 P2SH 實現 P2PK
- 形式
- redeemScript:
- PUSHDATA(PubKey)
- CHECKSIG
- input script:
- PUSHDATA(Sig)
- PUSHDATA(serialized redeemScript)
- output script:
- HASH160
- PUSHDATA(redeemScriptHash)
- EQUAL
- redeemScript:
- 腳本執行
- 第一階段的驗證
- step1
- step2
- step3
- step4
- step5
- step1
- 第二階段的驗證
- step1
- step2
- step1
- 第一階段的驗證
- 形式
- 腳本執行
- step1
- step2
- step3
- step4
- step5
- step6
- step7
- step8
- step9
- step1
- 實際應用不方便:交易雙方皆要先知道 M 及 N 值
- 用 P2SH 實現多重簽名
- 形式
- 腳本執行
- 第一階段的驗證
- step1
- step2
- step3
- step4
- step5
- step6
- step7
- step1
- 第二階段的驗證
- step1
- step2
- step3
- step4
- step5
- step6
- step1
- 第一階段的驗證
- 形式

