bitcoin script

简介: P2PK P2PKH,MS,P2SH,OP_RETURN 等的区别1.P2PK pay_to_public_keypubkey script: OP_CHECKSIGsignature script: [sig]2.

P2PK P2PKH,MS,P2SH,OP_RETURN 等的区别

1.P2PK pay_to_public_key

pubkey script:

 <pubkey> OP_CHECKSIG

signature script: [sig]

2. P2PKH pay_to_public_key_hash

pubkey script:

 OP_DUP OP_HASH160 hash(pubkey) OP_EQUALVERIFY 

signature script:

[sig] <pubkey>

3.P2SH pay_to_script_hash

pubkey script:

OP_HASH160 hash(Redeem script) OP_EQUAL

signature script:
此处和上面两个都不一样,解锁需要分成两部
第一步: 验证 redeem script hash 值是否正确,也就是将redeem script 作为数据放到栈上,然后执行 OP_HASH160,如果为真才会执行第二步,否则失败
第二步:执行redeem script, 将signature script+redeem script 一起执行,如果为真则成功,否则交易失败

4.P2WPKH pay_to_witness_public_key_hash

pubkey script:

0 HASH160(public key)

解锁脚本 signature script(scriptSig):

还增加了一个 witness 字段,用于验证交易合法性
witness:

如果按照前面的验证规则,所有的隔离见证交易都是合法的,所以这是一个软分叉.

5. P2WSH pay_to_witness_script_hash

pubkey script:

0 SHA256(redeem script)

scriptSig: 空
witness:

矿工如何区分交易类型?

主要是根据 pubkey script 的模式进行匹配,不同的模式匹配不同的验证规则.尤其是隔离见证部分.

scriptSig包含什么内容?

没看源码,纯属个人猜想.
一个 tx 的结构如下:

type MsgTx struct {
    Version  int32
    TxIn     []*TxIn
    TxOut    []*TxOut
    LockTime uint32
}
// TxIn defines a bitcoin transaction input.
type TxIn struct {
    PreviousOutPoint OutPoint
    SignatureScript  []byte
    Witness          TxWitness
    Sequence         uint32
}
// TxOut defines a bitcoin transaction output.
type TxOut struct {
    Value    int64
    PkScript []byte
}

签名放在 TxIn 中,因此签名应该是对hash(Version,LockTime, current TxIn(exclude signature script),all TxOut)) 进行签名.

这样狂购可以验证交易,但是不能修改交易. 至于 TxID 为什么会变,是否因为 TxIn以及 TxOut 的顺序可以被矿工调整?

目录
相关文章
|
9月前
|
负载均衡 监控 网络安全
pm2:ecosystem.config.js
pm2:ecosystem.config.js
208 0
|
自然语言处理 安全 JavaScript
手把手教你CSP系列之script-src
手把手教你CSP系列之script-src
821 0
|
JavaScript
two js questions
two js questions
57 0
|
人工智能 JavaScript Oracle
使用 Solidity 和 Node.js 构建简单的区块链预言机
区块链上的预言机是允许区块链世界与来自WEB其余部分的数据交互的框架,将其称为 WEB 2.0 世界。随着智能合约应用的不断扩展,处理独特用例所需的各种数据也将不断扩大。
385 0
使用 Solidity 和 Node.js 构建简单的区块链预言机
Hammer.js分析(二)——manager.js
“Manager”是所有识别器实例的容器,它为你设置的元素安装了交互事件监听器,并设置了触摸事件特性。 manager.js中的代码会涉及到input.js和recoginzer.js中的内容,这里会先做大致的流程分析,具体分析会在接下来的文章中详谈。
Hammer.js分析(二)——manager.js
Hammer.js分析(三)——input.js
input.js是所有input文件夹中类的父类,浏览器事件绑定、初始化特定的input类、各种参数计算函数。 Input父类和其子类就是在做绑定事件,各种参数计算、整合、设置等返回自定义事件对象,交给识别器的相关对象使用。
Hammer.js分析(三)——input.js
OPA 3 - thirdParty Qunit.js and IFrame load logic
Created by Wang, Jerry, last modified on Nov 08, 2015
107 0
OPA 3 - thirdParty Qunit.js and IFrame load logic
|
缓存 JavaScript 前端开发
Script Lab 02:Script Lab,知识储备
Script Lab 02:Script Lab,知识储备
155 0
Script Lab 02:Script Lab,知识储备
|
JavaScript 前端开发 安全
为什么Discourse选择ember.js
Discourse的推出在整个社区赚足了眼球,由于Discourse选择使用Ember.JS作为前端MVC框架,这促使Ember.JS也成为了热议的话题。一年多以前SproutCore2正式改名为Ember.JS后,本人持续的关注了Ember.JS的开发过程,见证着Ember.JS的成长。Ember.JS的API在整个社区共同协作的基础上日趋稳定,Ember.JS 1.0.rc1的推出,更是标着其API已经成熟。我相信越来越多基于Ember.JS实现的优秀的应用,将会像雨后春笋般涌现出来。
128 0
为什么Discourse选择ember.js
|
C++ 开发工具 git