比特币交易合约应用案例:如何提供押金证明?

企业新闻 | 2018-08-20

  比特币交易合约应用案例:如何提供押金证明?


比特币交易合约应用案例:如何提供押金证明?

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


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


  对于该问题,可以通过合约来解决,具体步骤如下。


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


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


  3)用户把TXl交易的Hash值发送给网站。


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


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


  6)用户先广播TXl,再广播TX2。


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


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


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


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