From 81482194c64600c1733d9f7823854abfe185786b Mon Sep 17 00:00:00 2001 From: Pierre Noizat Date: Wed, 18 Jan 2017 19:10:20 +0100 Subject: [PATCH 01/26] Initial commit --- README.md | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 README.md diff --git a/README.md b/README.md new file mode 100644 index 0000000..f89b366 --- /dev/null +++ b/README.md @@ -0,0 +1,2 @@ +# tumblebit_tips +Tumblebit Improvement Proposals (TIPs) From 3b56e5e1673e0e1b34f4610cbd9c476ed543177a Mon Sep 17 00:00:00 2001 From: Pierre Noizat Date: Wed, 18 Jan 2017 19:12:22 +0100 Subject: [PATCH 02/26] Set theme jekyll-theme-minimal --- README.md | 39 +++++++++++++++++++++++++++++++++++++-- _config.yml | 1 + 2 files changed, 38 insertions(+), 2 deletions(-) create mode 100644 _config.yml diff --git a/README.md b/README.md index f89b366..f4f91fa 100644 --- a/README.md +++ b/README.md @@ -1,2 +1,37 @@ -# tumblebit_tips -Tumblebit Improvement Proposals (TIPs) +## Welcome to GitHub Pages + +You can use the [editor on GitHub](https://github.com/pierrenoizat/tumblebit_tips/edit/master/README.md) to maintain and preview the content for your website in Markdown files. + +Whenever you commit to this repository, GitHub Pages will run [Jekyll](https://jekyllrb.com/) to rebuild the pages in your site, from the content in your Markdown files. + +### Markdown + +Markdown is a lightweight and easy-to-use syntax for styling your writing. It includes conventions for + +```markdown +Syntax highlighted code block + +# Header 1 +## Header 2 +### Header 3 + +- Bulleted +- List + +1. Numbered +2. List + +**Bold** and _Italic_ and `Code` text + +[Link](url) and ![Image](src) +``` + +For more details see [GitHub Flavored Markdown](https://guides.github.com/features/mastering-markdown/). + +### Jekyll Themes + +Your Pages site will use the layout and styles from the Jekyll theme you have selected in your [repository settings](https://github.com/pierrenoizat/tumblebit_tips/settings). The name of this theme is saved in the Jekyll `_config.yml` configuration file. + +### Support or Contact + +Having trouble with Pages? Check out our [documentation](https://help.github.com/categories/github-pages-basics/) or [contact support](https://github.com/contact) and we’ll help you sort it out. diff --git a/_config.yml b/_config.yml new file mode 100644 index 0000000..2f7efbe --- /dev/null +++ b/_config.yml @@ -0,0 +1 @@ +theme: jekyll-theme-minimal \ No newline at end of file From 8960afbf25a82d17de660f49c52e24d05f33cdd5 Mon Sep 17 00:00:00 2001 From: Pierre Noizat Date: Wed, 18 Jan 2017 19:19:23 +0100 Subject: [PATCH 03/26] Update README.md --- README.md | 48 ++++++++++++++++++++++++++---------------------- 1 file changed, 26 insertions(+), 22 deletions(-) diff --git a/README.md b/README.md index f4f91fa..7bea35c 100644 --- a/README.md +++ b/README.md @@ -1,37 +1,41 @@ -## Welcome to GitHub Pages +## TIP 1 -You can use the [editor on GitHub](https://github.com/pierrenoizat/tumblebit_tips/edit/master/README.md) to maintain and preview the content for your website in Markdown files. -Whenever you commit to this repository, GitHub Pages will run [Jekyll](https://jekyllrb.com/) to rebuild the pages in your site, from the content in your Markdown files. +### Background -### Markdown -Markdown is a lightweight and easy-to-use syntax for styling your writing. It includes conventions for +While implementing a Tumblebit server in “classic tumbler” mode and after carefully reviewing **Fig 3 of the original white paper describing interactions between Tumbler and Bob**, I came to the conclusion that steps 2,3,4 and steps 6,7 could be simplified (step 5 and 9-12 are unchanged). -```markdown -Syntax highlighted code block +The objectives are +1. to stick to the most common cryptographic primitives (avoid Tumblebit-specific data formats) +2. reduce the amount of data flowing back and forth between Tumbler and Bob. +3. preserve the security and privay-protection proprerties of the original Tumblebit protocol -# Header 1 -## Header 2 -### Header 3 +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 addtional code. -- Bulleted -- List +### Proposal -1. Numbered -2. List -**Bold** and _Italic_ and `Code` text +Initially, before each payment phase, Tumbler generates a fresh ECDSA key pair (PKT, SKT). +Bob generates 2 key pairs, “real” (PKB, SKB) and “fake” (PKF, SKF). Bob keeps PKF secret for now and publishes PKB. -[Link](url) and ![Image](src) -``` +In Fig. 3 **step 2**, Bob generates 15 “real” payout addresses (keeps them secret for now) and prepares 15 distinct “real” transactions. +In **step 3**, Bob prepares 285 “fake” transactions like so: -For more details see [GitHub Flavored Markdown](https://guides.github.com/features/mastering-markdown/). +Fake transaction i pays Tumbler compressed Bitcoin address (corresponding to PKT) 1 BTC (no network fee bearing in mind the transaction will never hit the blockchain ) with an OP_RETURN output containing the hex string “H || i” where H is the hash160 corresponding to the public key PKB. +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 300 random pad values. Bob needs only to generate 2 regular, Bitcoin key pairs._ -### Jekyll Themes +Bob hides the transactions in 300 sighash values (regular Bitcoin sighash computations here) , permutes them (**Step 4**), and finally sends them to Tumbler as beta1, ..., beta300. +_Minimized data flow: no need for Bob to send to Tumbler any hR, hF_ -Your Pages site will use the layout and styles from the Jekyll theme you have selected in your [repository settings](https://github.com/pierrenoizat/tumblebit_tips/settings). The name of this theme is saved in the Jekyll `_config.yml` configuration file. +In Step 5, Tumbler signs each betai with SKT to create an ECDSA-Secp256k1 signature sigmai. +_No change from original white paper._ -### Support or Contact +**Step 6**: Bob sends to Tumbler the 15 “real” indices along with PKF +Minimized data flow: Bob sends a single public key PKF in lieu of salt value and 300 pad values. + +**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 with an OP_RETURN output bearing the hash160 digest corresponding to PKF. The hash160 is appended with i so that each i is a preimage of betai. +_No need for the CashOutTFormat nor the FakeFormat specified in the original white paper_ -Having trouble with Pages? Check out our [documentation](https://help.github.com/categories/github-pages-basics/) or [contact support](https://github.com/contact) and we’ll help you sort it out. From 806f09704fd1c488f12e3cf74d6d270ef83a7c25 Mon Sep 17 00:00:00 2001 From: Pierre Noizat Date: Wed, 18 Jan 2017 19:20:32 +0100 Subject: [PATCH 04/26] Update README.md --- README.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/README.md b/README.md index 7bea35c..6423496 100644 --- a/README.md +++ b/README.md @@ -1,3 +1,6 @@ +# Tumblebit Improvement Proposal (TIP) + + ## TIP 1 From 4b2b2b2f1c7536f4e350e21b4d7582c251e72c4f Mon Sep 17 00:00:00 2001 From: Pierre Noizat Date: Wed, 18 Jan 2017 19:22:23 +0100 Subject: [PATCH 05/26] Update README.md --- README.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index 6423496..7e578c4 100644 --- a/README.md +++ b/README.md @@ -36,9 +36,14 @@ In Step 5, Tumbler signs each betai with SKT to create an ECDSA-Secp256k1 signat _No change from original white paper._ **Step 6**: Bob sends to Tumbler the 15 “real” indices along with PKF -Minimized data flow: Bob sends a single public key PKF in lieu of salt value and 300 pad values. + +_Minimized data flow: Bob sends a single public key PKF in lieu of salt value and 300 pad values._ **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 with an OP_RETURN output bearing the hash160 digest corresponding to PKF. The hash160 is appended with i so that each i is a preimage of betai. + +betai = sighash value of tx paying Tumbler 1 BTC with an OP_RETURN output bearing the hash160 digest corresponding to PKF. + +The hash160 is appended with i so that each i is a preimage of betai. + _No need for the CashOutTFormat nor the FakeFormat specified in the original white paper_ From e4a27dab2306a25e1b0ff86ba7adc0430315eff6 Mon Sep 17 00:00:00 2001 From: Pierre Noizat Date: Wed, 18 Jan 2017 19:26:01 +0100 Subject: [PATCH 06/26] Update README.md --- README.md | 7 +++---- 1 file changed, 3 insertions(+), 4 deletions(-) diff --git a/README.md b/README.md index 7e578c4..41b1632 100644 --- a/README.md +++ b/README.md @@ -14,12 +14,14 @@ The objectives are 2. reduce the amount of data flowing back and forth between Tumbler and Bob. 3. 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 addtional code. +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 addtional code. ### Proposal Initially, before each payment phase, Tumbler generates a fresh ECDSA key pair (PKT, SKT). + Bob generates 2 key pairs, “real” (PKB, SKB) and “fake” (PKF, SKF). Bob keeps PKF secret for now and publishes PKB. In Fig. 3 **step 2**, Bob generates 15 “real” payout addresses (keeps them secret for now) and prepares 15 distinct “real” transactions. @@ -36,14 +38,11 @@ In Step 5, Tumbler signs each betai with SKT to create an ECDSA-Secp256k1 signat _No change from original white paper._ **Step 6**: Bob sends to Tumbler the 15 “real” indices along with PKF - _Minimized data flow: Bob sends a single public key PKF in lieu of salt value and 300 pad values._ **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 with an OP_RETURN output bearing the hash160 digest corresponding to PKF. The hash160 is appended with i so that each i is a preimage of betai. - _No need for the CashOutTFormat nor the FakeFormat specified in the original white paper_ From 393f9556d089ee35203fe72a58aa6baaf45dd215 Mon Sep 17 00:00:00 2001 From: Pierre Noizat Date: Wed, 18 Jan 2017 19:27:39 +0100 Subject: [PATCH 07/26] Update README.md --- README.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/README.md b/README.md index 41b1632..bffdf31 100644 --- a/README.md +++ b/README.md @@ -17,6 +17,7 @@ The objectives are 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 addtional code. + ### Proposal @@ -25,9 +26,11 @@ Initially, before each payment phase, Tumbler generates a fresh ECDSA key pair ( Bob generates 2 key pairs, “real” (PKB, SKB) and “fake” (PKF, SKF). Bob keeps PKF secret for now and publishes PKB. In Fig. 3 **step 2**, Bob generates 15 “real” payout addresses (keeps them secret for now) and prepares 15 distinct “real” transactions. + In **step 3**, Bob prepares 285 “fake” transactions like so: Fake transaction i pays Tumbler compressed Bitcoin address (corresponding to PKT) 1 BTC (no network fee bearing in mind the transaction will never hit the blockchain ) with an OP_RETURN output containing the hex string “H || i” where H is the hash160 corresponding to the public key PKB. + 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 300 random pad values. Bob needs only to generate 2 regular, Bitcoin key pairs._ @@ -37,7 +40,8 @@ _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. _No change from original white paper._ -**Step 6**: Bob sends to Tumbler the 15 “real” indices along with PKF +**Step 6**: Bob sends to Tumbler the 15 “real” indices along with PKF. + _Minimized data flow: Bob sends a single public key PKF in lieu of salt value and 300 pad values._ **Step 7**: Tumbler can now compute the “fake” sighash values and verify that they match the “fake” betai values: From 5ce5b5470c80948df4d16c6923fad0f93a61f6b1 Mon Sep 17 00:00:00 2001 From: Pierre Noizat Date: Wed, 18 Jan 2017 19:30:52 +0100 Subject: [PATCH 08/26] Update README.md --- README.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index bffdf31..ada05f2 100644 --- a/README.md +++ b/README.md @@ -7,7 +7,7 @@ ### Background -While implementing a Tumblebit server in “classic tumbler” mode and after carefully reviewing **Fig 3 of the original white paper describing interactions between Tumbler and Bob**, I came to the conclusion that steps 2,3,4 and steps 6,7 could be simplified (step 5 and 9-12 are unchanged). +While implementing a demo Tumblebit server in “classic tumbler” mode and after carefully reviewing **Fig 3 of the original white paper describing interactions between Tumbler and Bob**, I came to the conclusion that steps 2,3,4 and steps 6,7 could be simplified (step 5 and 9-12 are unchanged). The objectives are 1. to stick to the most common cryptographic primitives (avoid Tumblebit-specific data formats) @@ -29,12 +29,13 @@ In Fig. 3 **step 2**, Bob generates 15 “real” payout addresses (keeps them s In **step 3**, Bob prepares 285 “fake” transactions like so: -Fake transaction i pays Tumbler compressed Bitcoin address (corresponding to PKT) 1 BTC (no network fee bearing in mind the transaction will never hit the blockchain ) with an OP_RETURN output containing the hex string “H || i” where H is the hash160 corresponding to the public key PKB. +Fake transaction i pays Tumbler compressed Bitcoin address (corresponding to PKT) 1 BTC (no network fee bearing in mind the transaction will never hit the blockchain ) with an OP_RETURN output containing the hex string `H || i `where H is the hash160 corresponding to the public key PKB. 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 300 random pad values. Bob needs only to generate 2 regular, Bitcoin key pairs._ Bob hides the transactions in 300 sighash values (regular Bitcoin sighash computations here) , permutes them (**Step 4**), and finally sends them to Tumbler as beta1, ..., beta300. + _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. From b859661bd94459d8ad1bd032c996d437e121f6a2 Mon Sep 17 00:00:00 2001 From: Pierre Noizat Date: Wed, 18 Jan 2017 19:32:11 +0100 Subject: [PATCH 09/26] Update README.md --- README.md | 1 + 1 file changed, 1 insertion(+) diff --git a/README.md b/README.md index ada05f2..85a79c7 100644 --- a/README.md +++ b/README.md @@ -10,6 +10,7 @@ While implementing a demo Tumblebit server in “classic tumbler” mode and after carefully reviewing **Fig 3 of the original white paper describing interactions between Tumbler and Bob**, I came to the conclusion that steps 2,3,4 and steps 6,7 could be simplified (step 5 and 9-12 are unchanged). The objectives are + 1. to stick to the most common cryptographic primitives (avoid Tumblebit-specific data formats) 2. reduce the amount of data flowing back and forth between Tumbler and Bob. 3. preserve the security and privay-protection proprerties of the original Tumblebit protocol From e5dc87fa353202788593e2e897cd5c5a651e1b2c Mon Sep 17 00:00:00 2001 From: Pierre Noizat Date: Wed, 18 Jan 2017 19:32:38 +0100 Subject: [PATCH 10/26] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 85a79c7..4147385 100644 --- a/README.md +++ b/README.md @@ -11,7 +11,7 @@ While implementing a demo Tumblebit server in “classic tumbler” mode and aft The objectives are -1. to stick to the most common cryptographic primitives (avoid Tumblebit-specific data formats) +1. stick to the most common cryptographic primitives (avoid Tumblebit-specific data formats) 2. reduce the amount of data flowing back and forth between Tumbler and Bob. 3. preserve the security and privay-protection proprerties of the original Tumblebit protocol From d4d8aab0c0a7e7d228d1961be9cdb70e7d9beb9b Mon Sep 17 00:00:00 2001 From: Pierre Noizat Date: Wed, 18 Jan 2017 19:38:14 +0100 Subject: [PATCH 11/26] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 4147385..dda2ed2 100644 --- a/README.md +++ b/README.md @@ -30,7 +30,7 @@ In Fig. 3 **step 2**, Bob generates 15 “real” payout addresses (keeps them s In **step 3**, Bob prepares 285 “fake” transactions like so: -Fake transaction i pays Tumbler compressed Bitcoin address (corresponding to PKT) 1 BTC (no network fee bearing in mind the transaction will never hit the blockchain ) with an OP_RETURN output containing the hex string `H || i `where H is the hash160 corresponding to the public key PKB. +Fake transaction i pays Tumbler compressed Bitcoin address (corresponding to PKT) 1 BTC (no network fee bearing in mind the transaction will never hit the blockchain ) with an OP_RETURN output containing the hex string `H || i `where H is the hash160 corresponding to the public key PKF. 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 300 random pad values. Bob needs only to generate 2 regular, Bitcoin key pairs._ From 5c68daec14f944739c86d259d410db4f9dbf119c Mon Sep 17 00:00:00 2001 From: Pierre Noizat Date: Wed, 18 Jan 2017 19:39:35 +0100 Subject: [PATCH 12/26] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index dda2ed2..20d9c60 100644 --- a/README.md +++ b/README.md @@ -16,7 +16,7 @@ The objectives are 3. 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 addtional code. +wallet developpers should be able to use their favorite Bitcoin library with minimal additional code. ### Proposal From ed1a0ca0207a8339a0c32f0ed908ad86f62ec0d6 Mon Sep 17 00:00:00 2001 From: Pierre Noizat Date: Thu, 19 Jan 2017 19:03:54 +0100 Subject: [PATCH 13/26] Update README.md --- README.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/README.md b/README.md index 20d9c60..35357ca 100644 --- a/README.md +++ b/README.md @@ -7,7 +7,7 @@ ### Background -While implementing a demo Tumblebit server in “classic tumbler” mode and after carefully reviewing **Fig 3 of the original white paper describing interactions between Tumbler and Bob**, I came to the conclusion that steps 2,3,4 and steps 6,7 could be simplified (step 5 and 9-12 are unchanged). +While implementing a demo Tumblebit server in “classic tumbler” mode and after carefully reviewing **Fig 4 of the [white paper](https://eprint.iacr.org/2016/575.pdf) describing interactions between Tumbler and Bob**, I came to the conclusion that steps 2,3,4 and steps 6,7 could be simplified (step 5 and 9-12 are unchanged). The objectives are @@ -24,23 +24,23 @@ wallet developpers should be able to use their favorite Bitcoin library with min Initially, before each payment phase, Tumbler generates a fresh ECDSA key pair (PKT, SKT). -Bob generates 2 key pairs, “real” (PKB, SKB) and “fake” (PKF, SKF). Bob keeps PKF secret for now and publishes PKB. +Bob generates an ECDSA key pair,(PKB, SKB), for "real" transactions and picks a random 128-bit blinding factor R for “fake” transactions. Bob keeps R secret for now and publishes PKB. -In Fig. 3 **step 2**, Bob generates 15 “real” payout addresses (keeps them secret for now) and prepares 15 distinct “real” transactions. +In Fig. 4 **step 2**, Bob generates 15 “real” payout addresses (keeps them secret for now) and prepares 15 distinct “real” transactions. In **step 3**, Bob prepares 285 “fake” transactions like so: -Fake transaction i pays Tumbler compressed Bitcoin address (corresponding to PKT) 1 BTC (no network fee bearing in mind the transaction will never hit the blockchain ) with an OP_RETURN output containing the hex string `H || i `where H is the hash160 corresponding to the public key PKF. +Fake transaction i pays Tumbler compressed Bitcoin address (corresponding to PKT) 1 BTC (no network fee bearing in mind the transaction will never hit the blockchain ) with an OP_RETURN output containing the hex string `R || i `. 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 300 random pad values. Bob needs only to generate 2 regular, Bitcoin key pairs._ +_No need for Bob to generate (and later transmit to Tumbler) a set of 300 random pad values. Bob needs only to generate one regular, Bitcoin key pair and one random blinding factor._ Bob hides the transactions in 300 sighash values (regular Bitcoin sighash computations here) , permutes them (**Step 4**), and finally sends them to Tumbler as beta1, ..., beta300. _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. -_No change from original white paper._ +_No change from white paper._ **Step 6**: Bob sends to Tumbler the 15 “real” indices along with PKF. From 52c477421b07219438c84609dc6c1edd3d5a5f48 Mon Sep 17 00:00:00 2001 From: Pierre Noizat Date: Thu, 19 Jan 2017 19:20:01 +0100 Subject: [PATCH 14/26] Update README.md --- README.md | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 35357ca..382b9a7 100644 --- a/README.md +++ b/README.md @@ -30,7 +30,9 @@ In Fig. 4 **step 2**, Bob generates 15 “real” payout addresses (keeps them s In **step 3**, Bob prepares 285 “fake” transactions like so: -Fake transaction i pays Tumbler compressed Bitcoin address (corresponding to PKT) 1 BTC (no network fee bearing in mind the transaction will never hit the blockchain ) with an OP_RETURN output containing the hex string `R || i `. +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 + +`R || i ` 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 300 random pad values. Bob needs only to generate one regular, Bitcoin key pair and one random blinding factor._ @@ -42,13 +44,13 @@ _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. _No change from white paper._ -**Step 6**: Bob sends to Tumbler the 15 “real” indices along with PKF. +**Step 6**: Bob sends to Tumbler the 15 “real” indices along with blinding factor R. -_Minimized data flow: Bob sends a single public key PKF in lieu of salt value and 300 pad values._ +_Minimized data flow: Bob sends a single 128-bit blinding factor R in lieu of a salt value and 300 pad values._ **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 with an OP_RETURN output bearing the hash160 digest corresponding to PKF. +betai = sighash value of tx paying Tumbler 1 BTC in output 0 with an OP_RETURN output (output 1) bearing the hex string `R || i ` -The hash160 is appended with i so that each i is a preimage of betai. +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_ From ee8471f6932c39a87a31555a633004c9a9047301 Mon Sep 17 00:00:00 2001 From: Pierre Noizat Date: Fri, 20 Jan 2017 19:51:05 +0100 Subject: [PATCH 15/26] Update README.md --- README.md | 27 ++++++++++++++++++++++----- 1 file changed, 22 insertions(+), 5 deletions(-) diff --git a/README.md b/README.md index 382b9a7..f236733 100644 --- a/README.md +++ b/README.md @@ -24,7 +24,7 @@ wallet developpers should be able to use their favorite Bitcoin library with min 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 random 128-bit blinding factor R for “fake” transactions. Bob keeps R secret for now and publishes PKB. +Bob generates an ECDSA key pair,(PKB, SKB), for "real" transactions and picks a single random 128-bit blinding factor r for “fake” transactions. Bob keeps r secret for now and publishes PKB. In Fig. 4 **step 2**, Bob generates 15 “real” payout addresses (keeps them secret for now) and prepares 15 distinct “real” transactions. @@ -32,7 +32,7 @@ In **step 3**, Bob prepares 285 “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 -`R || i ` +`r || i ` 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 300 random pad values. Bob needs only to generate one regular, Bitcoin key pair and one random blinding factor._ @@ -44,13 +44,30 @@ _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. _No change from white paper._ -**Step 6**: Bob sends to Tumbler the 15 “real” indices along with blinding factor R. +**Step 6**: Bob sends to Tumbler the 15 “real” indices along with blinding factor r. -_Minimized data flow: Bob sends a single 128-bit blinding factor R in lieu of a salt value and 300 pad values._ +_Minimized data flow: Bob sends a single 128-bit blinding factor r in lieu of a salt value and 285 pad values._ + +| Original | Size | TIP 1 | Size | +| ------------- |:-----------:| ------------:| ----------- | +| R, F | < 64 bytes | R, F | < 64 bytes | +| hR, hF | 64 bytes | | | +| salt | 16 bytes | | | +| 285 random r | 4560 bytes | one random r | 16 bytes | +| ------------- |:-----------:| ------------:| ----------- | +| Total | 4704 bytes | | 80 bytes **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 `R || i ` +betai = sighash value of tx paying Tumbler 1 BTC in output 0 with an OP_RETURN output (output 1) bearing the hex string + +`r || i ` 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, + +1. the amount of data sent by Bob to Tumbler in steps 4 and 6 is reduced by 98% or 4624 bytes from the original protocol design. +2. the need for specific formats like CashOutTFormat and FakeFormat is avoided so a regular Bitcoin library is sufficient to build a wallet implementation. From 121701472f0030ebae843610425cc516986267c1 Mon Sep 17 00:00:00 2001 From: Pierre Noizat Date: Fri, 20 Jan 2017 19:52:45 +0100 Subject: [PATCH 16/26] Update README.md --- README.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index f236733..23854d1 100644 --- a/README.md +++ b/README.md @@ -48,14 +48,15 @@ _No change from white paper._ _Minimized data flow: Bob sends a single 128-bit blinding factor r in lieu of a salt value and 285 pad values._ + | Original | Size | TIP 1 | Size | | ------------- |:-----------:| ------------:| ----------- | | R, F | < 64 bytes | R, F | < 64 bytes | | hR, hF | 64 bytes | | | | salt | 16 bytes | | | | 285 random r | 4560 bytes | one random r | 16 bytes | -| ------------- |:-----------:| ------------:| ----------- | -| Total | 4704 bytes | | 80 bytes +| Total | 4704 bytes | Total | 80 bytes | + **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 From 77ee5099c822f0dd88094f4aa9df908d9beb0737 Mon Sep 17 00:00:00 2001 From: Pierre Noizat Date: Fri, 20 Jan 2017 19:55:12 +0100 Subject: [PATCH 17/26] Update README.md --- README.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/README.md b/README.md index 23854d1..21d8a92 100644 --- a/README.md +++ b/README.md @@ -49,13 +49,13 @@ _No change from white paper._ _Minimized data flow: Bob sends a single 128-bit blinding factor r in lieu of a salt value and 285 pad values._ -| Original | Size | TIP 1 | Size | -| ------------- |:-----------:| ------------:| ----------- | -| R, F | < 64 bytes | R, F | < 64 bytes | -| hR, hF | 64 bytes | | | -| salt | 16 bytes | | | -| 285 random r | 4560 bytes | one random r | 16 bytes | -| Total | 4704 bytes | Total | 80 bytes | +| Original | Size | TIP 1 | Size | +| ------------- |:------------:| ------------ |:-----------:| +| R, F | < 64 bytes | R, F | < 64 bytes | +| hR, hF | 64 bytes | | | +| salt | 16 bytes | | | +| 285 random r | 4560 bytes | one random r | 16 bytes | +| Total |**4704 bytes**| Total |**80 bytes** | **Step 7**: Tumbler can now compute the “fake” sighash values and verify that they match the “fake” betai values: From c2ce24fcf3eb06ca32d4b915c67fab45e6801d6b Mon Sep 17 00:00:00 2001 From: Pierre Noizat Date: Fri, 20 Jan 2017 20:10:27 +0100 Subject: [PATCH 18/26] Update README.md --- README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/README.md b/README.md index 21d8a92..fd1d615 100644 --- a/README.md +++ b/README.md @@ -70,5 +70,5 @@ _No need for the CashOutTFormat nor the FakeFormat specified in the original whi With this proposal, -1. the amount of data sent by Bob to Tumbler in steps 4 and 6 is reduced by 98% or 4624 bytes from the original protocol design. +1. the amount of data sent by Bob to Tumbler in steps 4 and 6 is reduced by 4624 bytes, that is a 20-25% redcution of the total data flow in the interactions between Bob and Tumbler. 2. the need for specific formats like CashOutTFormat and FakeFormat is avoided so a regular Bitcoin library is sufficient to build a wallet implementation. From 02a7bc6f06acb212d224a2e95b5e1cdd80354b17 Mon Sep 17 00:00:00 2001 From: Pierre Noizat Date: Mon, 23 Jan 2017 15:17:38 +0100 Subject: [PATCH 19/26] Update README.md --- README.md | 36 ++++++++++++++++++++---------------- 1 file changed, 20 insertions(+), 16 deletions(-) diff --git a/README.md b/README.md index fd1d615..b09247f 100644 --- a/README.md +++ b/README.md @@ -24,38 +24,42 @@ wallet developpers should be able to use their favorite Bitcoin library with min 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 128-bit blinding factor r for “fake” transactions. Bob keeps r secret for now and publishes PKB. +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 15 “real” payout addresses (keeps them secret for now) and prepares 15 distinct “real” transactions. +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 285 “fake” transactions like so: +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 `r || i ` 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 300 random pad values. Bob needs only to generate one regular, Bitcoin key pair and one random blinding factor._ +_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 300 sighash values (regular Bitcoin sighash computations here) , permutes them (**Step 4**), and finally sends them to Tumbler as beta1, ..., beta300. +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. _No change from white paper._ -**Step 6**: Bob sends to Tumbler the 15 “real” indices along with blinding factor r. +**Step 6**: Bob sends to Tumbler the 42 “real” indices along with blinding factor r. -_Minimized data flow: Bob sends a single 128-bit blinding factor r in lieu of a salt value and 285 pad values._ +_Minimized data flow: Bob sends a single 256-bit blinding factor r in lieu of a salt value and 42 pad values._ -| Original | Size | TIP 1 | Size | -| ------------- |:------------:| ------------ |:-----------:| -| R, F | < 64 bytes | R, F | < 64 bytes | -| hR, hF | 64 bytes | | | -| salt | 16 bytes | | | -| 285 random r | 4560 bytes | one random r | 16 bytes | -| Total |**4704 bytes**| Total |**80 bytes** | +| Original | Size | TIP 1 | Size | +| ---------------- |:-------------:| ------------ |:-------------:| +| 84 Betas | 2688 Bytes | | 2688 Bytes | +| hR,hF | 64 Bytes | | 0 | +| 84 (z,c) couples | 26880 Bytes | | 24192 Bytes | +| Salt | 32 bytes | | 0 | +| 42 random r | 1344 Bytes | One random r | 32 Bytes | +| 41 Quotients | 10496 Bytes | | 10496 Bytes | +| 42 Epsilons | 10752 Bytes | | 1344 Bytes | +| Total |**52256 Bytes**| |**38752 Bytes**| +| Reduction | | |**26%** | **Step 7**: Tumbler can now compute the “fake” sighash values and verify that they match the “fake” betai values: @@ -63,12 +67,12 @@ betai = sighash value of tx paying Tumbler 1 BTC in output 0 with an OP_RETURN o `r || i ` -The i index is appended to R so that each i is a preimage of betai. +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, -1. the amount of data sent by Bob to Tumbler in steps 4 and 6 is reduced by 4624 bytes, that is a 20-25% redcution of the total data flow in the interactions between Bob and Tumbler. +1. 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. 2. the need for specific formats like CashOutTFormat and FakeFormat is avoided so a regular Bitcoin library is sufficient to build a wallet implementation. From 6cb1fc723aba08928bbae509e0d6115019dc75ef Mon Sep 17 00:00:00 2001 From: Pierre Noizat Date: Tue, 24 Jan 2017 09:29:51 +0100 Subject: [PATCH 20/26] Update README.md --- README.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/README.md b/README.md index b09247f..753bca1 100644 --- a/README.md +++ b/README.md @@ -7,7 +7,7 @@ ### Background -While implementing a demo Tumblebit server in “classic tumbler” mode and after carefully reviewing **Fig 4 of the [white paper](https://eprint.iacr.org/2016/575.pdf) describing interactions between Tumbler and Bob**, I came to the conclusion that steps 2,3,4 and steps 6,7 could be simplified (step 5 and 9-12 are unchanged). +While implementing a demo Tumblebit server in “classic tumbler” mode and after carefully reviewing **Fig 4 of the [white paper](https://eprint.iacr.org/2016/575.pdf) 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 @@ -41,8 +41,9 @@ Bob hides the transactions in 84 sighash values (regular Bitcoin sighash computa _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. -_No change from white paper._ +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. From 282e1dd854ce28c2819da5e75db9c3e52c21ff8c Mon Sep 17 00:00:00 2001 From: Pierre Noizat Date: Mon, 20 Mar 2017 20:04:35 +0100 Subject: [PATCH 21/26] Update README.md --- README.md | 78 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 78 insertions(+) diff --git a/README.md b/README.md index 0283bf5..7544a29 100644 --- a/README.md +++ b/README.md @@ -1,2 +1,80 @@ # TIP TumbleBit Improvement Proposal + + +## TIP 1 + + +### Background + + +While implementing a demo Tumblebit server in “classic tumbler” mode and after carefully reviewing **Fig 4 of the [white paper](https://eprint.iacr.org/2016/575.pdf) 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 + +1. stick to the most common cryptographic primitives (avoid Tumblebit-specific data formats) +2. reduce the amount of data flowing back and forth between Tumbler and Bob. +3. 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 + +`r || i ` + +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 | Size | TIP 1 | Size | +| ---------------- |:-------------:| ------------ |:-------------:| +| 84 Betas | 2688 Bytes | | 2688 Bytes | +| hR,hF | 64 Bytes | | 0 | +| 84 (z,c) couples | 26880 Bytes | | 24192 Bytes | +| Salt | 32 bytes | | 0 | +| 42 random r | 1344 Bytes | One random r | 32 Bytes | +| 41 Quotients | 10496 Bytes | | 10496 Bytes | +| 42 Epsilons | 10752 Bytes | | 1344 Bytes | +| Total |**52256 Bytes**| |**38752 Bytes**| +| Reduction | | |**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 + +`r || i ` + +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, + +1. 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. +2. the need for specific formats like CashOutTFormat and FakeFormat is avoided so a regular Bitcoin library is sufficient to build a wallet implementation. From 3b3f1f7a12e2d00800b85d7e11c52da414da450d Mon Sep 17 00:00:00 2001 From: Pierre Noizat Date: Wed, 22 Mar 2017 11:32:03 +0100 Subject: [PATCH 22/26] Update to match bitcoin bip style url --- README.md => tip-0001.mediawiki | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename README.md => tip-0001.mediawiki (100%) diff --git a/README.md b/tip-0001.mediawiki similarity index 100% rename from README.md rename to tip-0001.mediawiki From e7f00275f3f1a7b3d95b9ec95f2d5f13f7c70030 Mon Sep 17 00:00:00 2001 From: Pierre Noizat Date: Wed, 22 Mar 2017 11:36:09 +0100 Subject: [PATCH 23/26] converted from markdown to mediawiki --- tip-0001.mediawiki | 90 ++++++++++++++++++---------------------------- 1 file changed, 35 insertions(+), 55 deletions(-) diff --git a/tip-0001.mediawiki b/tip-0001.mediawiki index 753bca1..0ba4121 100644 --- a/tip-0001.mediawiki +++ b/tip-0001.mediawiki @@ -1,79 +1,59 @@ -# Tumblebit Improvement Proposal (TIP) += Tumblebit Improvement Proposal (TIP) = +== TIP 1 == -## 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). -### Background +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 -While implementing a demo Tumblebit server in “classic tumbler” mode and after carefully reviewing **Fig 4 of the [white paper](https://eprint.iacr.org/2016/575.pdf) 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 - -1. stick to the most common cryptographic primitives (avoid Tumblebit-specific data formats) -2. reduce the amount of data flowing back and forth between Tumbler and Bob. -3. 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 +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. +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 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: +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 -`r || i ` - -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._ +r || i +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.'' -| Original | Size | TIP 1 | Size | -| ---------------- |:-------------:| ------------ |:-------------:| -| 84 Betas | 2688 Bytes | | 2688 Bytes | -| hR,hF | 64 Bytes | | 0 | -| 84 (z,c) couples | 26880 Bytes | | 24192 Bytes | -| Salt | 32 bytes | | 0 | -| 42 random r | 1344 Bytes | One random r | 32 Bytes | -| 41 Quotients | 10496 Bytes | | 10496 Bytes | -| 42 Epsilons | 10752 Bytes | | 1344 Bytes | -| Total |**52256 Bytes**| |**38752 Bytes**| -| Reduction | | |**26%** | +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'' -**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 +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'' -`r || i ` +'''Step 6''': Bob sends to Tumbler the 42 “real” indices along with blinding factor r. -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_ +''Minimized data flow: Bob sends a single 256-bit blinding factor r in lieu of a salt value and 42 pad values.'' -**Conclusion** +{| +! Original +!align="center"| Size +! TIP 1 +!align="center"| Size +|- +| 84 Betas +|align="center"| 2688 Bytes +| -With this proposal, +|align="center"| 2688 Bytes +|- +| hR,hF +|align="center"| 64 Bytes +| -1. 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. -2. the need for specific formats like CashOutTFormat and FakeFormat is avoided so a regular Bitcoin library is sufficient to build a wallet implementation. +|} From 4257e33a9e63bd205450480c7112e64183c6a80b Mon Sep 17 00:00:00 2001 From: Pierre Noizat Date: Wed, 22 Mar 2017 11:48:32 +0100 Subject: [PATCH 24/26] Update with table --- tip-0001.mediawiki | 56 ++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 56 insertions(+) diff --git a/tip-0001.mediawiki b/tip-0001.mediawiki index 0ba4121..147c228 100644 --- a/tip-0001.mediawiki +++ b/tip-0001.mediawiki @@ -56,4 +56,60 @@ In '''Step 5''', Tumbler signs each betai with SKT to create an ECDSA-Secp256k1 |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 + +r || i + +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. From 987e0863dba1bbd72d5c2c65ec818fd2993bf678 Mon Sep 17 00:00:00 2001 From: Pierre Noizat Date: Wed, 22 Mar 2017 11:55:34 +0100 Subject: [PATCH 25/26] Removed Unneeded Yaml file --- _config.yml | 1 - 1 file changed, 1 deletion(-) delete mode 100644 _config.yml diff --git a/_config.yml b/_config.yml deleted file mode 100644 index 2f7efbe..0000000 --- a/_config.yml +++ /dev/null @@ -1 +0,0 @@ -theme: jekyll-theme-minimal \ No newline at end of file From d02ddebeb85d0f9432a2839a084e7fbd87b6feb1 Mon Sep 17 00:00:00 2001 From: Pierre Noizat Date: Wed, 22 Mar 2017 12:00:17 +0100 Subject: [PATCH 26/26] Moved to Mediawiki format --- README.md | 80 ------------------------------------------------------- 1 file changed, 80 deletions(-) delete mode 100644 README.md diff --git a/README.md b/README.md deleted file mode 100644 index 7544a29..0000000 --- a/README.md +++ /dev/null @@ -1,80 +0,0 @@ -# TIP -TumbleBit Improvement Proposal - - -## TIP 1 - - -### Background - - -While implementing a demo Tumblebit server in “classic tumbler” mode and after carefully reviewing **Fig 4 of the [white paper](https://eprint.iacr.org/2016/575.pdf) 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 - -1. stick to the most common cryptographic primitives (avoid Tumblebit-specific data formats) -2. reduce the amount of data flowing back and forth between Tumbler and Bob. -3. 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 - -`r || i ` - -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 | Size | TIP 1 | Size | -| ---------------- |:-------------:| ------------ |:-------------:| -| 84 Betas | 2688 Bytes | | 2688 Bytes | -| hR,hF | 64 Bytes | | 0 | -| 84 (z,c) couples | 26880 Bytes | | 24192 Bytes | -| Salt | 32 bytes | | 0 | -| 42 random r | 1344 Bytes | One random r | 32 Bytes | -| 41 Quotients | 10496 Bytes | | 10496 Bytes | -| 42 Epsilons | 10752 Bytes | | 1344 Bytes | -| Total |**52256 Bytes**| |**38752 Bytes**| -| Reduction | | |**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 - -`r || i ` - -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, - -1. 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. -2. the need for specific formats like CashOutTFormat and FakeFormat is avoided so a regular Bitcoin library is sufficient to build a wallet implementation.