OKCoin

比特币改进方案

骨髓行走 发布在 技术指南 4 7814

作者: Gavin Andresen <gavinandresen@gmail.com>

译者:骨髓行走

20130410024718693

摘要:

这个比特币改进方案(Bitcoin improvement proposal 以下简称BIP)描述了一种在商人和顾客之间的交流协议,该协议使得顾客获得更好的购物体验,并且在支付环节能够更有效的防范中间人的攻击(man-in-the-middle attack)。

改进动机:

现行的比特币支付协议的运作情况如下:

1.顾客添加商品到在线购物车,并决定以比特币进行支付

2.卖家产生一个独特的支付地址,并附上顾客订单,要求顾客支付。

3.顾客从卖家网页上粘贴比特币地址并把它粘贴到任意正在使用的钱包。

4.顾客对发送的卖家地址的支付进行授权,并通过P2P网络向全网广播。

5.卖家服务器检测到该支付,并且待到足够的交易确认形成后承认该支付。

 

本比特币改进方案(BIP)对上述支付协议进行了延伸,使其得以支持一些新的功能。

1.新增人可读的,安全的支付地址—–顾客进行支付的地址不再是一个无法理解的34个字母的比特币地址,而是一个类似“website.com”的地址

2.添加一个支付安全性证明,使得顾客能在和商家发生纠纷时使用这一证明。

3.抵挡中间人攻击的方法是,在交易由硬件钱包授权之前,替换卖家和攻击者的比特币地址。

4.增加支付被接受的消息,那样的话顾客可以瞬间知道卖家收到了支付,并对其支付进行了处理或正在处理

5.增加退款地址,该地址由买家钱包软件自动发送给卖家,因此出现退款或者订单因为某些原因没有成立的情况时,卖家不用联系顾客了。

 

改进协议

这个比特币改进方案描述了一种使用Google’s Protocol Buffers编码的支付协议消息,已验证使用X.509 certificates(译者注:可能是一种专业名词),并在http/https.上得以实现。之后的比特币改进方案也许会将此支付协议延伸到其他编码,PKI系统或传输协议上。

该支付协议由3条消息组成:支付请求,支付,以及支付PaymentACK(译者注:可能又是一种专业名词)。起初,顾客显示出其准备支付的意愿,卖家的服务器以一条支付请求的消息作为回应,流程图如下(译者:红字是笔者标注的,用以说明的更清楚,如有意见,欢迎在评论区指正)

 

1

 

改进协议中的消息

输出:

输出被用在支付请求的消息中以说明一笔支付(或部分支付)应该送到哪里去。它们也被用在支付消息中,以说明一笔退款应该送到哪里。

Message Output{

Optional unit64 amount = 1 [default = 0]

Optional bytes script = 2}

 

上述代码的解释:

Amount是支付1聪(即0.00000001 BTC)

Script:一个“TxOut”Script代表着支付该送到哪里。这将是标准比特币交易Scripts中的一个。该项是可选的,使得日后对这个协议进行扩展。

 

支付细节/支付请求消息

支付请求被分成2个消息,用以支持日后的扩展。信息集合被装在支付细节消息中。而支付细节又被裹在支付请求消息中,支付请求消息包含了关于卖家和数字签名的元信息。

 

Message paymentDetails{

Optional string network = 1[default = “main”]

Repeated Output outputs = 2

Required unit 64 time = 3

Optional unit64 expires = 4

Optional string memo = 5

Optional string payment_url = 6

Optional bytes merchant_data = 7

}

代码解释:

Network:无论是在产品比特币网络中的主要支付,还是在测试性网络中的支付测试。如果一个客户端收到来自该客户端不支持的网络的支付请求,客户端会加以拒绝。

Outputs:在比特币送到的地方会有一个或多个输出。如果总Output为0,顾客会被问及支付量是多少,并且比特币客户端会选择任何或者所有的Outputs用以支付。如果Output不为0,那么顾客将支付应有的支付量,且支付应在那些不为0的Output中被分开。

Time:Unix数字时间戳将会在支付请求创建时产生。

Expires:Unix数字时间戳在支付请求被认为无效时会被产生。

Memo:一种会展示给顾客看的UTF-8编码,纯文本记录。用以解释该支付请求是干什么的。

Payment-url:在一个支付消息发送出去获得一个支付ACK消息时产生。任意数据都可能被卖家使用来验证交易请求消息。当卖家不需要时,该条可以忽略之。

Merchant-data:卖家不需要把支付消息和支付请求消息连接起来,或者如果他们将每个支付请求与一个单独的支付地址连接起来。

一个支付请求中支付细节消息是可选则附在卖家的验证信息中的。代码如下

 

Message PaymententRequest {

Optional unit32 payment_details_version=1 [default =1]

Optional string pki_type =2 [default= “none”]

Optional bytes pki_date =3

Required bytes serialized_payment_details =4

Optional bytes signatuire = 5;

}

 

Payment-details version:下文会对更新升级进行讨论

Pki-type:公钥基础设施(pki)用以验证卖家身份。所有的执行过程应该支持“none”,”x509+sha256”和”x509+shal”。

Pki data:Pki系统的数据,用以验证卖家身份,能被用来创造一个数字签名。

serialized_payment_details:一种序列化的支付细节消息。

Signature:是一种0字节的数组,在数量较多的订单中以序列化形式存在,在PKI data中使用公钥。

当比特币钱包程序收到支付请求消息时,必须做下面几件事来保证授权支付:

 

1.验证卖家的身份且签名使用PKI系统,当pki_type的值不为空时。

2.验证顾客系统上的时间早于支付细节消息的有效期。若不如此,那么支付请求被拒绝。

3.显示卖家的身份并询问买家是否想提交支付请求。

 

支付请求消息大于50,000字节的,应该被钱包软件拒绝,以此来减轻拒绝服务的攻击(denial-of-service)

 

支付:

支付消息会在买家授权支付后发出

授权支付代码:

 

Message Payment {

Optional bytes merchant_date =1 ;

Repeated bytes transactions =2;

Repeated Output refund_to =3;

Optional string memo =4;

}

 

Merchant_data:从PaymentDetails.merchant_data. 复制而来。卖家会使用发票上的数字或者任何其他他们需要的数据来将支付和支付请求消息进行匹配。恶意的客户端会对卖家数据进行修改,所以卖家数据应该以某种方式进行授权。

Transactions:那些全额支付给交易请求消息的交易。

Refund_to:如果必要,在卖家归还退款时会有一个或多个输出

Memo:UTF-8编码,纯文本记录,从买家到卖家之间产生。

若买家授权支付,那么比特币客户端会:

1.创造并签署一个或多个交易来买足PaymentDetails.outputs这个参数

2.将交易在全网进行广播

3.如果PaymentDetails.payment_url 被指定,将会有一个支付消息附在那个URL上。支付消息是序列化的,并作为POST请求的主体被发送。

那些和payment_url服务器进行交换数据所产生的错误将报告给买家。

PaymentDetails.payment_url应该安全可靠能防范中间者攻击

钱包软件通过HTTP协议发送支付消息,这一行为应该有正确的内容格式和适合的抬头格式,正如BIP 71中定义的那样:

 

Content-type: application/bitcoin-payment

Accept:application/bitcoin-paymentcheck

 

 

当卖家服务器收到支付消息时,它必须决定交易是否满足了支付条件。当且仅当此时,交易记录才会向全网进行广播。

PaymentACK:

这个paymentACK消息是支付协议里的最后一环。它从卖家服务器发出,送到买家比特币钱包,以此对支付消息作出响应:

 

Message paymentACK {

Required Payment payment = 1;

Optional string memo =2

}

 

Payment:支付消息的复制版,用以激活paymentACK消息。如果客户端实施了某种其他的方式将支付消息和这个ACK消息连接起来,上述激活步骤则被忽略。

 

Memo:UTF-8编码记录,用以显示买家的交易状态(例如:支付一个比特币来购买十一个衣架的交易正在处理中)

 

定位:

那些支持多语言的卖家应该产生针对不同语言的支付请求消息,将请求和语言连接,或者在merchant_data. 中嵌入一个语言标签。他们也应该产生一个针对不同语言的ACK消息,且基于原生消息之上。

例如:一个说希腊语的买家浏览者希腊语版本的卖家网站,点击了一个”Αγορά τώρα” 链接,这产生了一个支付请求,并且其中merchant_data应该被设置为”lang=el&basketId=11252″.买家进行支付,他们的比特币客户端发送一个支付消息,卖家网站以ACK消息进行回应,用希腊语表示为:”σας ευχαριστούμε”.

证书:

默认的PKI系统使用X.509证书。当 pki_type是 ”x509+sha256″或”x509+sha1″时,pki_data的格式就变成了一个“协议–缓冲——编码”式的证书链:

Message X509Certificates {

Repeated bytes certificate = 1;

}

 

 

若pki_type是”x509+sha256″,那么支付消息会使用SHA256算法进行加密。如果pki_type 是”x509+sha1″,那么SHA1算法会被使用。

证书包含着实体的公钥,电子化的对支付请求消息进行签名将是第一个证书。随后也许会有很多附加的证书,每一个次级证书用以验证前一个证书,一直寻找到一个可信的根授权。接受者必须通过[RFC5280]验证证书链,并且当任何验证失败出现时加以拒绝。

受信任的根证书将从操作系统中获得:如果验证在一个没有操作系统的设备上完成,那么我推荐 Mozilla root store(译者:也许是一种完善根授权的办法)

扩展性:

协议缓冲序列格式在设计之时就定位于可扩展的目的。在一些特别的,新的,可选的领域中,可以加上一条信息,或者是被以往的实施行为给忽略。

交易细节消息也许会扩展一些新的可选的功能,并且仍被视作“初代版本”。旧的实施行为将能对支付请求消息中包含新领域的部分进行验证签名,但是将不能显示是什么新东西被加入到这个消息中。

如果在未来的某个时点,卖家产生支付请求的消息只被新的实施行为所接收,他们可以通过拒绝新的2代版本的支付细节消息来达到上述目的。旧的实施行为应该让用户知道他们应该更新软件了,这通过发送一条更高版本的支付细节消息而被知晓。

那些需要在一些特殊方面延伸消息方案的实施计划应该以1000为起始使用标签,并应该在维基页面:https://en.bitcoin.it/wiki/Payment_Request上更新,以防和其他扩展相冲突

参考文献(略)

译者比特币地址  1H3hKU3LAm7Mqg66RuC5f5R2xxJibjygaQ

版权声明: by nc" sa 作者保留权利。文章为作者独立观点,不代表巴比特立场。

评论:4

您需要登录后才可以回复 登录|注册
    Author Image
    bigsailor 145 天前

    能否给出原文网址或标题啊?

    +1
    +1
    我要点评
    比特币快递
    比特币快递 1064 天前

    比特币改进方案http://t.cn/8FAwV8V

    +1
    +1
    我要点评
    Author Image
    changjia 1100 天前

    资助0.025BTC
    交易ID 43af8da6dac3ba5f78c2313b16787c6ce1ad195e0cfd21c2a24efaca0326fbdf

    +1
    +1
    我要点评
    abc
    abc 1101 天前

    文章显然理解错了比特币的最终意识形态

    比特币要取代的概念不是可以超发印刷的无价值的法币 而是有价值的实物黄金来作为货币体系

    实物黄金的特点:就是不能实名登记 才能形成全球统一货币 从而在历史长河存在了5000年!

    任何试图把比特币实名化的企图 都是徒劳的!

    +1
    +1
    我要点评