[0087] (Sstop-n*s)≥s。
[0088] 图1的交易Tc和Tr,n是出现在区块链上的交易。
[0089] 图9示出了包括构建Alice和Bob之间的支付渠道所涉及的步骤的
流程图。
[0090] 原子交叉链交易
[0091] 对于数字交换,“公平交换”协议通常是必要的。该交换表示一个场景,其中,一个用户UserA拥有一个值x,并希望将其交换为UserB拥有的值y。公平交换协议允许两个用户:(i)承兑和交换;或者(ii)既不承兑也不交换。在Even,S.和Yacobi,Y.,1980,Relations among public key signature systems(第268卷)。以色列,海法,以色列理工,技术报告
175(http://ftp.cs.technion.ac.il/users/wwwb/cgi-bin/tr-get.cgi/1980/CS/CS0175.pdf)中,表明如果没有可信的第三方,确定的公平交换是不可能的。
[0092] 以ACCT为例,其作者为两个用户设计了一个公平的交换协议,以在不同的加密货币之间交换硬币。对于他们的解决方案,加密货币的区块链充当可信任的第三方。ACCT的算法如图2所示,其中,Alice A向Bob B支付w BTC,以换取v个替代币。
[0093] 这就是ACCT(超时)。如果
进程停止,则无论何时停止都可以将其逆转。
[0094] 参考图2,下面是用户A和B使用ACCT期间事件的示例
时间线:
[0095] 在1)之前:任何公共的事情都没有被广播,所以什么都没发生;
[0096] 在1)和2)之间:A可以在72小时后使用退款交易来取回他的钱;
[0097] 在2)和3)之间:B可以在24小时后拿到退款,A还需要再过24小时才可以拿到退款;
[0098] 在3)之后:由2)完成交易,
[0099] -A必须在24小时内用完他的新硬币,否则B可以要求退款并保留他的硬币;
[0100] -B必须在72小时内用完他的新硬币,否则A可以要求退款并保留他的硬币。
[0101] 为了安全起见,A和B双方都应该在离截止日期还有大量时间前完成这个过程。
[0102] 组随机交换
[0103] 本发明涉及一种组随机交换(GRE)协议。其提供了在一组n个用户中交换比特币的解决方案,其中,n>2。该组中的每个用户都可以用其拥有的一定数量的比特币来交换相同数量的比特币。
[0104] 然而,如果不改变协议,两个用户之间交换的比特币数量可能不相等。Ui和U(i+1)mod n之间交换的值可以是这对用户之间能够协商的任何值。
[0105] 假设x BTC是交换的约定金额,如果所有受影响的用户都希望如此,一个用户可以支付(x+a)BTC,而另一用户也可以收回(x-b)BTC。例如,用户U1具有10BTC用于交换。如果8BTC是U1能得到的最好的报价,则U1愿意接受用户U0提供的8BTC。U1这样做的同时也明白,另一用户U2可能会坚持接收10BTC。换言之,U1支付的值不一定是U1被支付的值,如果并且也只有U1接受这些条款,U1支付的值可能是U1被支付的值(如果U1坚持的话)。
[0106] 从此处开始,为便于说明,描述仅限于每个用户支付和被支付x BTC的场景。
[0107] 此外,用户可以在协议内交换代币。代币根据与代币相关联的智能合约表示资产或资源,以使对代币的控制提供对资产或资源的控制。
[0108] 假设忽略交易
费用(交易费用是与每个比特币交易相关的成本),用户拥有的比特币的净变化在参与交易协议后不会改变。假设第一用户是用户A,用户A支付给用户B x BTC,用户C支付给用户Ax BTC,其中,用户B与用户C不是同一用户。此外,每个用户具有与发送支付相关联的源地址和与接收支付相关联的接收地址,其中,源地址和接收地址不同。然而,通过参与协议,存储在
比特币地址的用户的比特币现在实际上被转移到同一用户拥有或控制的另一地址。由于交换协议的过程,比特币在地址间的转移是以在分析区块链时掩盖资金转移的方式完成的。
[0109] GRE协议与ACCT的不同之处在于,ACCT仅概述了一对用户之间的相互交换,而GRE协议描述了一种交换,其中:
[0110] ·有2个以上的用户;以及
[0111] ·在被支付和支付的过程中,第一用户支付的第二用户不是第一用户从其接收支付的用户。
[0112] GRE协议通过以下方式实现这一点:
[0113] ·该协议的用户没有丢失比特币的风险;以及
[0114] ·第一用户支付的第二用户是随机的,支付第一用户的用户也是随机的。
[0115] 第一类型的组随机交换-秘密值
[0116] 组随机交换协议以两种方式中的一种操作,每种方式都体现了本发明。现在将描述本发明的配置。
[0117] 考虑到参与本发明配置的GRE协议的一组n个用户Ui|i∈[0,n-1]要交换x BTC,该协议以以下方式操作:
[0118] ·用户被随机化,以实现有序集合{U0,U1,…,Un-2,Un-1};
[0119] ·其中一个用户被认为是‘发起者’或‘发起用户’。出于我们的目的,U0被认为是发起者;
[0120] ·发起者U0选择一个随机数k并计算H(k),其中,H(·)表示确定性散列函数;
[0121] ·k的值由U0私有,但H(k)的值被分发给参与GRE协议的所有用户;
[0122] ·选择时间值s,该时间值表示提供给每个用户Ui的时间量,以构建支付渠道Ui→U(i+1)mod n,提取k值以及向比特币网络提交支付给用户U(i+1)mod n的执行交易Tpay。考虑到其他用户的一致意见,组中的任何用户都可以选择时间s。在一个优选实施例中,发起者选择s来简化协议。时间s以秒或区块数表示;
[0123] ·选择另一值S作为提交给比特币网络的用户第一笔支付的开始时间。考虑到其他用户的一致意见,组中的任何用户都可以选择S。在一个优选实施例中,发起者选择S来简化协议。注意,S表示在Unix时间或区块高度中指定的时间点,而s表示时间跨度;
[0124] ·在每对用户之间建立单向支付渠道,其中,支付方向是用户Ui支付用户U(i+1)mod n(本文由Ui→U(i+1)mod n表示)。例如,假设n=7,GRE的支付渠道将包括U0→U1,U1→U2,…,U6→U0。
[0125] ·创建支付渠道Ui→U(i+1)mod n的过程如图3和10所示,其中,σ(Ui)表示Ui的签名:
[0126] ο初始承诺交易Tc使可用的x BTC只能通过提供以下任一项来花费:(i)Ui和U(i+1)mod n的签名;或者(ii)k和U(i+1)mod n的签名(参考图6);
[0127] ο此处只需要一个退款交易:退款函数Tr,0,将所有x BTC返回给Ui(参考图7);
[0128] ο退款交易Tr,0包含nLockTime值S+(n-i)s;
[0129] ο退款交易Tr,0必须在初始承诺交易Tc被提交给比特币网络之前由U(i+1)mod n签署;
[0130] ο支付渠道包含支付交易Tpay,其从Tc承诺的x BTC向U(i+1)mod n支付xBTC;以及[0131] ο支付交易Tpay到U(i+1)mod n的内包含值k(参考图8);
[0132] ·以有序的顺序创建用户对之间的支付渠道是很重要的,因为支付渠道Ui-1→Ui是在支付渠道Ui→U(i+1)mod n之前被创建的。这从创建第一支付渠道U0→U1开始,其中,U0是发起者,并以最后一个支付渠道Un-1→U0结束。图4示出了支付渠道的构建顺序。
[0133] 在某些配置中,序列的顺序很重要,因为这使得用户Ui在冒险付款之前确保:
[0134] ·存在到Ui的Tpay交易,只需要Ui知道k,就可以让交易Tpay被比特币网络接受;以及[0135] ·在支付渠道Ui→U(i+1)mod n(Ui花费)的Tpay中发现的标准与支付渠道Ui-1→Ui(Ui接收)的Tpay相同。
[0136] 只有发起者U0不必在支付之前优先接收。然而,不能U0被骗,因为U0是唯一知道k值的用户。因此,在U0能够舒适地开始该过程(与其发布k值的时间一致)前,GRE协议中的任何人都不能执行撤销操作。
[0137] 为GRE实例创建一组Ui→U(i+1)mod n支付渠道的过程如图11所示。
[0138] 假设最终支付渠道Un-1→U0在时间S或之前完成。一旦该最终支付渠道构建完成,可以说连接协议的所有用户的交易的链或交易链也已经完成。
[0139] 图5示出了GRE协议的所有用户之间存在的Ui→U(i+1)mod n支付渠道的表示。箭头表示支付渠道和Tpay支付的方向。箭头外部相邻的表达式表示区块链可接受的交易Tpay标准。注意,σ(Ui)表示Ui的签名。箭头内部相邻的表达式表示s时间跨度值。
[0140] 鉴于循环设置,Ui|i∈[0,n-1]的顺序是随机的,这意味着支付用户Ui和由用户Ui支付的用户都是随机的。此外,支付用户Ui和由用户Ui支付的人是不同的。
[0141] 发起者U0花费现有支付渠道Un-1→U0的交易Tpay,披露k的值。U0可以将k的值直接传送给Un-1,或者可以从区块链中提取该值。
[0142] 类似地,每个用户Ui可以直接将值k传送给其付款人Ui-1。如果Ui没有传送,则用户Ui-1可以在
区块链账本中找到该值(至少在时间s内)。
[0143] 由于区块链在提交此
申请时平均需要10分钟来确认交易,因此s的值应该选择为使得其所表示的时间段足以在交易Tpay提交给比特币网络之后,让任何用户Ui在该时间段内找到(如果必要的话)该交易Tpay(支付渠道Ui→U(i+1)modn)中的k值。s的值还应包括一对用户之间构建支付渠道的估计时间。因此,s可以被选择为s=sk+ε,其中,sk是找到k并提交Tpay的估计时间,ε是构建支付渠道的估计时间。
[0144] 由于发起用户U0现在已经向网络提交了Un-1和U0之间现有支付渠道的Tpay交易,向Un-1披露了k的值,然后k的值才可以以相反的顺序方式(从Un-1到U2)披露给每个其他用户Ui。这是基于一个前提,即每个用户Ui将投资于提交交易(支付渠道Ui-1到Ui的Tpay),以使他们自己获得支付。提交上述交易的用户Ui将需要从支付渠道Ui到Ui+1的Tpay(之前已经可用)获得k值。通过Ui提交支付渠道Ui-1到Ui的交易Tpay,用户Ui-1随后可获得K值。这个过程从Un-1一直级联到U1,这样兑现的每个用户Ui向用户Ui-1披露k,从而使得用户Ui-1也兑现。
[0145] 更正式地,执行支付渠道的Tpay交易的提交顺序如下:
[0146] [Tpay:Un-1→U0,[Tpay:Un-2→Un-1],…,[Tpay:U1→U2],[Tpay:U0→U1][0147] 这组Tpay交易的完成成功结束了GRE。每个用户支付了x BTC,每个用户接收了x BTC。
[0148] 提交一个GRE实例的Tpay:Un-1→U(i+1)mod n交易的过程如图12所示。
[0149] 下面,描述在一对用户之间的支付渠道Ui→U(i+1)mod n中使用的比特币交易的结构。这些支付渠道包括三个主要交易:
[0150] ·存入2对2多重签名交易Tc:该交易表示支付渠道的承诺部分,可称为承诺交易。在此处,通过交易,用户Ui发送/提交指定数量的比特币x BTC,由以下任一个管理:
[0151] ο2对2多重签名(Ui,U(i+1)mod n)
[0152] 或者
[0153] ο对k值的知晓和U(i+1)mod n的签名;
[0154] ·退款交易Tr,0:该交易表示在指定时间到期后将x BTC(从承诺交易)退还给用户Ui。要成功执行该交易,需要用户Ui和U(i+1)mod n的签名;
[0155] 以及
[0156] ·支付交易Tpay:该交易是Ui向U(i+1)mod n支付x BTC。要成功执行该交易,需要对k值的知晓和U(i+1)mod n的签名。支付交易也可称为执行交易。
[0157] 注意,虽然交易的详细信息仅限于各种交易的、、nLockTime和输出值,因为这些与所描述的GRE协议最相关,也可以使用其他函数和值。
[0158] 第二类型的组随机交换-改变秘密
[0159] 现在将描述本发明的进一步配置。
[0160] 针对上述配置的GRE协议的情况,对于每个支付渠道都通用的k值可以作为GRE可向其用户提供的匿名级别的限制。这是因为k和/或其散列值H(k)的共享使用使得外部观察者更容易将GRE的特定实例中涉及的一组交易关联起来。这减少了观察者追踪用户从一个地址到另一地址的资金转移所需的工作量。
[0161] 与上述在所有支付渠道中使用相同秘密值的配置相反,下面描述的配置在GRE交换中对每个支付渠道使用不同的秘密值。此外,尽管每个渠道的秘密值不同,但是当交易被提交给区块链时,披露秘密值为序列的下一个支付渠道中秘密值的后续披露提供了足够的信息。
[0162] 为了实现这一功能,这种配置利用椭圆曲线(EC)密码的特性,使得E(m)+E(n)=E(m+n);其中,E(x)=xG,G是椭圆曲线上的基点。然而,具有基本类似同态性质的其他类型的加密可以用来代替EC加密。
[0163] 椭圆曲线是由以下等式描述的一组点:
[0164] y2≡x3+ax+b(mod p);
[0165] 其中, (mod p)和p是质数。
[0166] 比特币脚本中所需的EC算术功能是点乘标量。也就是这样的操作:
[0167]
[0168] 其中,n是自然数,P是椭圆曲线上的一个点,而+是EC上点的加法运算符。
[0169] 标量乘法反过来需要特定的EC组运算点加和点倍增:
[0170] ·点加P+Q:通过这个运算,我们计算出EC上的一个新点,作为曲线交点的非。这可以描述为R=P+Q,
[0171] ·点倍增P+P:使用点加,我们可以计算出P的点倍增。这可以描述为R=P+P=2P。
[0172] 更具体地,给定EC上的两点,即,P(x1,y1)和Q(x2,y2):
[0173] P+Q=(x3,y3);其中:
[0174] x3=m2–x1–x2mod p;
[0175] y3=m(x1–x3)–y1mod p;以及
[0176]
[0177] 如上所述,使用k值(和其后的H(k))作为配置的GRE
电路中每个支付渠道的标准,该配置的GRE电路在所有支付渠道中使用相同秘密值的,这可能被证明是一种限制,因为这涉及匿名性的要求。
[0178] 如果用户希望在GRE交换中匿名,因为这与用户的比特币转移有关,那么U1支付x BTC的地址与用户接收x BTC的地址不同是可以预料到的。地址之间的这种分离意味着比特币区块链的支付和收款交易彼此分离。
[0179] 然而,了解GRE协议的外部观察者会知道,带有包含一种标准的脚本的比特币交易是GRE实例的人工产物。此外,由于k和它的散列是在这些GRE实例的子集内找到的,因此外部观察者将能够识别与GRE的特定实例相关的所有交易,或者至少显著减小这组可能交易的大小。虽然不能保证成功,但这使得外部观察者能够更好地跟踪GRE实例中比特币的移动。
[0180] 这种配置使用GRE协议,其中,每个支付渠道使用不同的唯一秘密值(sv)和相应加密版本的秘密值。应当注意,在这种配置中,散列函数本身没有被使用,而是被EC加密代替。这降低了外部观察者识别属于特定GRE实例的一组交易的能力。
[0181] 该配置的不同秘密值预期满足以下条件:
[0182] a.秘密值应该是很难猜测出来的;
[0183] b.在执行支付渠道Ui→U(i+1)mod n的TPay时对sv(i+1)mod n的披露应该使得GRE序列Ui-1→Ui(逆
时针)中下一个支付渠道的sv1被披露或至少是易于计算的;
[0184] c.外部观察者应当很难识别密钥(或密钥加密(密文))之间的关系;以及[0185] d.交换中的用户不应有失去资金的风险。
[0186] 可以使用EC加密作为散列函数的替代来满足先前的标准。对于EC加密,标量值乘以EC上的基点G。标量值k是密钥,Q=kG是加密输出。从Q中确定k是一个‘困难的’离散对数问题。
[0187] 此外,对于椭圆曲线算术的加法运算符,对于基点G,mG+nG=(m+n)G
[0188] EC密码的这一特性允许在条件b下依次披露另一秘密值。
[0189] 考虑到一组n个用户{U1|i∈[0,n–1]}参与交换x个BTC的GRE协议,本发明的这种配置的协议以以下方式操作。
[0190] ·用户对椭圆曲线数字签名算法(ECDSA)曲线的参数(p,a,b,G,n,h)达成一致。例如,secp256k1;
[0191] ·用户被随机化,以实现有序集合{U0,U1,…,Un-2,Un-2};
[0192] ·其中一个用户被认为是‘发起者’。出于我们的目的,U0被认为是发起者;
[0193] ·发起者U0选择一个随机数ks并计算ksG,其中,G表示椭圆曲线上的基点;
[0194] ·ks值由U0私有;
[0195] ·其他用户U1到Un-1中的每一个都选择一个随机数。U1选择k1,U2选择k2,…,Un-1选择kn-1。这些其他用户中的每一个都安全地将他们选择的值发送到U0。U0也选择一个第二随机数k0。
[0196] ·选择时间值s,该时间值表示提供每个Ui以构建支付渠道Ui→U(i+1)modn、提取必要的秘密值以及向比特币网络提交支付U(i+1)mod n的执行交易TPay的时间量。时间s表示为秒或区块数。
[0197] ·选择另一值S作为提交给比特币网络的用户的第一次支付的开始时间。注意,S表示在Unix时间或区块高度中指定的时间点,而s表示时间跨度。
[0198] 在每对用户之间建立单向支付渠道,其中,支付的方向是Ui向U(i+1)mod n支付。例如,假设n=7,GRE的支付渠道将包括U0→U1,U1→U2,…和U6→U0。
[0199] 创建支付渠道Ui→U(i+1)mod n的过程描述如下,如图13和14所示:
[0200] ·初始承诺交易Tc使可用的x BTC只能通过“Ui和U(i+1)mod n的签名”或“sv(i+1)mod n和U(i+1)mod n的签名”根据其来使用;
[0201] ·出于我们的目的,只需要一次退款交易;这个退款交易,Tr,0将所有x BTC返还给Ui;
[0202] ·支付渠道的退款交易Tr,0包含nLockTime值S+(n-i)s;
[0203] ·退款交易Tr,0必须在初始承诺交易Tc被提交给比特币网络之前由U(i+1)mod n签署;
[0204] ·支付渠道包含支付交易TPay,其从Tc承诺的x BTC向U(i+1)mod n支付x BTC;以及[0205] ·支付交易TPay至U(i+1)mod n的内预期将包含值sv(i+1)mod n。
[0206] 按顺序创建用户对之间的支付渠道是非常重要的,因为支付渠道Ui→U(i+1)mod n是在支付渠道Ui-1→Ui之前被创建的。这从创建第一支付渠道U0→U1开始,其中,U0是发起者,并以最后一个支付渠道Un-1→U0结束。
[0207] 在某些配置中,序列的顺序很重要,因为这使得用户Ui在进行支付和承担与进行支付相关的风险之前,确保存在到Ui的TPay交易,如果Ui向U(i+1)mod n进行他/她的TPay支付,则Ui能够成功执行该交易。
[0208] 参考图15和16,现在将描述在该配置中使用的秘密值的准备工作。
[0209] 1.sv0的默认值设置为sv0=ks。回顾一下,ks是在GRE协议用户列表中的发起者U0选择的一个随机值。该ks值是协议安全性的核心,只有U0知道,并一直保密,直到所有支付渠道被创建和完成以达到U0满意为止;
[0210] 2.U0通过将默认sv值ks乘以椭圆曲线的基点G来加密该默认sv值ks。其中,Qi是加密版本的svi值,加密版本的默认sv是Q0=sv0G=ksG;
[0211] 3.对于创建的第一支付渠道U0→U1,U1将其随机数k1传送到U0,U0将‘加密版本的密钥’Q0传送到U1;
[0212] 4.创建的支付渠道U0→U1的sv值为sv1=sv0+k1,其密文为:
[0213] Q1=Q0+k1G;
[0214] 注意:
[0215] ο新的秘密值(ks+k1)出现在Q1的计算中,如下:
[0216] Q1=ksG+k1G=(ks+k1)G;
[0217] ο用户U1不知道ks和其后的交易的秘密值;以及
[0218] οU1和U0都可以计算和验证对方对Q1的计算;
[0219] 5.步骤3和4可适用于GRECS电路中的所有其他支付渠道。这种概括描述如下:
[0220] ·U(i+1)mod将其随机数k(i+1)mod n传送给Ui。Ui将加密版本的密钥Qi传送给U(i+1)mod n;
[0221] ·创建的支付渠道的sv值为sv(i+1)mod n=svi+k(i+1)mod n,,其加密值为:Q(i+1)mod n=Qi+k(i+1)mod n G;
[0222] ·注意,对于支付渠道:
[0223] ο可以在Q(i+1)mod n的计算中看到新的秘密值sv(i+1)mod n=ks+k1+k2+…+k1+k(i+1)mod n,如下:
[0224]
[0225] ο用户U(i+1)mod n不知道交易的秘密值,因为ks和sv的所有其他先前的
迭代都已加密;以及
[0226] οU(i+1)mod n和Ui都可以计算和验证对方对Q(i+1)mod n的计算。
[0227] ·注意,前面的流程也适用于最终支付渠道Un-1→U0。因此,除了秘密随机数ks之外,U0还必须创建第二随机值k0。k0是添加到秘密值的最终值。注意,最终秘密值被标记为svfinal,而不是sv0;以及
[0228] 6.只有发起者U0不必在他/她支付的支付渠道之前优先建立他/她被支付的支付渠道。这是因为不能被U0欺骗,因为U0是唯一知道所有支付渠道的所有TPay交易所需的ks值的人。因此,在U0能够舒适地开始该过程(与其发布最终秘密值svfinal=ks+k1+k2+…+kn-1+k0,包括ks值的时间一致)前,此配置的GRE协议中的任何用户都不能执行撤销操作。
[0229] 最终支付渠道Un-1→U0在时间S或之前完成。连接用户的这组支付渠道可以被
可视化为如图16所示的圆圈,图16示出了该配置的协议的所有用户之间存在的Ui→U(i+1)mod n支付渠道的表示。箭头表示支付渠道和TPay支付的方向。箭头外部相邻的值表示交易TPay:Ui→U(i+1)mod n所需的秘密值被区块链所接受。箭头内部相邻的值表示s时间跨度值。Qi值表示支付渠道秘密值的加密值。
[0230] 鉴于循环设置,{Ui|I∈[0,n–1]}的顺序是随机,这意味着支付用户Ui和由用户Ui支付的用户都是随机的。同样地,支付用户Ui的用户不同于Ui支付的用户。
[0231] 发起者U0花费现有支付渠道Un-1→U0的交易TPay,披露svfinal=ks+k1+k2+…+kn-1+k0的值。如上所述,是U0创建了值ks和k0,所有用户都需要将其ki值发送给U0。
[0232] U0可以将svfinal的值直接传送给Un-1,或者可以从区块链中提取该值。
[0233] 虽然Un-1现在知道svfinal,但这不是Un-1经由支付渠道Un-2→Un-1接收支付所需的秘密值:
[0234] svfinal=ks+k1+k2+…+kn-1+k0,而:
[0235] svn-1=ks+k1+k2+…+kn-1。
[0236] 然而,Un-1可以通过从svfinal中减去k0来轻松计算svn-1,然后提交TPay交易,以进行支付。Un-1在构建支付渠道交易时会从以前的流程中知道k0。
[0237] 类似地,每个用户U(i+1)mod n可以直接将值sv(i+1)mod n传送给其付款人Ui。如果U(i+1)mod n没有传送,则用户Ui可以在区块链账本中提取值sv(i+1)mod n(在至少时间s内)。
[0238] 从sv(i+1)mod n中,用户Ui可以通过从sv(i+1)mod n中减去k(i+1)mod n来计算svi,这使得Ui可以经由TPay:Ui-1→Ui被支付。
[0239] 由于区块链平均需要10分钟来确认交易,所以s的值应该选择为使得它所表示的时间段足以在交易TPay提交给比特币网络之后,让任何用户Ui在该时间段内找到(如果必要的话)该交易TPay:Ui→U(i+1)mod n中的sv(i+1)mod n的值。如果确认交易的平均时间发生变化,则可以相应地选择s。
[0240] s值还应包括一对用户之间构建支付渠道的估计时间。因此,s将是s=ssv+ε,其中,ssv是找到sv(i+1)mod n并提交TPay:Ui→U(i+1)mod n的估计时间,而ε是构建支付渠道的估计时间。
[0241] 由于发起者U0已经向网络提交了Un-1和U0之间的现有支付渠道的TPay交易,向Un-1披露了svfinal的值,然后svi的值才可以以逆时针方式(从Un-1到U1)披露给每一个其他用户Ui:见图17。这是基于一个前提,即每个用户Ui将投资于提交交易(支付渠道Ui-1到Ui的TPay),以使他们自己获得支付。
[0242] 提交上述交易的用户Ui将需要从支付渠道Ui到U(i+1)mod n的TPay获得sv(i+1)mod n的值,Ui将从该TPay中导出svi。通过Ui提交支付渠道Ui-1到Ui的交易TPay,导出svi-1的用户Ui-1随后可以获得svi的值。这个过程像多米诺骨牌一样级联,从Un-1一路落到U1,这样兑现的每个用户Ui都会向用户Ui-1披露svi-1,从而使得用户Ui-1也兑现。
[0243] 更正式地,支付渠道的TPay交易(执行/提交)顺序如下:
[0244] [TPay:Un-1→U0],[TPay:Un-2→Un-1],...,[TPay:U1→U2],[TPay:U0→U1],[0245] 这组TPay交易的完成成功结束了该过程。每个用户支付了x BTC,每个用户接收了x BTC。
[0246] 在该配置中提交TPay:Ui→U(i+1)mod n交易的过程如图18所示,其中,t是当前时间,PC是支付渠道Ui+1=U(i+1)mod n,bc是区块链。对于支付渠道Un-1→U0,sv值被命名为svfinal。
[0247] 向区块链提交的所有退款交易Tr,0受nLockTime值的限制。nLockTime参数的这个值表示一个绝对时间值,因此Tr,0将仅在该时间或之后被区块链接受。Ui→U(i+1)mod n的nLocktime值是S+(n-i)s。
[0248] 如果U(i+1)mod n未能在nLocktime值之前签署并且披露Q(i+1)mod n的sv(i+1)mod n,则用户Ui提交Tr,0:Ui→U(i+1)mod n。
[0249] 如果Ui提交Tr,0:Ui→U(i+1)mod n,意味着支付交易TPay:Ui→U(i+1)mod n尚未且永远不会被执行。这意味着sv(i+1)mod n不会被披露,因此Ui-1将无法从区块链计算支付交易TPay:Ui-1→Ui所需的svi。
[0250] Ui-1必须等到Ui-1→Ui的nLockTime值之时或之后,才能提交退款交易Tr,0:Ui-1→Ui。
[0251] 对于多于且包括提交Tr,0:U0→U1的发起者U0的所有用户,这些退款提交过程是以逆时针方式重复执行的。这些交易中的每一个只能发生在特定的时间点或之后。这一系列退款交易的一个示例如图19所示,其中,U4未能在t=S+4s之前为TPay:U3→U4签名并生成sv4。退款交易用逆时针方向的箭头表示。支付或执行交易由顺时针方向的箭头表示。
[0252] 需要注意的是,退款交易不必在准确的nLockTime值提交。也可以在该时间之时或之后。这意味着,虽然Ui可以为TPay:Ui→U(i+1)mod n授予U(i+1)mod n额外的时间tx来签名并生成sv(i+1)mod n,但这意味着Ui将因此具有更少的时间为TPay:Ui-1→Ui生成svi(假设Ui-1没有授予Ui额外的时间)。参见图20,其中,U0被授予额外的时间tx,导致Un-1只有较少的时间来计算svn-1并向区块链提交TPay:Un-2→Un-1,因为U0迟交TPay:Un-1→U0。
[0253] 下面将描述在该配置的协议的一对用户之间的支付渠道Ui→U(i+1)mod n中使用的比特币交易的结构。这些支付渠道由三个主要交易组成:
[0254] ·存入2对2多重签名交易Tc:该交易表示支付渠道的承诺部分,可称为承诺交易。在此处,通过交易,用户Ui发送/提交指定数量的比特币x BTC,由以下任一个管理:
[0255] ο2对2多重签名(Ui,U(i+1)mod n)
[0256] 或者
[0257] ο对值sv(i+1)mod n的知晓和U(i+1)mod n的签名;
[0258] ·退款交易Tr,0:该交易表示x BTC(从承诺交易)退款给用户Ui,该用户在指定时间到期后具有提交给区块链的资格。要成功执行该交易,需要用户Ui和U(i+1)mod n的签名;以及
[0259] ·支付交易TPay:该交易是Ui从承诺的资金中向用户U(i+1)mod n支付x BTC。要成功执行该交易,需要对秘密值sv(i+1)mod n的知晓和用户U(i+1)mod n的签名。支付交易也可称为执行交易。
[0260] 注意,图21至24的交易的详细信息仅限于各种交易的、、nLockTime和输出值,因为这些是与该配置最相关的交易元素。
[0261] 交易详细信息如图21至24所示。下面描述椭圆曲线操作码的细节。
[0262] 该配置使用椭圆曲线加密。给定秘密值k,其EC加密值是Q=kG;其中,G是椭圆曲线上的基点。
[0263] 这种EC加密相当于在所有支付渠道中使用相同秘密值的配置的GRE的散列函数。然而,EC加法的同态性质允许在这种配置的支付渠道中改变sv值,同时允许从sv的最终版本svfinal的披露开始的秘密值的多米诺级联。
[0264] 对于每个支付渠道Ui→U(i+1)mod n,承诺交易Tc包括一个条件,该条件规定,除了退款之外,承诺资金只能在出现产生加密值Q(i+1)mod n的秘密值sv(i+1)mod n时被花费。承诺资金的这种不退款花费将由支付渠道的TPay完成。
[0265] Q(i+1)mod n=sv(i+1)mod n G
[0266] 其中,sv(i+1)mod n=ks+k1+k2+···ki+k(i+1)mod n
[0267] 为了确定sv(i+1)mod n是否正确,使用了下面的EC操作码,其提供了乘法Q=kG。该操作码称为OP_ECPMULT。OP_ECPMULT取一个编码的椭圆曲线点和一个数,然后用标量进行椭圆曲线乘法。其输出结果以作为编码的椭圆曲线点。
[0268] 支付渠道Ui→U(i+1)mod n的交易Tc、Tr,0和TPay的脚本如图21至24所示。具体地,图24示出了如何使用上述操作码OP_ECPMULT将承诺交易Tc的与支付交易TPay的相结合,以解锁承诺的x BTC。
[0269] 尽管在本领域技术人员的职权范围内会组合这些配置以便使用变化的秘密值和不变的秘密值的组合,上文已经描述了本发明的配置为对所有支付渠道使用相同的秘密值或者对所有支付渠道使用不同的秘密值。
[0270] 此外,应当理解,诸如电子邮件、文件传输协议和点对点共享等其他通信渠道可以被本发明任何配置的用户用来传送信息,并且该信息可以涉及秘密值或与其相关的信息、一个或多个交易的详细信息以及一个或多个交易本身的完整或不完整版本,并且除了区块链之外的通信渠道的使用程度可以取决于本发明的给定用户对之间存在的信任程度。
[0271] 应当理解的是,虽然上述本发明的配置仅涉及用户之间的比特币转移,但是用户可以使用该协议交换其他资源,例如,信息、合约和代币。代币根据与代币相关联的智能合约表示资产或资源,以使对代币的控制提供对资产或资源的控制。智能合约本身可以存储在区块链以外的地方,也可以存储在一个或多个交易中。
[0272] 在本文,术语“系统”用于包括计算机
硬件和/或软件系统,其被配置为执行上述GRE协议的至少一种配置、协议本身以及保存在计算机硬件上的协议的步骤。
[0273] 应当注意的是,上述实施例阐明了本发明,而不是限制了本发明,并且本领域技术人员将能够在不脱离由所附权利要求限定的本发明的范围的情况下设计许多替代实施例。在权利要求中,括号中的任何附图标记不应被解释为对权利要求的限制。词语“包括(comprising)”和“包括(comprises)”等不排除任何权利要求或整个
说明书中列出的元件或步骤之外的元件或步骤的存在。在本说明书中,“包括(comprises)”是指“包括(includes)或者由……组成(consists of)”,而“包括(comprising)”是指“包括(including)或者由……组成(consisting of)”。元件的单数引用不排除这些元件的复数引用,反之亦然。本发明可以通过包括若干不同元件的硬件以及通过适当编程的计算机来实现。在列举了若干种方法的设备权利要求中,这些方法中的几种可以由同一个硬件来实现。在相互不同的
从属权利要求中引用某些措施这一事实并不表示这些措施的组合不能有利地使用。