找回密码
 立即注册

新浪微博登陆

只需一步, 快速开始

查看: 1180|回复: 0

混币Coin Shuffle---原理

942

主题

1096

帖子

4668

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
4668
nxt 发表于 2015-7-18 18:46:21 | 显示全部楼层 |阅读模式
CoinShuffle(混币)最早是由TimRuffling与2014年4月12日在BitcoinTalk论坛上提出,同时作者也给出了技术白皮书
后来Nxt开发者借鉴其概念,将其应用于Nxt协议,计划在1.6.X系列的客户端中实施该功能。


综述
  • 该功能基于Nxt协议,可以在Nxt客户端界面中直接使用,同时充分考虑了安全性和易操作性;
  • 混币功能适用于NXT本身和货币系统;
  • 最终的结果是:N个人提交了相同数量的资金,这些资金将最终都分发到他们提供的不同的账号中,而且没有人知道发送者和接收者的账户关系;


实施建议

假定有4个参与者,Alice, Bob, Charlie 和 Dave,使用的账户分别是 A', B', C', D',但是协议本身允许最多有10个参与者。参与者越多,混币过程越安全。


创建混币

在本例中,Alice是混币的创建者,她提交了一个混币创建交易,提供了她的原始账户、混币币种、混币金额、参与者人数和取消高度。


Bob, Charlie 和 Dave 能够在客户端中看到该混币请求,通过发送混币注册交易提供混币ID和原始账户来参与该混币过程。该协议确保每一个注册的账户都有公钥和要求的余额,用于混币的金额将会从每一个注册人的未确认余额中扣除。如果在到达取消高度之前注册仍未完成,混币将会取消,资金将解冻释放。当参与人数达到Alice指定的数目后,混币开始激活,由Alice启动该过程。


混币过程

Alice通过混币id、她的密码和她的接受账号A'提交了混币处理请求。如果她不是混币受托人,她将会收到错误信息。正如TimRuffing所解释的,节点会收到计算token enc(ekC, enc(ekD, A')))的请求,并将结果加密token作为一个交易附件广播至其它节点。每一个节点都处理该交易,保存加密数据,并将混币受托人改变为下一个参与者(例如,Bob)。客户端会反应出目前的混币状态,即混币分配给了Bob。


Bob通过混币id、他的密码和他的接收者账户B'提交了一个混币处理请求。收到请求的节点会加载由Alice在之前的交易中生成的token,使用Bob的密码解密token,然后计算enc(ekC, enc(ekD, B'))并添加到enc(ekC, enc(ekD, A')),混和这两个token并将结果数据作为交易附件提交给其它节点。


类似地,Charlie提交混币处理请求、节点解密enc(ekD, B'), enc(ekD, A') ,计算enc(ekD, C') ,混和tokens并提交一个混币处理附件。


最后,Dave提交混币处理请求,节点解密所有地址,添加D',最后一次混合地址,并通过所有解密地址提交混币处理。


现在混币移动至验证阶段,客户端中也会反应出混币状态。


混币验证和分发

现在参与者验证他们的接受地址包括在混币结果中来确保没有人在作弊。每一个混币参与者通过混币id提交混币验证交易来验证他们的地址是混币的一部分。验证顺序不重要,只要所有的参与者都验证了他们的地址。

一旦所有的参与了发布了混币验证交易,Alice就能提交混币分发交易来按照Dave所提供的混币将资金分发至接收者地址。此时,混币完成,节点可以从数据库中将所有的混币信息清除。


在处理过程完成之前的任何时候,Alice都能提交混币取消请求来取消该过程并将所有资金返回到他们的原始账户中(减去最小费用)。在验证阶段,每一个参与者都可以取消混币。

混币状态在客户端界面中始终是可见的,允许参与者监控该过程。


注意:该功能的本质是没有一个参与者知道原始账号与接收者账号之间的完整关联。即使Dave收到了所有的目标账户也无法将其它参与者的原始账户与目标账户进行关联,因为他不知道Bol和Charlie所执行的混币是什么,外部的观察者就更不可能算出它们的之间的关联了。


=========


Coin Shuffling

Updated Nov. 3rd, 2014

This feature is based on the idea presented by TimRuffing in https://bitcointalk.org/index.php?topic=567625.msg6370451#msg6370451 and is based on the academic paperhttp://crypsys.mmci.uni-saarland.de/projects/CoinShuffle/coinshuffle.pdf which is also the source of the feature name.



Overview
  • The implementation of the feature is based on the NXT protocol, which eliminates some of the manual steps and security concerns while providing a framework for shufflers to coordinate their actions using the client user interface.
  • Shuffling can be performed using NXT (this is still being debated) or using monetary system currency units.
  • The end result is that N people submit the same amount of funds, all of them receive their funds back to different accounts they provided while there is no known mapping between sender and recipient accounts.


Implementation suggestion


Here I assume there are 4 participants Alice, Bob, Charlie and Dave using recipient accounts A', B', C', D' but the protocol itself allows for up to 10 participants. The more participants, the more secure the process.


Shuffle Creation

In our case Alice is the creator of the shuffle, she submits a /shuffleCreate transaction sending her source account, the shuffled currency, amount to shuffle, number of participants and cancellation height.

Bob, Charlie and Dave can now see the shuffle request in their client and register for the shuffling by sending a /shuffleRegister transaction providing the shuffle id and their source account number. The protocol ensures that each registered account has a public key and poses the required balance, the amount to shuffle is then reduced from each registrant unconfirmed balance. If the registration is not complete before reaching the cancellation height the shuffle is cancelled and funds are released. When the number of participants specified by Alice is reached the shuffle becomes active and is assigned to Alice to start the process.


Shuffle Processing

Alice submits a /shufflingProcess request passing the shuffle id her secret phrase and her recipient account A' . If she is not the shuffling assignee she receives an error. Otherwise the peer receiving the request calculates the token enc(ekB, enc(ekC, enc(ekD, A'))) as explained by TimRuffing, and broadcasts the resulting encrypted token to other peer as a transaction attachment. Each peers process the transaction, stores the encrypted data and changes the shuffling assignee to the next participant (i.e. Bob). The client now reflects the status that the shuffling is assigned to Bob.

Bob submits a /shufflingProcess request passing the shuffle id, his secret phrase, and his recipient account B'. the peer which receives the request loads the token generated by Alice in the previous transaction, decrypts the token using Bob's passphrase then calculate enc(ekC, enc(ekD, B')) and add it to enc(ekC, enc(ekD, A')) shuffles the two tokens and submits the resulting data as transaction attachments to other peers.

Similarly, Charlie submits /shufflingProcess request, the peer decrypts enc(ekD, B'), enc(ekD, A') , calculates enc(ekD, C') shuffles the tokens and submits a /shufflingProcess attachment.

Finally, Dave submits /shufflingProcess request, the peer decrypts all addresses adds D' shuffles the addresses one last time and submits a /shufflingProcess passing all decrypted addresses.

The shuffle now moves to verification phase and this is reflected by the shuffling status in the client.


Shuffle Verification and Distribution

Participants now verify that their recipient address is included in the shuffling result to make sure no one has cheated. Each of the shuffling participants now submits a /shufflingVerify transaction passing the shuffle id thus verifying that his recipient address is part of the shuffling. The order of verification is unimportant as long as all participants verify their address.

Once all participants issued a /shufflingVerify transaction, Alice can submit a /shufflingDistribute transaction to distribute the funds to the recipient addresses according to the shuffling provided by Dave. At this point the shuffling is complete and peers can purge all shuffling information from their database.

At any point before the completion of the process, Alice can submit a /shufflingCancel request to cancel the process and return all funds to their original accounts (minus fees). During the verification stage each of the participants is allowed to cancel the shuffling.

The Shuffle status is visibile in the client UI all the times allowing the participants to monitor the process.


Note: the essence of this feature is that no single participant knows the complete mapping between source and recipient accounts. Even Dave who received the full list of destination accounts cannot associate source and destination accounts of the other participants since he cannot tell what was the shuffling performed by Bob and Charlie. Goes without saying that an external viewer cannot figure out this mapping.



Source from Nxt source code issues.


https://bitbucket.org/JeanLucPicard/nxt/issues/325/coin-shuffling

Total number of coins in Nxt is exactly 0.
In the very beginning,BCNext created coins and anti-coins out of the void just like vacuum creates particles and anti-particles.
In the very end,all coins will come back to genesis account and annihilate with their opposites...

NxtChina.org | 微博 | 关于我们
您需要登录后才可以回帖 登录 | 立即注册 新浪微博登陆

本版积分规则

快速回复 返回顶部 返回列表