刘 鲁, 何杰杰, 田海博

1.中山大学数据科学与计算机学院, 广东省信息安全重点实验室 广州 中国510006

2.广西密码学与信息安全重点实验室, 桂林 中国541004

1.介绍

在商业活动中, 公平性是一项基础的需求。考虑一份纸质合同签署的场景, 我们希望所有的当事人坐在一起签署一份合同并且观看彼此在合同上的签名。在最后一个当事人签名之后, 从法律上来说合同生效。如果当事人尝试签一份电子合同, 那么当事人就无法观看彼此的签名过程。例如, 当Alice给Bob发送她在合同上的签名, Bob可能很轻易地就可以延迟回复, 中止合同, 或者滥用 Alice的签名。解决方法就是设计一个公平合同签署协议来强制要求当事人良好表现。

公平合同签署协议可以根据是否存在一个可信第三方机构(TTP)来进行粗略区分。早期的协议不需要 TTP, 这类协议依赖于密钥或优先级的逐步释放。例如, Alice和Bob将他们自己的密钥划分成n块, 一块块的互相交换。在交换周期内, Alice或Bob具有在一块密钥中包含的一个有限的有利条件。这类协议主要是有过早终止问题, 研究人员建议使用 TTP来解决该问题。一种明显的解决方法是使用一个在线的TTP, 当事人发送合同的签名给TTP, TTP转交当事人的签名。为了避免性能瓶颈, 研究者提出了TTP仅在当事人发生争执的时候参与的协议。这类协议被称为最优公平合同签署协议。

包含TTP的协议具有的一个基础问题就是TTP在实践中是很难实现的。这个问题在比特币区块链技术出现之后似乎是得到了解决。然而, 区块链仅仅提供了一个可信赖的账本和一个计时器, 它距离一个在公平合同签署中的TTP还差很远。例如, Asokan等人的公平交换协议[1]要求他们的 TTP始终保存一些数据并且需要执行一系列的操作去解决当事人的争执。虽然一个账本可以胜任记录数据的功能, 但是它并没有责任执行一系列的操作来解决当事人之间的争执。或许可以有一个独立的实体仅负责执行这种操作以赚取某种密码货币, 但这个时候, 这个实体已经充当了一个TTP的角色。

Rabin[2]已经提出了一种基于签名信标实现合同签署的协议。TTP每隔固定的时间间隔分发一个随机数的签名和时间戳。我们通过使用区块链技术来完成公平合同签署。

1.1 相关工作

目前已经有了很多包含或不包含TTP的合同签署的提议, 简单列举如下。

Blum[3]给出了一种基于 Rabin加密方案、交换RSA密钥参数的协议。大致来看, 只有当一个签名者知道与合同中的RSA模块相关的RSA密钥参数的时候, 签名者才可以声称这个合同是有效的。然后签名者就可以公平的交换彼此的RSA密钥参数, 来使合同签署保持公平。Even[4], Goldreich[5], Okamoto和Ohta[6], Stini和Mauve[7]也给出了一些不包含TTP的简单协议。

在线TTP通常涉及到每一次消息传输。Deng等人[8]提出了一种使用 TTP来传递电子邮件以及邮件收据的可验证公平的电子邮件协议。Franklin等人[9]雇用了一个 TTP来担保每次交易的公平性。Alawi等人[10]要求TTP记录每一个将要被签署的合同。Wan等人[11]要求一个时间戳服务提供方来为每一个合同产生时间戳。

如果在签名者之间没有产生争执的话, TTP可能是离线的。Ben-Or等人[12]介绍了一种离线的TTP来解决提前终止问题。这个问题是指如果一个当事人太早地终止协议, 其余的当事人必须无尽地等待。Asokan等人[1]当争执发生时使用TTP来复原加密的签名。Garay等人[13], Ateniese[14], Wang[15]也用了类似的方式来使用TTP。Huang等人[16]雇用了一个TTP,当争执发生的时候, TTP产生一个环签名。

我们接下来介绍两个新近的与区块链技术和合同签署相关的工作。

● Wan等人[11]提出了一种使用时间戳服务的合同签署协议。大致来看, Alice和Bob协商合同签署的最后期限, 如果两个人均在最后期限之前签名,那么合同宣称有效。Alice给合同以及最后期限签名, 并发送签名给Bob。然后Bob给合同、最后期限以及 Alice的签名进行签名, 并且发送Bob的签名给时间戳服务方。时间戳服务方鉴定Alice和 Bob签名的有效性, 然后给合同一个时间戳。假设合同可以被部署在一个比特币的区块上, 那么他们的时间戳服务可以利用区块链技术来实现。

● Kiayias等人[17]提出了一种使用全局交易账本的多方计算协议。他们的模型包括一个全局的时钟函数和一个账本函数。他们的账本扩展了比特币系统的函数以处理任意的函数。通过这些扩展,他们给出了一个编译器来将任何一个多方计算协议转化为一个具有公平性和鲁棒性的安全协议。既然一个合同签署协议可以被当作一个特殊的多方安全协议, 那么他们的方法也提供了一种使用扩展的比特币系统来进行合同签署的通用方法。

1.2 贡献

我们提出了一种使用当前的比特币等区块链系统而不需要任何扩展的合同签署协议。比特币系统是一个包括数千个节点的分布式计算系统。该系统的任何修改都需要大部分节点的同意。当前出现的比特币分支系统足以说明这种社区共识是很难达成的。而我们的系统不需要修改任何底层区块链技术,无需社区的任何共识。

另外, 目前的比特币, 以太坊等系统的代币都具有较高的价格, 这使得矿工费持续升高, 进而使得比特币交易或者以太坊交易必须能够获取远超过矿工费的收益时才会发生。这使得部署在比特币或者以太坊上的应用成为很少有人运行的应用。我们的系统只是把区块链作为随机数和时钟源头, 并不需要生成新的交易, 缴纳矿工费。

从技术上来说, 假设哈希值的任意一部分是均匀分布的。我们从区块头的哈希值中取出一部分作为随机数, 使用区块的高度和区块的时间戳作为计时器。这个随机数和定时器取代了在Rabin的合同签署协议中的签名信标[2]。合同签署的基本思想和Rabin协议是相同的。首先给一个可能有效的合同签名, 然后等待一个可信赖的事件来确认或者废除这个合同的合法性。不同之处在于我们的可信赖的事件是发生在区块链系统中一个新块出现的时候。然后我们添加参数来增加签订合同的时间和可能的合同数量。我们还对不同参数集的预期执行时间进行了估计, 并给出了一些实际的结果。

2.引言

我们的工作仅仅需要区块头的时间戳, 区块的高度, 区块头的哈希值。我们按照文献[18,19]中惯例来描述这些参数。

2.1 时间戳和区块高度

对于比特币区块链, 一个区块头包含80字节。前 4个字节是区块的版本号, 指明了要遵循的块验证的规则集。接下来的32个字节是前一个区块头的哈希值。这是一个 SHA256(SHA256())的哈希输出。之后的 32字节也是一个 SHA256(SHA256())的哈希输出, 表示该块中包含的所有交易的哈希值的默克尔根。接下来的 4个字节是时间戳。区块的时间是矿工开始对块头做哈希时的Unix时间戳。它要求这个时间戳必须要比前十一个区块的中位时间大或者相等。一个完整的节点将不会接受一个超过两个小时的区块。接下来的两个字段占据了8个字节, 指明了当前区块的目标, 挖矿的目的是生成一个比该目标小的哈希值。

需要注意的是, 区块中的时间戳是在本地取样的。当取样结束以后, 取样结果不应该小于前十一个区块的中位时间。也就是说, 由于这种本地取样的操作, 一个区块的时间戳理论上来说是有可能小于前一个区块的时间戳的。如果有一个可信赖的全局时钟, 那么这种情况将不会发生, 毕竟区块是一个接一个地产生的。这说明了区块链时间戳与全局时钟的不同。

区块的高度指的是在此区块与第一个区块之间所含有的区块数目。第一个区块一般被看作是创世区块, 其高度为0。当两个或者多个矿工几乎在同时生成了自己的区块时, 多个区块可以有相同的区块高度。一个人可以使用在“blockchain.info”网站中的“getblockcount”方法来获取最后一个区块的高度。我们仅仅考虑最长的链, 与区块的时间戳相比, 区块高度更为可靠的提供给我们一个间隔可变的计时器。

2.2 区块头的哈希值

当一个矿工找到了一个小于目标的区块头哈希值时, 一个新的区块就诞生了。这个哈希值利用SHA256(SHA256())算法来计算。我们给出了一个使用#125552号区块的头部来计算哈希值的 python代码样例。

'1dbd981fe6985776b644b173a4d0385ddc1aa2a82 9688dle0000000000000000'是一个采用小端模式存储的值。它的逆序是一个采用大端模式的值。大部分比特币客户端和网站是用大端模式来显示的区块头部哈希值。在本篇文章中我们也使用大端模式。例如, 当我们说在#125552号区块头部哈希值的最后十位时, 我们的意思是指 0100011101, 或者是十六进制形式0x11d。

3.协议

本节内容中包含 3个协议, 其中最后一个是最灵活的。

3.1 基本协议

Rabin[2]提出了一种包含签名信标的合同签署协议。这个签名信标以固定的时间间隔签名并且广播出一个随机数和一个时间戳。签名者首先声明“如果这个有一个随机数和一个时间戳的合同已经被签名者签署了, 并且这个随机数和时间戳也被签名信标签署了, 那么合同有效”。然后合同的签名者交换他们自己的随机数, 并且对随机数的加和值进行签名。这个随机数的加和值被作为对签名信标下一个签名的随机数的猜测。如果这个猜测是正确的, 那么所有合同的签名者就都得到了一份有效的合同。如果猜测是错误的, 那么他们重复以上过程直到猜测正确。这个随机数的范围是[1,k]。假设这个时间间隔是Δ, 这个协议预期的执行时间就是kΔ。

在区块链中, 每一个区块都有区块高度, 区块头的哈希值和本地采样的时间戳。比特币区块链的两个连续的区块之间的时间间隔大约是10分钟。这个哈希值是采用密码安全的哈希函数计算出的, 使用大端模式表示。哈希值的后log2k位应该具有良好的随机性。任何一个人可以使用公开的比特币系统的 API来获取最后一个区块的高度, 时间戳以及哈希值。

我们把签名信标的随机数用大端模式的哈希值的最后log2k位来代替。同时把签名信标的时间戳用区块的高度和时间戳来代替。然后我们得到了一个基于区块链的签名信标。信标的广播用新区块的生成和广播替换。

合同用类似文献[2]中的方式来签署。Alice和Bob讨论一个合同C。他们采用了基于区块链的签名信标。信标信息以M=(r,i,t,f)的形式出现, 这里的r是预测区块头部哈希值的最后log2k位, i和t是合同签署时区块的高度和时间戳, f是一个间隔因子来增加可能的有效区块的数量。大致上来说, Alice和Bob会在一个时间戳为 t, 高度为 i的区块出现之后开始签署合同。在接下来的f个区块中, 如果有一个区块头部哈希值的最后log2k位等于 r, 这个合同就生成了。

详细来说, Alice发送给Bob一个Alice签署的初步的签名协议PAA。初步协议PAA是“如果Bob可以给出一个被Alice签过名的(C,M), 并且M可以链接到区块链的一个部分, 这个部分的起始区块包含时间戳t并且此区块的高度是i, 而且在接下来的f个区块中, 存在一个区块的头部哈希值用大端模式表示的时候最后log2k位等于r, Alice就承认合同C是在M中提到的t时间后签署的有效合同”。Bob也会发送一个类似的签过名的初步协议PAB给Alice来完成初步阶段。

Alice和 Bob执行协议的情况是相同的。Alice的协议如下:

1.Alice读出最新区块的高度bℎA,发送PAA和bℎA给Bob, 并且打开一个Δ/6的定时器。

2.在Alice收到Bob发来的PAB和区块高度bℎB之后, 她清除之前的定时器。之后她等待高度是max(bℎA,bℎB)+1的区块出现。

3.Alice读出新区块的时间戳t和区块高度i。然后她读出本地的时间t0, 计算时间差td=t0−t。如果td的绝对值是可接受的, Alice 将任选rAϵ｛1,…,k｝,发送rA给 Bob, 并且打开一个Δ/6的定时器。否则,Alice终止。

4.当Alice收到Bob发来的rB, Alice清除之前的定时器并且计算r=rA+rBmod k, 生成M=(r,i,t,f),签名SigA=SignA(C,M)。Alice发送SigA给Bob, 并且打开一个Δ/3的定时器。

5.当Alice收到Bob发来的SigB, 她清除之前的定时器, 等待f个区块, 直到有一个区块可以使合同合法。如果没有这样的区块, 那么Alice在一个新区块出现的时候从步骤3重新开始执行这个协议。

6.在任何一个步骤中, 如果定时器超时的情况发生, Alice终止。

注意在比特币系统中的时间戳是由矿工在本地取样得到的, 理论上来说允许一个区块的时间戳比前一个区块的小。因此我们设置一个变量td来记录区块时间戳之间的时间差和一个签名者的本地时间。一个签名者应该检验td是足够小的。

3.2 延迟起始区块

上述的基础协议隐式地假定区块的间隔足够长以来完成交易。通过在信标信息M中增加一个延时因子d, 我们可以去掉这个假设。大致上来说, Alice和Bob可以在时间dΔ内交换他们的信息。现在Alice的初步协议PAA是“如果如果 Bob可以生成一个被Alice签过名的(C,M), 并且 M 可以链接到区块链的一个部分, 这个部分的起始区块是包含时间戳t并且区块高度是i的区块的后面第d个区块, 而且在接下来的f个区块中, 存在一个区块的头部哈希值用大端模式表示的时候最后log2k位等于 r, Alice就承认合同C是在M中提到的t时间后签署的有效合同”。

现在Alice的协议如下。

1.Alice读出最新区块的高度bℎA,发送PAA和bℎA给Bob, 并且打开一个dΔ/6的定时器。

2.在Alice收到Bob发来的PAB和区块高度bℎB之后, 她清除之前的定时器。之后她等待高度是max(bℎA,bℎB)+1的区块出现。

3.Alice读出新区块的时间戳t和区块高度i。然后她读出本地的时间t0, 计算时间差td=t0−t。如果td的绝对值是可接受的, Alice 将任选rAϵ｛1,…,k｝,发送rA给 Bob, 并且打开一个dΔ/6的定时器。否则,Alice终止。

4.当Alice收到Bob发来的rB, Alice清除之前的定时器并且计算r=rA+rBmod k, 生成M=(r,i,t,d,f),签名SigA=SignA(C,M)。Alice 发送SigA给Bob, 并且打开一个dΔ/3的定时器。

5.当Alice收到Bob发来的SigB, 她清除之前的定时器, 等待i+d个区块。当第i+d个区块出现之后, Alice再等待f个区块, 直到有一个区块可以使合同合法。如果没有这样的区块, 那么Alice在一个新区块出现的时候从步骤3重新开始执行这个协议。

6.在任何一个步骤中, 如果定时器超时的情况发生, Alice终止。

3.3 增加成功率

在以上的协议中的参数 f可以增加生成一个有效合同的成功率。例如, 如果k=32,f=16, 成功率大约是 1/2。然而, 这是有代价的。首先是公平性。如果Alice发送一个可能的合同给Bob然后Bob终止了, Bob有1/2的机会来使合同合法。其次是执行时间。更大的f意味着更长的执行时间。

我们给出了另外一个方法来增加成功率。大致上来说, Alice和Bob可以用不同的随机数连续签署多个可能成功的合同。初步协议和延迟起始区块的版本是相同的。Alice的协议生成了一个新的参数 b来指明交换的合同签名的额外数量。在新的协议中采用了一个安全的哈希函数hash。Alice的协议如下。

1.Alice读出最新区块的高度bℎA,发送PAA和bℎA给Bob, 并且打开一个dΔ/2(2b+3)的定时器。

2.在Alice收到Bob发来的PAB和区块高度bℎB之后, 她清除之前的定时器。之后她等待高度是max(bℎA,bℎB)+1的区块出现。

3.Alice读出新区块的时间戳t和区块高度i。然后她读出本地的时间t0, 计算时间差td=t0−t。如果td的绝对值是可接受的, Alice 将任选rAϵ｛1,…,k｝,发送rA给Bob, 并且打开一个dΔ/2(2b+3)的定时器。否则, Alice终止。

4.当Alice收到Bob发来的rB, Alice清除之前的定时器并且计算r=rA+rBmod k, 生成M=(r,i,t,d,f),签名SigA=SignA(C,M)。Alice 发送SigA给Bob, 并且打开一个dΔ/(2b+3)的定时器。

5.当Alice收到Bob发来的SigB, 她清除之前的定时器并且重复下列操作b次:

(a) Alice计算 hash(r)来更新 r, 生成M=(r,i,t,d,f),签名SigA=SignA(C,M)。Alice 发送SigA给Bob, 并且打开一个dΔ/(2b+3)的定时器。

(b) 当Alice收到Bob发来的SigB, 她清除之前的定时器。

6.在第i+d个区块出现之后, Alice再等待f个区块, 直到有一个区块可以使这b+1个合同中的一个合法。如果没有这样的区块, 那么Alice在一个新区块出现的时候从步骤3重新开始执行这个协议。

7.在任何一个步骤中, 如果定时器超时的情况发生, Alice终止。

3.4 协议分析

这个协议假定哈希的输出是均匀分布的。我们接下来按照文献[2]的思路, 分析最后一个协议的安全性。

定理1.假设哈希输出是均匀分布的。如果Alice和 Bob遵循他们各自的协议, 在预期执行时间k(d+f)Δ/f(b+1)之后, 每个人都有另外一个人合同的签名。如果Alice遵循她的协议, Bob尝试去欺骗她, Bob得到Alice 合同签名并且Alice没有Bob的签名的概率是f/k。Bob被欺骗的概率类似。

证明.假设Alice和Bob在区块高度为i的区块出现的时候开始他们的协议。在区块高度为i+d的区块出现之后, 他们的必须已经分别交换了b+1个签名SigA和SigB。对每一组签名对SigA和SigB, 都存在一个随机数rϵ｛1,…,k｝。因为我们假定哈希值是具有任意性的, 我们可以认为每个 r都是在集合｛1,…,k｝上均匀分布的。在i+d+f区块出现之后,存在最多f个区块头。由于假定的随机性, 区块头部哈希值的最后log2k位有(b+1)/k的机会与b+1个随机数中的一个相等。因为我们考虑了 f个区块头,所以一个合法合同出现的概率就是f(b+1)/k。因此这个协议将在预期执行时间k(d+f)Δ=f(b+1)之内终止。

当协议终止, Alice和Bob可能有最多f个合同是同时合法的。他们可以在这其中选择一个作为他们自己最终的合法合同。如果争执发生了, 也就是说,Alice否认曾经签署过这份合同, Bob就可以起诉她并且证明她是签过的。也就是说, Bob将给出一个初步协议PAA和签名信息SigA。法官需要验证这个签名SigA和PAA中的签名。如果这两个签名都得到了验证,那么这个法官就去检查区块链, 核实PAA中的条件。也就是, M中的时间戳t是被包含在区块高度为M中的 i的区块中的, 并且在第i+d个区块与第i+d+f+1个区块之中存在一个区块头部哈希值的最后log2k位等于M中的r值。如果所有的条件都满足了,那么Alice就是签署过这个合同。

现在假设Alice遵循了她的协议, 但是Bob没有在dΔ/(2b+3)时间之内回复。Alice将终止协议。假设Alice已经收到了Bob发来的j个签名。然后Bob已经收到了Alice发来的j+1个签名。这j个签名对可能可以同时使合同合法。Bob对于Alice来说唯一的有利条件就是一个Alice发来的额外的可以使合同合法的签名, 合法的可能性是f/k。有1−f/k的概率是Bob并没有有利条件。

Alice和Bob在协议中的角色是完全对等的, 因此上述分析也适用于Bob被欺骗的概率。

3.5 协议实例

我们给出一些最终版协议的实例。首先, 我们令d=1,Δ=10分钟, b=0,f=1,k=1024。然后交换签名的时间间隔大约是3分钟。Alice和Bob有1/1024的概率需要大约20分钟来签署合同。完成协议的预期执行时间是两个星期。注意我们没有考虑交换他们合法合同的时间, 因为这个交换只发生一次。

然后, 我们令d=10,Δ=10分钟, b=49,f=2,k=1024。然后交换签名的时间间隔大约是1分钟。Alice和Bob有1/10的概率需要大约两个小时来签署合同。完成协议的预期执行时间是二十个小时。如果网络延迟是很小的, 我们可以使用更为乐观的参数。例如, b=499, 交换签名的时间间隔大约是 6秒。理论上来说, 在两个小时以内, 一个合法合同出现的概率是0.75。

在实践中, 我们使用比特币区块的原始数据来签署合同。当一个合同将要被签名时, 我们令k=1024,b=499,f=2。这个随机数rA和rB是由C++中的默认函数“rand()”生成的。我们使用 SHA256()函数来生成不同随机数的链。我们选择一个任意的区块作为起始区块来签署 100次合同。如果一个随机数在两个区块中都被发现了, 那么有效的合同产生了。我们用不同的起始区块重复 20次,结果在表1中。当这个起始区块是#80号区块时,在100协议执行的过程中生成了81份有效的合同。当这个起始区块是#180号区块时, 成功率是 0.64。在这2000次执行中签名合同总体的成功率大约是0.72。

表1 采用不同的起始区块时有效合同的数量Table 1 Number of valid contracts with different beginning block

4 结论

我们展示了如何使用当前的比特币区块链系统来设计一个公平合同签署协议。它不需要缴纳矿工费。同样的思路可以很扩展到以太坊等区块链系统中。特别的, 以太坊的区块时间大约是15秒, 与比特币的大约10分钟相比, 出块速度快了将近40倍。这意味着我们的协议效率还有提升的空间。

[1]N.Asokan, V.Shoup and M.Waidner, “Optimistic fair exchange of digital signatures,” IEEE Journal on Selected Areas in Communications, vol.18, no.4, pp.593-610, 2000.

[2]M.O.Rabin, “Transaction protection by beacons,” Journal of Computer and System Sciences, vol.27, no.2, pp.256-267, 1983.

[3]M.Blum, “How to exchange (secret) keys,” Proceedings of the fifteenth annual ACM symposium on Theory of computing, Victoria,British Columbia, pp.440-447, 1983.

[4]S.Even, “A protocol for signing contracts,” SIGACT News, vol.15, no.1, pp.34-39, 1983.

[5]O.Goldreich, “Simple Protocol for Signing Contracts,” dvances in Cryptology: Proceedings of Crypto 83, California, USA, pp.133-136, 1984.

[6]T.Okamoto and K.Ohta, “How to simultaneously exchange secrets by general assumptions,” Proceedings of the 2nd ACM Conference on Computer and communications security, VA, USA, pp.184-192, 1994.

[7]M.Stini and M.Mauve, “Enabling fair offline trading,” Proceedings of the 2009 International Conference on Wireless Communications and Mobile Computing: Connecting the World Wirelessly,NY, USA, pp.973-978, 2009.

[8]R.H.Deng, L.Gong, A.A.Lazar and W.Wang, “Practical protocols for certified electronic mail,” Journal of Network and Systems Management, vol.4, no.3, pp.279-297, 1996.

[9]M.K.Franklin and M.K.Reiter, “Fair exchange with a semi-trusted third party (extended abstract),” Proceedings of the 4th ACM conference on Computer and communications security,Arizona, USA, pp.1-5, 1997.

[10]A.A.Al-Saggaf and L.Ghouti, “Efficient abuse-free fair contract-signing protocol based on an ordinary crisp commitment scheme,” IET Information Security, vol.9, no.1, pp.50-58, 2015.

[11]Z.Wan, R.H.Deng and D.Lee, “Electronic Contract Signing Without Using Trusted Third Party,” Network and System Security:9th International Conference, NSS 2015, NY, USA, pp.386-394,2015.

[12]M.Ben-Or, O.Goldreich, S.Micali and R.L.Rivest, “A fair protocol for signing contracts,” IEEE Transactions on Information Theory, vol.36, no.1, pp.40-46, 1990.

[13]J.A.Garay, M.Jakobsson and P.MacKenzie, “Abuse-Free Optimistic Contract Signing,” Advances in Cryptology - CRYPTO’ 99:19th Annual International Cryptology Conference, California, USA,pp.449-466, 1999.

[14]G.Ateniese, “Verifiable encryption of digital signatures and applications,” ACM Trans.Inf.Syst.Secur., vol.7, no.1, pp.1-20,2004.

[15]G.Wang, “An Abuse-Free Fair Contract-Signing Protocol Based on the RSA Signature,” IEEE Transactions on Information Forensics and Security, vol.5, no.1, pp.158-168, 2010.

[16]Q.Huang, G.Yang, D.S.Wong and W.Susilo, “Efficient Optimistic Fair Exchange Secure in the Multi-user Setting and Chosen-Key Model without Random Oracles,” Topics in Cryptology -CT-RSA 2008: The Cryptographers’ Track at the RSA Conference 2008, CA, USA, pp.106-120, 2008.

[17]A.Kiayias, H.S.Zhou and V.Zikas, “Fair and Robust Multi-party Computation Using a Global Transaction Ledger,” Advances in Cryptology - EUROCRYPT 2016: 35th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Vienna, Austria, pp.705-734, 2016.

[18]“Bitcoin developer reference,” https://bitcoin.org/en/developer- reference#blockchain, 25 June.2016.

[19]“Block hashing algorithm,” https://en.bitcoin.it/wiki/Block hashing algorithm., 25 June.2016.