Created TIP-1: Protocol Optimization

tip-0001.mediawiki

@@ -0,0 +1,115 @@
+= Tumblebit Improvement Proposal (TIP) =
+
+== TIP 1 ==
+
+=== Background ===
+
+While implementing a demo Tumblebit server in “classic tumbler” mode and after carefully reviewing '''Fig 4 of the [https://eprint.iacr.org/2016/575.pdf white paper] describing interactions between Tumbler and Bob''', I came to the conclusion that steps 2-7 could be simplified (steps 9-12 are unchanged).
+
+The objectives are
+
+# stick to the most common cryptographic primitives (avoid Tumblebit-specific data formats)
+# reduce the amount of data flowing back and forth between Tumbler and Bob.
+# preserve the security and privay-protection proprerties of the original Tumblebit protocol
+
+Objective 1 is meant to facilitate integration of Tumblebit features into multiple wallet implementations: wallet developpers should be able to use their favorite Bitcoin library with minimal additional code.
+
+=== Proposal ===
+
+Initially, before each payment phase, Tumbler generates a fresh ECDSA key pair (PKT, SKT).
+
+Bob generates an ECDSA key pair,(PKB, SKB), for “real” transactions and picks a single random 256-bit blinding factor r for “fake” transactions. Bob keeps r secret for now and publishes PKB.
+
+In Fig. 4 '''step 2''', Bob generates 42 “real” payout addresses (keeps them secret for now) and prepares 42 distinct “real” transactions.
+
+In '''step 3''', Bob prepares 42 “fake” transactions like so:
+
+Fake transaction i pays Tumbler compressed Bitcoin address (corresponding to PKT) 1 BTC in output 0 (no network fee bearing in mind the transaction will never hit the blockchain ) with an OP_RETURN output (output 1) containing the hex string
+
+<code>r || i</code>
+
+Such fake transaction only sends a full refund to Tumbler and is unlikely to confirm without network fees. ''No need for Bob to generate (and later transmit to Tumbler) a set of 84 random pad values. Bob needs only to generate one regular, Bitcoin key pair and one random blinding factor.''
+
+Bob hides the transactions in 84 sighash values (regular Bitcoin sighash computations here) , permutes them ('''Step 4'''), and finally sends them to Tumbler as beta1, …, beta84.
+
+''Minimized data flow: no need for Bob to send to Tumbler any hR, hF''
+
+In '''Step 5''', Tumbler signs each betai with SKT to create an ECDSA-Secp256k1 signature sigmai. Tumbler picks 84 random 256-bit symetric encryption keys epsilon and computes ci = AES256( epsiloni, sigmai ) ''Minimized data flow: we propose a simple AES256 encryption instead of the complex SHA512 hash specified in the original paper: this yields most of the data traffic reduction''
+
+'''Step 6''': Bob sends to Tumbler the 42 “real” indices along with blinding factor r.
+
+''Minimized data flow: Bob sends a single 256-bit blinding factor r in lieu of a salt value and 42 pad values.''
+
+{|
+! Original
+!align="center"| Size
+! TIP 1
+!align="center"| Size
+|-
+| 84 Betas
+|align="center"| 2688 Bytes
+|
+
+|align="center"| 2688 Bytes
+|-
+| hR,hF
+|align="center"| 64 Bytes
+|
+
+|align="center"| 0
+|-
+| 84 (z,c) couples
+|align="center"| 26880 Bytes
+|
+
+|align="center"| 24192 Bytes
+|-
+| Salt
+|align="center"| 32 bytes
+|
+
+|align="center"| 0
+|-
+| 42 random r
+|align="center"| 1344 Bytes
+| One random r
+|align="center"| 32 Bytes
+|-
+| 41 Quotients
+|align="center"| 10496 Bytes
+|
+
+|align="center"| 10496 Bytes
+|-
+| 42 Epsilons
+|align="center"| 10752 Bytes
+|
+
+|align="center"| 1344 Bytes
+|-
+| Total
+|align="center"| '''52256 Bytes'''
+|
+
+|align="center"| '''38752 Bytes'''
+|-
+| Reduction
+|align="center"|
+
+|
+
+|align="center"| '''26%'''
+|}
+
+'''Step 7''': Tumbler can now compute the “fake” sighash values and verify that they match the “fake” betai values: betai = sighash value of tx paying Tumbler 1 BTC in output 0 with an OP_RETURN output (output 1) bearing the hex string
+
+<code>r || i</code>
+
+The i index is appended to r so that each i is a preimage of betai. ''No need for the CashOutTFormat nor the FakeFormat specified in the original white paper''
+
+'''Conclusion'''
+
+With this proposal,
+
+# the total data flow in the interactions between Bob and Tumbler is reduced by 26% as a result of the simplification and use of AES256 for symetric encryption.
+# the need for specific formats like CashOutTFormat and FakeFormat is avoided so a regular Bitcoin library is sufficient to build a wallet implementation.