BTC.com手机客户端

比特币合同

申屠青春 发布在 技术指南,比特币 71 11301

 

本文译自比特币WIKI:https://en.bitcoin.it/wiki/Contracts

译者:申屠青春 深圳大学ATR国防科技重点实验室博士 新浪微博 @我看比特币

注意:本文可随意转发,请留下译者信息,如果觉得本文对你有用,请给译者捐赠,以便翻译更多比特币的核心资料。捐赠地址:1faVxBp2KmST98p3tJjx2MQP98JLLnF2Q

 

译者前言

比特币在国内已经众所周知,但是技术研究并未有效开展,大部分人处于知道和了解程度,目前比特圈中许多人对比特币能做什么,同样了解不多。一个重要原因是大多数比特币核心资料都是英文,很少有人能静心看完如此繁杂的英文资料。本人博士论文的研究方向是比特币,在研究其英文技术的同时,拟对一些重要资料进行翻译,让更多的圈内人对比特币有更多的理解。

本文涉及比特币合同,其中提及的合同是非标准交易,可以改写Bitoind、BitCoin钱包代码或使用bitcoinj来生成非标准交易,虽然正常钱包不会接受这些非标准交易,但是有矿池如Eligius.st接受非标准交易并且可以打入到块链中,这样有些钱包软件就能正常处理。具体方法见:《Secure multiparty computations on Bitcoin》程序实现部分。

正文

分布式合同是指一种使用比特币和别人在比特币块链上达成协议的方法,合同不会使得以前不可能的事情变成可能,但是,它们能让你以信任最小化的方式来解决现实问题。信任最小化在合同签订过程中避免人类判断,通常会使得事情变得更方便,因此可由程序实现完全的自动化。

通过构建与比特币交互的最低信任协议,能够创建以下全新产品:

智能资产:能通过块链进行原子交易和贷款的资产。

可转移的虚拟资产:能交易但不能复制的数字资产

代理:是指自治的程序,维护着它们自己的钱包,它们用钱来购买服务器运行时间,代理通过出售服务来挣钱,如果用户需求超过代理的计算能力,它们能生成子代理,这些子代理能否存活要看它们能否得到足够多的业务。

分布式市场:是一种实现点对点债券和股票交易的方法,可使得比特币进化成一个能与互联网金融系统分庭抗礼的竞争者。

瑞波货币交易所:是一种在社交网络上实现分布式货币交易的方法。

本文还列出了一些更小的例子。

许多底层比特币合同的思想,由NickSzabó在他的开创性研究《Formalizing and Securing Relationships on Public Networks》中最先提出,本文由MikeHearn所写,如果你有新型合同的想法,可以联系他。你还可以看看他在2012年伦敦比特币会议上的视频演讲

 

1对内存池交易替换机制的警告

本文是指比特币的一种特殊机制,能使用交易数据结构中的nSequence参数替换内存池中的交易。因为考虑到有人会利用它来实施DOS攻击,这种机制已经在2010年禁用,目前所有相关代码被完全删除。开发者必须注意这点,如果他们开发的程序要与目前钱包兼容,就不要创建依赖于内存池替换的合同机制。如果比特币将来再一次允许内存池替换,本文将会更新。

2理论

每个比特币交易都有一个或多个输入和输出,每个输入/输出都有一个小的纯函数与之相关联,我们称之为脚本,脚本可包含简化形式交易的签名。

每个交易有一个锁定时间,使得该交易处于特定状态并且可被新交易替换,直至锁定时间来临。预定时间可以是块索引或时间戳(这两个因素使用同一个内存项,小于5亿是块索引,大于5亿是时间戳)。当一个交易的锁定时间到了,我们称之为终结。

每个交易的输入都有一个序列号,对于正常发送币的交易,该序列号为UNIT_MAX,锁定时间为0。如果锁定时间还未达到,但所有的序列号为UNIT_MAX,该交易也被认为是终结。序列号用来发布交易的新版本,无需验证其他输入的签名。例如:在一个交易中,每个输入都来自于不同的一方,每个输入的序列号都是0,这些序列号可以独立增加。

签名验证是很灵活的,因为交易的签名方式可以通过SIGHASH符号控制,该符号附加在签名后面。通过这种方式能构建特殊的合同,交易的每个输入方只对交易的一部分签名,因而每个输入方能单方面改变该交易的一部分内容,而无需其他输入方的参与。SIGHASH符号分为两部分,一种模式和一个ANYONECANPAY指示器。

(1)SIGHASH_ALL:这是默认模式。它指示一个交易除输入脚本外,所有部分都被签名。对输入脚本进行签名显然是不可能的,那样无法构建一个交易,所以脚本总是不被签名。尽管如此,要注意的是,输入的其他属性如输出、序列号等都会被签名。直观地说,它的意思是“我同意把我的钱放进去,如果每个人都把他们的钱放进去,并且输出正是我想要的。”。

(2)SIGHASH_NONE:输出没有被签名,可以是任何内容。使用这种模式意味着“我同意把我的钱放进去,如果每个人都把他们的钱放进去,但我不关心输出什么“。这种模式使得其他输入方可以通过改变输入序列号来更新交易。

(3)SIGHASH_SINGLE:像SIGHASH_NONE一样,输入被签名,但序列号没有。因而其他人可以创建交易的新版本,然而,唯一的输出也被签名。该模式说明”如果输出正是我想要的,我同意放钱进去,我不关心其他人的输入。“

ANYONECANPAY指示器可以与以上三种模式联合使用,当设置了ANYONECANPAY时,仅仅是该输入被签名,其他输入可以是任意内容。

脚本可以包括CHECKMULTISIG操作码,该操作码提供了n-of-m的签名验证:你可以提供多个公钥m,定义必须出现的有效签名个数n,签名个数n可以小于公钥数量m。如果我们设置以下脚本,则一个输出需要两个签名:

2 <pubkey1> <pubkey2> 2 CHECKMULTISIGVERIFY

有两种通用方式来安全地创建合同:

(1)在P2P网络之外传递部分完成或无效的交易。

(2)使用两个交易:创建一个交易(合同交易),先签名但不马上广播,在达成合同并且被锁定在内存中后,广播另一个交易(支付交易),最后再广播合同。

用以上方式来保证人们知道他们达成的合同内容。这些特性可以让我们在块链基础上创建有趣的、创新的金融手段。

3示例1:提供押金证明

想像你在一个网站(论坛或WIKI)上注册了一个帐号,想在网站运营者处建立你的信用,但是你没有以前的名誉来支撑你的信用。一个解决方案是向网站付点钱购买信用,但是如果你关闭帐号,可能想要回这部分钱。你对该网站的信任程度不足以让你存钱到该网站,因为担心网站会花掉你的钱。另一个风险是,某一天该网站有可能消失了。

建立信用度的目的是你作出某种奉献,让网站知道你不是一个垃圾机器人。但是你不想网站花掉你的钱。如果网站运营者消失了,你最终想让钱回来,而无需他们的任何许可。

我们通过合同来解决这个问题:

(1)用户和网站相互发送各自新生成的公钥

(2)用户创建交易TX1(支付交易),该交易支出10个BTC到网站地址,用户创建了TX1但不广播。

(3)用户把TX1交易的HASH值发送给网站。

(4)网站使用TX1的HASH值创建交易TX2(合同),TX2花掉TX1的钱并且支付到用户地址。注意:TX2需要双方签名,因而该交易不完整,nLockTime被设置成未来时间(比如六个月后),输入的序列号为0。

(5)最终,这个不完整的交易TX2(一半已签名)被回送给用户,用户检查合同是否如预期-六个月后10BTC最终会回到他的地址-除非情况有变,因为序列号为0,如果双方同意,合同可以被修订。该交易的输入脚本不完整,因为用户未签名,用户对合同签名并且把签名放到合适的位置。

(6)用户先广播TX1,再广播TX2。

在这个阶段,用户和网站都不能单独得到10BTC。六个月后,合同完成,即使网站消失了,用户也能得到币。

如果用户想提早关闭帐号,又该怎么处理呢?网站创建新版的TX2,nLockTime设为0,并且输入的序列号设为UINT_MAX,重新签名,把该交易发回用户,用户签名后广播该交易,就能提早结束合同并且释放10BTC。

如果六个月快到了,而用户想保留他的帐号,又该怎么办呢?类似的事情发生了,合同使用新的nLockTime,序列号比以前的序列号大1,双方重新签名,广播2^32次。无论发生什么,双方都必须同意,才能真正改变合同。

显然,如果该用户被证明是有恶意的(例如:垃圾邮件发送者),网站不会同意提早结束合同。如果用户有太多的滥用行为,则网站可以要求增加押金数量,或者要求延长合同时间。

4示例2:担保和争端调解

一个买家想和他不认识或不信任的某人交易,在一般情况交易正常进行时,买家不想任何第三方参与。但如果交易出现问题时,他想有一个第三方-也许是一个专业的争端调解服务-来决定谁能拿到钱。注意:这个概念同时适用于买家和卖家。例如:调解员可向商家要求邮资证明,以判断是否发货。

换句话说,某人想锁定某些币,在第三方同意的情况下,才能被花掉。

(1)和商家一起引入一个调解员(如:ClearCoin)

(2)得到商家的公钥K1,得到调解员的公钥K2,创建自己的公钥K3

(3)把K2发给商家,商家生成一个随机数挑战调解员,调解员用K2的私钥签名,用来证明K2确实属于调解员

(4)创建一个交易TX1,包括如下输出脚本并且广播该交易。

2 <K1> <K2> <K3> 3 CHECKMULTISIGVERIFY

现在这些币被锁定了,如果要解锁这些币,需要使用以下几种方式:

(1)客户和商家同意(无论是成功的交易,还是在没有调解的情况下商家同意回退给客户)

(2)客户和调解者同意(失败的交易,调解者认同客户,正如退款)

(3)调解者和商家同意(商品已经发送,尽管有争议,商家还是得到币)

当对输入签名时,内容被设为相关联的输出。这样,为了从这个交易中得到币,客户创建包含两个签名位的脚本,自己签一个,再把未完全的交易发给商家或者调解员,请求第二个签名。

5示例3:保证合同

保证合同是建造公众商品时的集资办法,公众商品是指,一旦建成,任何人都可以免费享受到好处。标准的例子是灯塔,所有人都认同应该建造一个,但是对于个人航海者来说灯塔太贵了,灯塔同时也会方便其他航海者。

一个解决方案是向所有人集资,只有当筹集的资金超过所需的建造成本时,每个人才真正付钱,如果集资款不足,则谁都不用付钱。

在保证合同集资方面,包括频繁的、小额的、经常自动进行的集资,例如互联网电台的资金和网页翻译等,比特币优于传统的支付方式。考虑有一个浏览器的插件可供你发送一点币,它能检测当前页面的语言并且广播一个集资请求,用于把该页面翻译成你的语言。如果使用该插件的许多用户同时查看该页面(例如:该页面从高流量的网站链接过来),足够的集资请求广播出去,到达一定的金额时,可自动付钱给一个高质量的翻译公司,当翻译完成后该页面自动在你的浏览器中加载。

我们能以比特币方式建立以下模型

(1)主办方创建新的捐赠地址,宣布如果筹集资金超过1000BTC,则将建造该商品,任何人都可以捐赠。

(2)捐赠者创建一个新交易,把一定数量的钱打到集资地址,但是他们并不广播该交易。该交易与常规的交易相似,除了三个不同点:首先,不能做任何改变,如果你没有正确的输出金额1000BTC,你必须先创建一个;第二,输入脚本要以SIGHASH_ALL|SIGHASH_ANYONECANPAY的模式签名;最后,输出值是1000BTC,注意这不是一个有效的交易,因为输出值比输入值大得多。

(3)把交易上传到主办方的服务器上,他们保存到磁盘上,随时更新捐赠的币数量。

(4)一旦服务器获得了足够的币,它将把所有捐赠者上传的独立交易合并成一个新交易,该交易只有一个输出,仅仅把钱付到捐赠地址,该输出与每个捐赠者的交易的输出部分相同,而输入部分则是所有捐赠者输入的集合。

(5)完整的交易被广播,发送捐赠的币到捐赠地址中。

这样的场景依靠协议的几个方面,首先使用了SIGHASH符号,SIGHASH_ALL是默认模式,意味着要签名所有交易的内容,除了输入脚本。SIGHASH_ANYONECANPAY是附加的指示器,意味着签名仅覆盖自己的输入部分-不签名其他人的输入,这样其他人的输入可以留空。使用这些符号,我们能创建这样一个签名,即使在其他输入添加进入后,该签名依旧是有效的。但如果输出内容或其他的交易部分被改变了,该签名就无效了。第二,输入值小于输出值的交易是无效的(原因很明显),这就意味着捐赠者把发送币的交易发送给主办方是安全的-因为主办方不可能得到这些捐赠币,除非他加上其他的输入值等于或超过输出值。

不使用SIGHASH_ANYONECANPAY指示器也可以创建保证合同。不需捐赠者创建交易的集资方式有两个步骤,一旦达到集资的总金额,主办方就创建包含所有捐赠者输入的交易,然后依次在捐赠者中传递,每个捐赠者对该交易签名。但是,先使用SIGHASH_ANYONECANPAY指示器,然后合并交易,这样可能更方便一些。

保证合同可以保证下一个块的资金网络安全,通过这种方式,即使一个块中的交易数量比较少,挖矿也能挣钱(因为保证合同的交易一般占用空间大,因而要付出更多的网络转帐费)。

Tabarrok在他的论文《The private provision of public goods via dominant assurance

contracts》中详尽描述了保证合同的概念,在一个通用保证合同中,如果合同失败了(在预定时间内集资不足),主办方给捐赠者支付网络转帐费,这种类型的合同旨在鼓励捐赠者,积极参与总是正确做法。有人提出了《A scheme for dominant assurance contracts

6示例4:使用外部状态

脚本被设计成纯函数,它们不能访问外部服务器,也不能导入任何会改变的外部状态,因为攻击者会利用该特性突破块链。而且,脚本语言的功能被严格限制。幸运的是,我们可以以其他方式创建交易,从而与外部世界相联系。

考虑一个例子,老人想让他孙子继承遗产,继承时间是在他死后或者在孙子年满18岁时,无论哪个条件先满足,他的孙子都可以得到遗产。

为了解决这个问题,老人首先给他自己发送孙子要继承的资产数量,以便有一个正确继承数量的唯一输出;接着,他创建一个带有锁定时间的交易,该交易的意思是:在孙子18岁生日时把币支付到孙子的地址中,老人对该交易签名,不进行广播,直接把该交易给了孙子。当过了孙子的18岁生日后,孙子广播了这个交易并且得到他的币。孙子可以在这时间之前广播该交易,但他不会提前得到币,有些节点会在内存池中把这种交易丢弃掉,因为锁定时间在遥远的将来。

死亡条件非常难判断,因为比特币节点不会检测主观条件,我们必须依靠预言,预言是指具有密钥对的服务器,当用户自定义的表达式被证明是真的,它能按照要求对交易签名。

以下是例子,老人创建了一个交易花掉了他的币,把输出设为:

<hash> OP_DROP 2 <sons pub key> <oracle pub key> CHECKMULTISIG

这是一个预言脚本,具有与众不同的形式-它把数据推到堆栈中,然后立即删除。公钥发布在预言服务器的网站上,为公众所知,HASH值设为用户自定义表达式的HASH值,该表达式以预言服务器能理解的方式编写,能确认老人已经死亡。举个例子,可能是以下字符串的HASH值:

if(has_died(‘johnsmith’,born_on=1950/01/02))return(10.0,1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp);

以上语言是假设的,该语言被预言服务器定义,可能是任何一种语言。返回值是一个输出:币数量和孙子的地址。

再一次,老人创建了一个交易,没有广播而是直接给了孙子,他另外还提供了一个表达式和预言服务器的名字,HASH值被写入交易,预言服务器则能解锁表达式。算法如下:

(1)预言服务器接受评估请求,请求包括了用户提供的用户自定义表达式、输出脚本和部分完成的交易,交易中除了scriptSig签名之外,其他部分都已经完成,签名仅包括了孙子的签名,还不足以解锁输出。

(2)预言服务器检查表达式,得到其HASH值,并且与交易中的HASH对照,如果两者不一致,则返回错误。

(3)预言服务器评估表达式,如果表达式的结果不是交易输出的目标地址,则返回错误。

(4)预言服务器签名交易,返回签名给用户,注意:对一个比特币交易签名时,输入脚本被设为相关联的输出脚本。原因是当OP_CHECKSIG操作起作用时,包含该操作码的脚本被放到输入,脚本并不包含签名本身。预言服务器不知道完整的输出,也没必要知道,因为它知道输出脚本、自己的公钥和表达式的HASH值,这就足以使它检查输出脚本并且完成交易。

(5)用户接受新签名,插入到交易的scriptSig项中,广播交易。

当且仅当预言服务器认为老人死了,孙子才能广播两个交易(合同和申报)并且得到币。

预言服务器可以评估任何事情,然而块链中的输出脚本形式总是一样的,考虑以下可能性:

today()==2011/09/25&&exchange_rate(mtgoxUSD)>=12.5&&exchange_rate(mtgoxUSD)<=13.5

给定一个日期,假定mtgox比特币的美元价格在12.5-13.5之间

google_results_count(site:www.google.com/hostednews’MikeHearn’ Olympic gold medal)>0

打赌我会做一些我从来不会真正做的事情(获得奥林匹克金牌)。

//欧洲电视台的歌唱比赛,选择两个优胜者之一打赌。

if(eurovision_winner()==’Azerbaijan’)

return 1Lj9udBVDwptFffGSJSC2sohCfudQgSTPD;

else

return 1JxgRXEHBi86zYzHN2U4KMyRCg4LvwNUrp;

这些条件可使预言服务器的签名变得任意复杂,但是块链仅需要包含一个HASH值即可。

6.1信任最小化:挑战

有许多方法可降低对预言服务器的信任程度。

回到我们的第一个例子,预言服务器还没看到孙子想解锁的交易,因为该交易从没被广播过。这样,它不会支持孙子赎回币,因为它不知道该交易是否存在。人们能做到,并且也应该做到,以自动方式定期挑战预言服务器,确保它总是按照人们想像的方式输出。挑战无需花费任何币,因为要签名的交易是无效的(例如:与一个并不存在的交易关联),预言服务器没法知道签名请求是随意的还是真实的,如何以一个尚未成真的条件来挑战预言服务器,是一个开放的研究课题。

6.2信任最小化:多个独立预言服务器

如果需要,CHECKMULTISIG中的n签名个数可以增加至能够达到n-of-m的预言服务器模式(即m个预言服务器中需要有n个预言服务器签名才能使交易有效),当然,检查预言服务器是独立的而非串通的,也是很重要的。

6.3信任最小化:可信的硬件

使用合适的硬件,你可以进行信任计算,以INTELTXT或AMD等硬件来建立一个封闭的运行环境,然后用TPM芯片向第三方证实其可信度。第三方可判定硬件是否处于所需状态。如果要使硬件失败,则需要有人介入CPU程序的执行过程,甚至在极端情况下,内存总线没有数据流过(如果程序足够小,你完全可以使用缓存来运行程序)

6.4信任最小化:亚马逊AWS预言服务器

最终,也许目前最现实的方法是使用亚马逊的网页服务,截至2013年11月,最合适的预言服务器的解决方案是:《this recipe for creating a trusted computing environment using AWS》,该方案基于《this project for doing selective SSL logging and decryption》。基本思想是:预言服务器使用亚马逊作为其信任根,并且能用亚马逊API证明其是值得信任的,该预言服务器记录在线银行接口的加密SSL会话,如果以后产生交易争端,会话记录能被解密,争端可以被解决。

7示例5:跨链交易

比特币技术可以用来创建多个独立的货币,域名币(Namecoin)就是一个例子,它与比特币的运作规则有些不同,它可以在域名空间中租用域名。与比特币实现理念相同的山寨币,可以在有限信任条件下与比特币进行自由交易。

举例:想像一个财团发行了欧元币(EURCoins),一种以财团的银行存款1:1支持的加密货币。这样的货币与比特币有不同的交易集:更中心化,但没有外汇风险。人们可能希望在比特币与欧元币之间来回交易,

为了实现这个想法,可以使用TierNolan提出的协议

(1)A产生一些随机数据X(秘密)

(2)A产生TX1交易(支付)包含了带跨链交易脚本的输出,看下面的脚本和讨论。它允许币以A和B共同签名的方式释放,也可以以私密X和B签名的方法释放,该交易未广播,块链的释放脚本包含了私密的HASH值,并非真正的私密X本身。

(3)A产生TX2(合同),花掉TX1并且输出到A的地址,该交易有个未来的锁定时间,输入的序列号为0,因而可以被替换。A签名TX2并且发送给B,B给TX2签名后发送回A。

(4)A广播TX1和TX2,B可以看到币但是不能花掉它们,因为并没有输出到B的地址,该交易还没终结。

(5)B在山寨币块链上执行相同的操作,B的锁定时间应该更大于A的锁定时间,双方的交易都待定但未完全。

(6)因为A知道私密X,A能马上申报他的币,然而,A在申报币的过程,向B释放了私密X,B可以以私密X和签名B来完成山寨币块链的交易。

自动化交易完全以点对点的方式进行,能确保货币的流动性,该协议使得这种交易更灵活。跨链交易的脚本如下所示:

IF

2 <keyA> <keyB> 2 CHECKMULTISIGVERIFY

ELSE

<keyB> CHECKSIGVERIFY  SHA256 <hash of secret x> EQUALVERIFY

ENDIF

合同输入脚本如下所示:

<sigA> <sigB> 1

或者

<secretx><sigB>0

例如:第一个数据元素决定使用哪个方式。

参考《Atomic cross-chain trading》能得到更详细的说明。

注意:欧元币是一个很自然的想法,还有其他方法能实现点对货币交易(把比特币换成菲亚特汽车,反之亦然),看《Ripple currency exchange》得到更多信息。

Sergio Demian-Lerner提出了P2PTradeX协议,一种块链交易的解决方案,需要把一个块链中的确认规则有效编码进另一个块链的确认规则。

8示例6:支付证明合同:购买任何纯函数的解决方案

在示例4中,我们看到如何基于任意程序的输出来实现条件支付,这些程序非常有用,能做到任何常规程序实现的功能,比如获取网页。缺点是需要一个第三方(预言服务器),尽管我们有技术来减少预言服务器的信任度,谁都不能减少到0。

对于受限的程序、纯函数,新加密技术已经出现,这些技术能实际上减少信任度到0,无需第三方参加。这些程序不能进行任何I/O操作,但是在许多情况下,这种限制被证明并不重要,或者可以以其他方式绕过,比如给程序一个签过名并且打过时间戳的文档作为输入,无需程序自己从网上下载。

可以阅读一下该协议的解释:《Zero Knowledge Contingent Payment》。

9示例7:特定对象的快速调整(微)支付

与传统支付系统相比,比特币交易费用非常便宜,但是还是需要费用以便被挖矿和融合到块链上。有些情况下,你想快速和便宜地调整发送到某个特定地址的货币金额,而不会导致广播交易的费用。

举个例子:考虑一个不信任的互联网接入点,就像你从来没有去过的咖啡屋中一个WIFI热点一样。每使用10K字节流量你得向咖啡屋支付0.001BTC,无需注册咖啡屋帐号。零信任解决方案意味着可以全自动完成整个过程,因而你在月初预先转了一笔钱到你的手机钱包,然后你的手机会自动与AP协商并且按需给AP支付费用,咖啡屋也希望任何人付钱给它,而无需担心被诈骗。

为了达到这个目标,可以使用下面的协议。该协议依赖nLockTime与原设计不同的行为,从2013年开始,时间锁定的交易被认为是非标准协议,不能进入内存池,这样就不能在锁定时间过期之前广播出去。当nLockTime的行为恢复回中本联的初始设计时,就需要修改以下讨论的协议了。

我们定义客户端为发送向币的那一方,服务端为接收币的那一方,以下协议是从客户的角度来进行的。

(1)创建公钥K1,向服务端请求公钥K2

(2)创建、签名但不广播交易T1,支付10BTC到输出,需要服务端和你自己的公钥,使用OP_CHECKMULTISIG是一个好办法。

(3)创建退款交易T2,与T1的输出相关联,发送所有币回到你的地址。该交易有个锁定时间,例如几小时后,不签名并且把该交易发送给服务端,常规来说,输出脚本是“2 K1 K2 2 CHECKMULTISIG”

(4)服务端用K2签名T2,返回给客户,注意:服务端目前还未看到T1,仅仅看到了T1的HASH值(该HASH值在未签名的T2中)

(5)客户验证服务端的签名是否正确,如果不正确则中止。

(6)客户签名T1并且把签名返回给服务端,服务端广播T1(如果他们双方有联系的话,每一方都可以广播T1),币被锁定。

(7)客户创建一个新交易T3,与T1相联系,类似于退款交易,有K1和K2两个输出,把所有币分配给第一个输出K1,它做了与退款交易相同的事情,但是没有锁定时间,客户签名T3,发送给服务端。

(8)服务端验证输出到它的地址的币数量是正确的,验证客户提供的签名是正确的。

(9)当客户想付钱给服务端,他调整T3,向服务端的输出增加足够的币,同时减少他自己的币数量,然后重新签名T3,发送给服务端。客户无需发送整个交易,只需发送签名和增加的币数量即可。服务端调整T3内容与新的币数量吻合,验证客户的签名并且继续。

整个过程持续到会话结束,或者到1天时间快到来,AP签名和广播最终版本的交易,分配最终的币数量给它自己。退款交易需要处理服务端消息中断和未分配币的情况,如果这些事件发生,一旦锁定时间过期,客服可以广播退款交易,拿回所有的钱。

这个协议已经用bitcoinj实现了

当nLockTime的交易能进入内存池、交易替换重新启用时,本协议必须被修改。在这种情况下,无需退款交易。T3有一个序列号,每次都比前一次大1,T3的锁定时间与以前的时间一致。每次的支付都使得序列号增加1,确保最后版本会优先发生。如果通道协议没有被正常关闭,意味着向服务端支付币不会成功,直到锁定时间过期,客户拿回所有币。为了避免这种情况,双方共同签名T3交易,序列号为0xFFFFFFFF,导致立即确认,而不考虑nLockTime的值。

锁定时间和序列号可以避免一种攻击,在这种攻击中:AP提供连通性,客户使用TX2的第一版本双花,使币回到他自己的地址中,阻止咖啡屋申报帐单。如果客户尝试这么做,该交易不会马上被包括进去,AP在一段时间内可以观察到该交易被广播,然后广播它看到的最后一个版本,就能推翻客户的双花企图。

后一种协议依赖交易替换,具有更大的灵活性,因为在通道的生命周期中,只要客户能收到服务端的签名,协议就能使客户分配给自己的币数量越来越少。但是在许多用例中,这个功能是不必要的。交易替换一样允许配置更复杂的超过两方的通道,如何在这种使用情况下详尽描述协议,就留给读者作练习吧。

10示例8:多方去中心化彩票

使用示例6的一些技术和一些高级的脚本,使得构建无人值守的多方彩票系统成为可能。准确协议在《Secure multiparty computations on Bitcoin》中已经有详细描述。以后可能会在WIKI中添加对这种系统的简要解释。

 

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

评论:71

您需要登录后才可以回复 登录|注册
    比特暴民
    比特暴民 870 天前

    回复@放牛班差子生:比特币的普及程度不够,这种略复杂的交易办法基本无人问津,可能只有在比特币更加普及之后,才可能看见多重签名技术的应用(所以说,多重签名是未来)。手动构造合同交易的案例,贴吧http://t.cn/RPUpCMz,btcman精排版http://t.cn/RPUpk7I

    +1
    +1
    我要点评
    比特暴民
    比特暴民 870 天前

    回复@放牛班差子生:比特币的普及程度不够,这种略复杂的交易办法基本无人问津,可能只有在比特币更加普及之后,才可能看见多重签名技术的应用(所以说,多重签名是未来)。手动构造合同交易的案例,贴吧,btcman精排版

    +1
    +1
    我要点评
    宏亲v杨小国
    宏亲v杨小国 870 天前

    取消关注,后会无期[拜拜]

    +1
    +1
    我要点评
    小国v耍微博
    小国v耍微博 870 天前

    取消关注,后会无期

    +1
    +1
    我要点评

    #中国好声音中国好电视#给我个机会吧我真的长那么大没中过 @街拍沙巛龙- @不要惹奴奴 @内内内小谁1983__

    +1
    +1
    我要点评
    比特暴民
    比特暴民 870 天前

    我看了很多遍也没看懂[生病]

    +1
    +1
    我要点评
    比特暴民
    比特暴民 870 天前

    我看了很多遍也没看懂

    +1
    +1
    我要点评
    亨利问
    亨利问 870 天前

    傻逼,合同是人和人之间签的,没人,你丫拿基霸构造合同啊?//@比特暴民:旧文《比特币合同》,利用指示器、锁定时间和多重签名来构造各种实用合同,可惜其中部分设想暂时受限。希望这篇115天之前翻译的,同样发表在巴比特上的文章,能让不懂装懂的家伙闭嘴。http://t.cn/8s5GGQu

    +1
    +1
    我要点评
    芯随你
    芯随你 870 天前

    祝后会无期超过当年泰囧的票房 大卖 我在新浪新闻客户端参与了#我想和韩寒谈谈#活动,有机会赢得《后会无期》电影票哦,1500张电影票正向我涌来,小伙伴们快行动吧。下载地址:http://t.cn/RPyzlXZ

    +1
    +1
    我要点评
    放牛班差子生
    放牛班差子生 870 天前

    那里能够生成,求链接

    +1
    +1
    我要点评
    campanella
    campanella 870 天前

    等下有空了好好看看//@巴比特资讯: [鼓掌]//@比特暴民: 旧文《比特币合同》,利用指示器、锁定时间和多重签名来构造各种实用合同,可惜其中部分设想暂时受限。希望这篇115天之前翻译的,同样发表在巴比特上的文章,能让不懂装懂的家伙闭嘴。 http://t.cn/8s5GGQu

    +1
    +1
    我要点评
    巴比特资讯
    巴比特资讯 870 天前

    [鼓掌]//@比特暴民: 旧文《比特币合同》,利用指示器、锁定时间和多重签名来构造各种实用合同,可惜其中部分设想暂时受限。希望这篇115天之前翻译的,同样发表在巴比特上的文章,能让不懂装懂的家伙闭嘴。 http://t.cn/8s5GGQu

    +1
    +1
    我要点评
    巴比特资讯
    巴比特资讯 870 天前

    //@比特暴民: 旧文《比特币合同》,利用指示器、锁定时间和多重签名来构造各种实用合同,可惜其中部分设想暂时受限。希望这篇115天之前翻译的,同样发表在巴比特上的文章,能让不懂装懂的家伙闭嘴。

    +1
    +1
    我要点评
    比特暴民
    比特暴民 870 天前

    旧文《比特币合同》,利用指示器、锁定时间和多重签名来构造各种实用合同,可惜其中部分设想暂时受限。希望这篇115天之前翻译的,同样发表在巴比特上的文章,能让不懂装懂的家伙闭嘴。http://t.cn/8s5GGQu

    +1
    +1
    我要点评
    Author Image
    BigChubbyCat 982 天前

    ………………译者辛苦了

    +1
    +1
    我要点评
    Author Image
    宋欢平 984 天前

    8070feb76eaba0abd0e710044f3dc4a3a2e8bffbc66c10d840c5638ef819c202
    资助0.03btc

    +1
    +1
    我要点评
    Author Image
    宋欢平 984 天前

    8070feb76eaba0abd0e710044f3dc4a3a2e8bffbc66c10d840c5638ef819c202

    +1
    +1
    我要点评
    至以
    至以 986 天前

    [威武]//@宋欢平:说要改变世界,说要挑战法币,却被一个小小媒体记者搞的团团转。我们比特粉还是too simple,too naive 。怎么样才能有免疫力?交好友,读好书,看好文!除了奥派的经济学理论,这类技术科普是最好的精神食粮。

    +1
    +1
    我要点评
    silenceAuro
    silenceAuro 987 天前

    不是你们自己胡扯么?什么挑战法币?封锁IRC、种子服务器IP和端口,我看你比特币网络怎么运转?封锁支付渠道,我看你比特币怎么用,封锁交易所,我看你比特币怎么买卖?!作为支付手段,比特币在线下交易方面对纸币毫无优势!作为货币,各国不可能放弃自身利益和调控手段,为什么许多人连位置都没认清

    +1
    +1
    我要点评