Learn about the bitcoin mix with | hardcore: TumbleBit
Original title: "getting to know your bitcoin mix with hardcore | : TumbleBit"
Source: Nervos
TumbleBit is an article published in NDSS in 2017. It is a bitcoin compatible centralized coinage protocol and a protocol to solve the linkeability problem of Bitcoin transactions. TumbleBit can expand the volume of transactions in the block chain, as well as the transaction speed of the block chain. In this article, research-loving Nervos colleague Ma Yufeng takes a detailed look at TumbleBit's overall framework, its puzzle and puzzle protocols, and introduces the design of a solution to the problem. TumbleBit Some attacks that cannot be correlated. Get your new skills.
Overall framework structure & NBSP;
Since TumbleBit needs to be compatible with blockchains that support only non-Turing-complete languages such as Bitcoin, the parts of the chain that need cryptographic primitives are few and simple. And while it's a centralized protocol, even malicious Tumbler can't steal money and find links between transaction inputs and outputs without engaging in user collusion. The advantage of TumbleBit over coinjoin and CoinShuffle is that it does not require a party to interact with another user. The interaction only takes place between the parties and Tumbler.
TumbleBit can aggregate many transactions sent to one party into two on-chain transactions that do not need to be stored or verified on the blockchain, thus extending the volume of blockchain transactions, and TumlbeBit's off-chain transactions can be completed in seconds, thus extending the speed of blockchain transactions.
TumbeBIt's main idea is simple: instead of paying on the chain, it uses solving puzzles under the chain. When Alice wants to pay Bob some money, Alice gives Bob the solution to a puzzle that Has been created by the interaction between Bob and Tumbler. For each puzzle, Alice sends Tumbler a bitcoin, and Tumbler sends Bob a bitcoin.
The TumbleBit protocol construct is shown in the figure above. The TumbleBit protocol operates with a period of the epoch, so it's important to note that everyone involved in the TumbleBit protocol knows the time of each stage within each epoch. Each epoch is divided into three stages:
The first is the Escrow phase, and this is the chain hosted phase. At this stage Bob told Tumbler to receive up to three bitcoins within the epoch, and Tumbler constructed an escrow transaction;
This is a 2-OF-2 multi-signature transaction, unlocked by signing Bob and Tumbler or by signing Tumbler when tw2 is exceeded, and then allowing Bob to get Promise-puzzle pair by running a Puzzle Promise protocol under the chain between Bob and Tumbler, i.e. (c, z),
Tumbler's signature for this transaction, and C is the symmetric key
对签名加密的密文，我们称 c
为 promise， z
是一个 RSA puzzle，是用 Tumbler 的公钥对对称密钥 加密后的密文，协议运行完成后 Tumbler 将 
The transaction is sent to the chain, and payer Alice also sends an escrow transaction & NBSP at this stage; 
, this is also a 2-OF-2 multi-sign transaction, unlocked with the signatures of Alice and Tumbler, or retrieved by Alice after tw1;
第二是 Payment 阶段，这个是链下支付阶段。在这个阶段 Bob 将 puzzle 盲化后发送给 Alice，盲化 puzzle 的目的是为了防止 Tumbler 将交易方关联起来，盲化方法很简单，就是选取一个盲因子 r，
然后用 Tumbler 的公钥对 r
加密后乘上原来的 puzzle 
Alice runs an RSA-puzzle protocol with Tumbler after she gets the blind puzzle, gets the solution of the blind puzzle, and sends it to Bob. Since the RSA algorithm is multiplicative homomorphology, decryption of the blind puzzle is NBSP;
Divided by r You get a cake;
And decrypt it to get the signature & NBSP;
;
Finally, there is the cash-out stage, which is the withdrawal stage on the chain. Alice takes back the remaining two bitcoins, pays Tumbler one, Tumbler takes back the remaining two bitcoins, and pays Bob one.
Puzzles agreement
This article focuses on the RSA-Puzzle solving protocol, which is a fair exchange protocol. Alice pays Tumbler a bitcoin when and only if Tumbler gives Alice a solution to RSA Puzzle, which can be integrated into the TumbleBit protocol and run independently as a fair exchange protocol in other scenarios.
这个协议的核心思想是 Tumbler 解迷 Alice 的 puzzle 之后，将这个解用对称密钥 k
加密得到密文 c，然后使用比特币支持的哈希算法计算 k
的哈希为 h，之后将（c，h）发送给 Alice, Alice 收到之后发送交易
The unlock condition is to provide H
To get this bitcoin,
And then When it's open, Alice gets a k, with A K & NBSP; To the c
One challenge for this protocol is to find a way for Alice to verify ciphertext C without using zero-knowledge proof
图 2. RSA-puzzle-solving 协议
The protocol details are shown in the figure above. The public input is Tumbler's RSA public key (E, N), and Alice's is puzzle
First Alice prepares the puzzle set, which includes M 
In the second step, Alice prepares the false message set, which contains n
Alice then randomizes the set of mixed puzzles to get a new set, and writes down the subscripts for real puzzles and fake puzzles, then sends the new set to Tumbler.
Tumbler decrypts each element of the new set, encrypts the resulting plaintext with a different symmetric key to get the new ciphertext, and then sends Alice the hash of all the new ciphertext and the corresponding key for the new ciphertext;
Alice sends the index of false puzzle and the random number in false puzzle to Tumbler, which verifies that puzzle in set F is indeed false (if it is true, Alice cannot know Y without the key
1. Alice is puzzle, and determine if Tumbler cheated Alice. If the verification passes, Alice constructs and publicly trades NBSP;
, if tw1 is exceeded and Alice's signature is required to unlock the puzzle, or Tumbler provides the key for all real puzzles;
Alice then sends the real puzzle, along with all blind factors, to Tumbler, which verifies that all the real puzzles correspond to the same puzzle, and publishes it if it passes.
Trade to get bitcoin,
Contains all the real puzzle keys;
Finally, Alice uses the real puzzle key to solve the puzzle.
So the only time Alice can't get a correct answer is if Tumbler turns on all the fake puzzles correctly, and all the real ones that aren't turned on are wrong, which is a probability of
.
There are three problems with this protocol when applied directly to TumbleBit: the first is that it only allows Alice to obtain one puzzle, which should be expanded to allow any number of Q puzzles; The second is that the deal should happen entirely down the chain, which currently requires trading on both chains & NBSP;
And & have spent
; The third is NBSP;
A trade is longer than a typical trade because it contains m
The solution:
First, in the EScrow stage, Alice sends & NBSP;
To mortgage Q bitcoins,
Is unlocked with the signatures of Alice and Tumbler or after tw1 has expired;
Alice can then buy up to Q puzzle solutions during the payment phase, and Tumbler maintains a counter to calculate the number of solutions Alice has provided. Now suppose Alice is asking for I
1. Alice constructs and signs the deal/NBSP;
To Tumbler, which will neither sign nor make the transaction public upon receipt;
The trade points to NBSP;
The deal, that is, will be NBSP;
The output of the transaction as NBSP;
The input to the transaction will be NBSP;
The bitcoin transaction is transferred to NBSP;
Trading,
There are two transaction outputs, one is the I sent to Tumbler
Bitcoins, which require Tumbler to provide the key to unlock;
3. Tumbler doesn't use cake;
The transaction sends the key, but instead sends the key directly to Alice;
4. Alice verifies whether the key is correct. If so, Alice signs a transaction that will be used during the withdrawal phase
If Alice cheats and does not send NBSP after receiving the correct key;
Tumbler would be able to make it public with NBSP;
And & have spent
To get your fair share of bitcoin, the price is NBSP;
And & have spent
It's bigger than a regular transaction, and you'll have to pay a few more fees. After these modifications, rSA-puzzle - Solving can be used for Bitcoin.
Puzzle agreement
Now let's talk about NBSP; puzzle-promise Protocol, which runs under the chain between payee Bob and Tumbler during the EScrow phase, aims to allow Bob to obtain a promise-puzzle pair (C,z)
这个协议的挑战是如果 Tumbler 仅仅发送一个
(c,z) 给 Bob, 那么 Bob 就不知道 c 是否是正确签名的加密，也不知道 z
We can still tackle this challenge by cut-and-choose. But unlike Rsa-Puzzle solving, Bob gets a lot of masse-promsie pairs, and cut-and-choose ensures that at least one pair is correct (ensuring that all correct probabilities are lower than at least one pair is correct). Bob can only ask Alice one puzzle at a time. TumbleBit solves this problem by using the RSA puzzle technique. By using the RSA chain technique, Bob is guaranteed to get the solution to all the puzzles once he gets one.
Figure 3. Puzzle- Promise agreement & NBSP;
Given the space given, let's briefly introduce NBSP; The cut - and - chosse:
Bob passes an analysis of NBSP;
The format is different but with the same meaning & NBSP;
Trade as a true set and then prepare
Tumbler signs each element in the collection, encrypts it with a different key, and Bob sends a collection of fake messages to Tumbler after he sends all the massed-promise pairs.
Tumbler verifies the authenticity of the fake message set. If the verification is done by sending the symmetric key in the fake set pair to Bob, Bob decrypts the signature with this key. Tumbler starts to prepare the RSA merchant chain after the verification is correct. The business chain is that Tumbler uses the second symmetric key and divides the previous symmetric key to get a cake;
The quotient (step 9 in the figure above) is then sent to Bob.
Bob uses the homomorphism of the RSA algorithm to verify that the quotient is correct. If the puzzle is correct, he sends the first puzzle to Alice and takes the puzzle to NBSP;
After times & have spent
Get the
Signature of a transaction. These transactions are different, but only in terms of padding, so Bob can only use one pie;
Trade to get cash.
不可关联性
到这里完整的 TumbleBit 协议部分就介绍完了，接下来看一下 TumbleBit 的不可关联性。我们先看一下 Tumbler 的视角如下图所示，Tumbler 看不到交易间的关联性，但是能看到付款人在哪个时间和自己交互的，因此结合一些额外信息，可以对交易间的关联性进行分析。我们下面介绍一些针对 Unlinkable 的攻击，这些攻击中有些是能避免的，有些是没有很好的方法避免的。
Figure 4. Tumbler perspective
Ceiling attack Alice and Tumbler conspire to create ceiling attack. This is called ceiling attack. It assumes that at some point like NBSP;
, Alice pays Bob one bitcoin, but Bob has already reached the limit of receiving, so he rejects Alice's request for payment. Alice brings this information to Tumbler. Tumbler can rule out NBSP;
The post-moment transaction is a possibility sent to Bob. Tumbler does not know when Bob will reach his acceptance limit if Alice does not conspire with him.
There are several solutions to this attack. For example, Bob makes the maximum amount of money he can receive much higher than expected during the EScrow phase. Or you could stagger the time of a TumbleBit epoch and run several at once, using up the amount of one epoch in Bob and the next one.
Bob and Tumbler conspire together;
Bob and Tumbler Conspiracy: Bob tells Tumbler to send Alice blind puzzle so that Tumbler knows Alice's identity (especially in situations where Alice and Bob don't know each other's identity, such as using the Tor protocol). The solution is simple: Alice runs RSA-puzzle with Tumbler after she has blinded the puzzle sent by Bob, and then sends Bob the puzzle blind.
Potato attack & have spent
Potato attack is to point to consider outside information, assuming that Bob was selling potatoes, a Potato 7 COINS, and Tumbler know something nobody else sell 7 COINS, then Tumbler can eliminate some transactions (such as Calor only a total of 6 deal, she was left out, and Alice just seven deal in the short term, so presumably Alice in buy potatoes). The solution is to add redundant transactions, where Alice creates a collection address, transfers a sum of money to her address as she buys potatoes, or buys something else at the same time.
Intersection attacks
Intersection attacks: Unlinkability is defined only within a cycle and does not rule out some associations between cycles. The following abort attack is one such attack. Abort attacks: Tumbler can Abort a transaction to get some information. Tumbler, for example, notes that there are cycles in which Alice has been making individual transactions and Bob has been hitting the limit, and then in the next cycle, when Tumbler halts Alice's payments and finds that Bob is no longer hitting the limit, Tumbler can guess that Alice is trading with Bob.
Abort the attack & NBSP;
Abort attacks: Tumbler can Abort a transaction to get some information. Tumbler, for example, notes that there are cycles in which Alice has been making individual transactions and Bob has been hitting the limit, and then in the next cycle, when Tumbler halts Alice's payments and finds that Bob is no longer hitting the limit, Tumbler can guess that Alice is trading with Bob.
Summary & have spent
There are limitations, but if there are enough transactions, the unconnectability of the transactions is guaranteed.
The author thinks that & NBSP; TumbleBit has two main disadvantages. The first is that all users in the system use the same "denomination" money, so it is difficult to define the denomination. If the denomination definition is small, large payments require a lot of offline interaction, but can be addressed by running several Tumbler within the system, each of which offers a different denomination. The second is that Tumbler needs to pledge money in advance. This can be addressed by a service charge, which recipient will pay as required by Tumbler's mortgage.
TumbleBit is an excellent money-mixing solution, regardless of the privacy of the amount.
The original link
Welcome to join the official BlockBeats community:
Telegram Subscription Group: https://t.me/theblockbeats
Telegram Discussion Group: https://t.me/BlockBeats_App
Official Twitter Account: https://twitter.com/BlockBeatsAsia
Related Articles
