diff options
| author | Tony Churyumoff <tony991@gmail.com> | 2016-08-09 02:42:03 +0300 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-08-08 23:42:07 +0000 |
| commit | 171874938e4b7141d1c324d4d544b1e2b001310d (patch) | |
| tree | fdf597695e2f5266e843fcbf854dc2ef2adc255a /d2 | |
| parent | f2fa73af8032fd4c40db82b493b217d7ea82972d (diff) | |
| download | pi-bitcoindev-171874938e4b7141d1c324d4d544b1e2b001310d.tar.gz pi-bitcoindev-171874938e4b7141d1c324d4d544b1e2b001310d.zip | |
Re: [bitcoin-dev] Hiding entire content of on-chain transactions
Diffstat (limited to 'd2')
| -rw-r--r-- | d2/1de857418af2fd015ec2bb025bbc1774d6e758 | 762 |
1 files changed, 762 insertions, 0 deletions
diff --git a/d2/1de857418af2fd015ec2bb025bbc1774d6e758 b/d2/1de857418af2fd015ec2bb025bbc1774d6e758 new file mode 100644 index 000000000..6d25525c7 --- /dev/null +++ b/d2/1de857418af2fd015ec2bb025bbc1774d6e758 @@ -0,0 +1,762 @@ +Return-Path: <tony991@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 4D7F892 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 8 Aug 2016 23:42:07 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 53CF71BA + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 8 Aug 2016 23:42:05 +0000 (UTC) +Received: by mail-wm0-f47.google.com with SMTP id f65so2661791wmi.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 08 Aug 2016 16:42:05 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=mime-version:reply-to:in-reply-to:references:from:date:message-id + :subject:to:cc; + bh=fnKX9GJlq/q0yBSnqAkYTf9FCODcAQiSmNYzuNILKlY=; + b=XjIDcr7kvAp57LrMsw5UQ5xQzZrisyGycdXjCeCI7ZqUvQ2GbiCyVebGSY4rg7qpo+ + hVLDVTqKqT7dYA6LV5LJKrHcD3ExNDUp9+czTAS2rWiDInsYWkyBRqyyume6v1qva1Iz + /F8T+tPRzffpBUF+UVz84cNfEFNZXSm2Y/x0GVNmY6XG2+aZCI08lAjr+vS07vp8EJbX + fiygY/GVEQ4fAOCutnteHoe5MLBL9GBhWG+gT1v0gZkZnWhBoIEK1vovNxfACaFQwetL + 8GWCvIsAlKVyv3Gji3aFLH0gkO7HZ7Bh4uwvZvH12KzFvJSPRlDVZHc+age2ydy9C6l4 + afeg== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:mime-version:reply-to:in-reply-to:references + :from:date:message-id:subject:to:cc; + bh=fnKX9GJlq/q0yBSnqAkYTf9FCODcAQiSmNYzuNILKlY=; + b=gIAcjUXffTInVOf9OK6DQxsjo2Y/MhrP8pCWkiKBYmaGkv+HnYFkJFL+mqvKzBvDGw + rsxGQ4SYdVYDs7+H/6T6OoSAsiF2xvxzCL/ZPfaWhYSJpaowGSp5Pf3XrbaSAPNofYVt + h6Cv7vaT5v0mt817JGiPNuufiutTeWEeVRfuiabGNqbGBxVRA6BXdp3N8j66E1T4a/9v + 7cO+G8yDYYvMbDHUrhNw6wkbnoMt6mtXrGBL1UJAHPETSNoVEzW7oExo9LK8lIcK0yB1 + W1s9k8R1xknguhuzRoTAKQA7OWe7kroT8LQZA8Z3P+vtmxMGk4LZe4lcIXUe3KZvBuzy + qe1Q== +X-Gm-Message-State: AEkooutsS3O2goPPer1iO0kOMITKxdaYayuT8VUj8MhDmVDm8fLAd8i1eTgJA0Wo/wAXagOPn1OW77FBH5ByiQ== +X-Received: by 10.194.148.19 with SMTP id to19mr96033630wjb.81.1470699723858; + Mon, 08 Aug 2016 16:42:03 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.194.100.161 with HTTP; Mon, 8 Aug 2016 16:42:03 -0700 (PDT) +Reply-To: tony.991@gmail.com +In-Reply-To: <CAH+Axy6yJ3WotKjsMjo3o23V5Du1nniu8Bzd3gxYX5OuqeB6gw@mail.gmail.com> +References: <CAL3p6zpADtYFQnQUr3Efk6V59+K+bB3tPQQMGT9weiafU=43zA@mail.gmail.com> + <20160808154707.GB2196@banane.informatik.uni-ulm.de> + <CAL3p6zo1xBEu90MDHSK4TNX0DL2QXxq5vC48a2cFnX0JCD=RvQ@mail.gmail.com> + <CAH+Axy6yJ3WotKjsMjo3o23V5Du1nniu8Bzd3gxYX5OuqeB6gw@mail.gmail.com> +From: Tony Churyumoff <tony991@gmail.com> +Date: Tue, 9 Aug 2016 02:42:03 +0300 +Message-ID: <CAL3p6zp5wcr4bK13n1F51XeKPahjUTNUziZq2MN7PRDA_BzGBg@mail.gmail.com> +To: James MacWhyte <macwhyte@gmail.com> +Content-Type: multipart/alternative; boundary=089e01177b199ceb70053997f699 +X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, + FREEMAIL_REPLYTO, HTML_MESSAGE, + RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Tue, 09 Aug 2016 03:06:22 +0000 +Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Subject: Re: [bitcoin-dev] Hiding entire content of on-chain transactions +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Mon, 08 Aug 2016 23:42:07 -0000 + +--089e01177b199ceb70053997f699 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +The whole point is in preventing every third party, including miners, from +seeing the details of what is being spent and how. The burden of +verification is shifted to the owners of the coin (which is fair). + +In fact we could have miners recognize spend proofs and check that the same +spend proof is not entered into the blockchain more than once (which would +be a sign of double spend), but it is not required. The coin owners can +already do that themselves. + +2016-08-09 0:41 GMT+03:00 James MacWhyte <macwhyte@gmail.com>: + +> Wouldn't you lose the ability to assume transactions in the blockchain ar= +e +> verified as valid, since miners can't see the details of what is being +> spent and how? I feel like this ability is bitcoin's greatest asset, and = +by +> removing it you're creating an altcoin different enough to not be connect= +ed +> to/supported by the main bitcoin project. +> +> On Mon, Aug 8, 2016, 09:13 Tony Churyumoff via bitcoin-dev < +> bitcoin-dev@lists.linuxfoundation.org> wrote: +> +>> Hi Henning, +>> +>> 1. The fees are paid by the enclosing BTC transaction. +>> 2. The hash is encoded into an OP_RETURN. +>> +>> > Regarding the blinding factor, I think you could just use HMAC. +>> How exactly? +>> +>> Tony +>> +>> +>> 2016-08-08 18:47 GMT+03:00 Henning Kopp <henning.kopp@uni-ulm.de>: +>> +>>> Hi Tony, +>>> +>>> I see some issues in your protocol. +>>> +>>> 1. How are mining fees handled? +>>> +>>> 2. Assume Alice sends Bob some Coins together with their history and +>>> Bob checks that the history is correct. How does the hash of the txout +>>> find its way into the blockchain? +>>> +>>> Regarding the blinding factor, I think you could just use HMAC. +>>> +>>> All the best +>>> Henning +>>> +>>> +>>> On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via +>>> bitcoin-dev wrote: +>>> > This is a proposal about hiding the entire content of bitcoin +>>> > transactions. It goes farther than CoinJoin and ring signatures, whi= +ch +>>> > only obfuscate the transaction graph, and Confidential Transactions, +>>> which +>>> > only hide the amounts. +>>> > +>>> > The central idea of the proposed design is to hide the entire inputs +>>> and +>>> > outputs, and publish only the hash of inputs and outputs in the +>>> > blockchain. The hash can be published as OP_RETURN. The plaintext o= +f +>>> > inputs and outputs is sent directly to the payee via a private +>>> message, and +>>> > never goes into the blockchain. The payee then calculates the hash a= +nd +>>> > looks it up in the blockchain to verify that the hash was indeed +>>> published +>>> > by the payer. +>>> > +>>> > Since the plaintext of the transaction is not published to the public +>>> > blockchain, all validation work has to be done only by the user who +>>> > receives the payment. +>>> > +>>> > To protect against double-spends, the payer also has to publish anoth= +er +>>> > hash, which is the hash of the output being spent. We=E2=80=99ll cal= +l this +>>> hash *spend +>>> > proof*. Since the spend proof depends solely on the output being +>>> spent, +>>> > any attempt to spend the same output again will produce exactly the +>>> same +>>> > spend proof, and the payee will be able to see that, and will reject +>>> the +>>> > payment. If there are several outputs consumed by the same +>>> transaction, +>>> > the payer has to publish several spend proofs. +>>> > +>>> > To prove that the outputs being spent are valid, the payer also has t= +o +>>> send +>>> > the plaintexts of the earlier transaction(s) that produced them, then +>>> the +>>> > plaintexts of even earlier transactions that produced the outputs +>>> spent in +>>> > those transactions, and so on, up until the issue (similar to coinbas= +e) +>>> > transactions that created the initial private coins. Each new owner +>>> of the +>>> > coin will have to store its entire history, and when he spends the +>>> coin, he +>>> > forwards the entire history to the next owner and extends it with his +>>> own +>>> > transaction. +>>> > +>>> > If we apply the existing bitcoin design that allows multiple inputs a= +nd +>>> > multiple outputs per transaction, the history of ownership transfers +>>> would +>>> > grow exponentially. Indeed, if we take any regular bitcoin output an= +d +>>> try +>>> > to track its history back to coinbase, our history will branch every +>>> time +>>> > we see a transaction that has more than one input (which is not +>>> uncommon). +>>> > After such a transaction (remember, we are traveling back in time), +>>> we=E2=80=99ll +>>> > have to track two or more histories, for each respective input. Thos= +e +>>> > histories will branch again, and the total number of history entries +>>> grows +>>> > exponentially. For example, if every transaction had exactly two +>>> inputs, +>>> > the size of history would grow as 2^N where N is the number of steps +>>> back +>>> > in history. +>>> > +>>> > To avoid such rapid growth of ownership history (which is not only +>>> > inconvenient to move, but also exposes too much private information +>>> about +>>> > previous owners of all the contributing coins), we will require each +>>> > private transaction to have exactly one input (i.e. to consume exactl= +y +>>> one +>>> > previous output). This means that when we track a coin=E2=80=99s his= +tory back +>>> in +>>> > time, it will no longer branch. It will grow linearly with the numbe= +r +>>> of +>>> > transfers of ownership. If a user wants to combine several inputs, h= +e +>>> will +>>> > have to send them as separate private transactions (technically, +>>> several +>>> > OP_RETURNs, which can be included in a single regular bitcoin +>>> transaction). +>>> > +>>> > Thus, we are now forbidding any coin merges but still allowing coin +>>> > splits. To avoid ultimate splitting into the dust, we will also +>>> require +>>> > that all private coins be issued in one of a small number of +>>> > denominations. Only integer number of =E2=80=9Cbanknotes=E2=80=9D ca= +n be transferred, +>>> the +>>> > input and output amounts must therefore be divisible by the +>>> denomination. +>>> > For example, an input of amount 700, denomination 100, can be split +>>> into +>>> > outputs 400 and 300, but not into 450 and 250. To send a payment, th= +e +>>> > payer has to pick the unspent outputs of the highest denomination +>>> first, +>>> > then the second highest, and so on, like we already do when we pay in +>>> cash. +>>> > +>>> > With fixed denominations and one input per transaction, coin historie= +s +>>> > still grow, but only linearly, which should not be a concern in regar= +d +>>> to +>>> > scalability given that all relevant computing resources still grow +>>> > exponentially. The histories need to be stored only by the current +>>> owner +>>> > of the coin, not every bitcoin node. This is a fairer allocation of +>>> > costs. Regarding privacy, coin histories do expose private +>>> transactions +>>> > (or rather parts thereof, since a typical payment will likely consist +>>> of +>>> > several transactions due to one-input-per-transaction rule) of past +>>> coin +>>> > owners to the future ones, and that exposure grows linearly with time= +, +>>> but +>>> > it is still much much better than having every transaction immediatel= +y +>>> on +>>> > the public blockchain. Also, the value of this information for +>>> potential +>>> > adversaries arguably decreases with time. +>>> > +>>> > There is one technical nuance that I omitted above to avoid +>>> distraction. +>>> > Unlike regular bitcoin transactions, every output in a private payme= +nt +>>> > must also include a blinding factor, which is just a random string. +>>> When +>>> > the output is spent, the corresponding spend proof will therefore +>>> depend on +>>> > this blinding factor (remember that spend proof is just a hash of the +>>> > output). Without a blinding factor, it would be feasible to pre-imag= +e +>>> the +>>> > spend proof and reveal the output being spent as the search space of +>>> all +>>> > possible outputs is rather small. +>>> > +>>> > To issue the new private coin, one can burn regular BTC by sending it +>>> to +>>> > one of several unspendable bitcoin addresses, one address per +>>> denomination. +>>> > Burning BTC would entitle one to an equal amount of the new private +>>> coin, +>>> > let=E2=80=99s call it *black bitcoin*, or *BBC*. +>>> > +>>> > Then BBC would be transferred from user to user by: +>>> > 1. creating a private transaction, which consists of one input and +>>> several +>>> > outputs; +>>> > 2. storing the hash of the transaction and the spend proof of the +>>> consumed +>>> > output into the blockchain in an OP_RETURN (the sender pays the +>>> > corresponding fees in regular BTC) +>>> > 3. sending the transaction, together with the history leading to its +>>> input, +>>> > directly to the payee over a private communication channel. The firs= +t +>>> > entry of the history must be a bitcoin transaction that burned BTC to +>>> issue +>>> > an equal amount of BCC. +>>> > +>>> > To verify the payment, the payee: +>>> > 1. makes sure that the amount of the input matches the sum of outputs= +, +>>> and +>>> > all are divisible by the denomination +>>> > 2. calculates the hash of the private transaction +>>> > 3. looks up an OP_RETURN that includes this hash and is signed by the +>>> > payee. If there is more than one, the one that comes in the earlier +>>> block +>>> > prevails. +>>> > 4. calculates the spend proof and makes sure that it is included in t= +he +>>> > same OP_RETURN +>>> > 5. makes sure the same spend proof is not included anywhere in the +>>> same or +>>> > earlier blocks (that is, the coin was not spent before). Only +>>> transactions +>>> > by the same author are searched. +>>> > 6. repeats the same steps for every entry in the history, except the +>>> first +>>> > entry, which should be a valid burning transaction. +>>> > +>>> > To facilitate exchange of private transaction data, the bitcoin netwo= +rk +>>> > protocol can be extended with a new message type. Unfortunately, it +>>> lacks +>>> > encryption, hence private payments are really private only when +>>> bitcoin is +>>> > used over tor. +>>> > +>>> > There are a few limitations that ought to be mentioned: +>>> > 1. After user A sends a private payment to user B, user A will know +>>> what +>>> > the spend proof is going to be when B decides to spend the coin. +>>> > Therefore, A will know when the coin was spent by B, but nothing mor= +e. +>>> > Neither the new owner of the coin, nor its future movements will be +>>> known +>>> > to A. +>>> > 2. Over time, larger outputs will likely be split into many smaller +>>> > outputs, whose amounts are not much greater than their denominations. +>>> > You=E2=80=99ll have to combine more inputs to send the same amount. = +When you +>>> want +>>> > to send a very large amount that is much greater than the highest +>>> available +>>> > denomination, you=E2=80=99ll have to send a lot of private transactio= +ns, your +>>> > bitcoin transaction with so many OP_RETURNs will stand out, and their +>>> > number will roughly indicate the total amount. This kind of privacy +>>> > leakage, however it applies to a small number of users, is easy to +>>> avoid by +>>> > using multiple addresses and storing a relatively small amount on eac= +h +>>> > address. +>>> > 3. Exchanges and large merchants will likely accumulate large coin +>>> > histories. Although fragmented, far from complete, and likely +>>> outdated, it +>>> > is still something to bear in mind. +>>> > +>>> > No hard or soft fork is required, BBC is just a separate privacy +>>> preserving +>>> > currency on top of bitcoin blockchain, and the same private keys and +>>> > addresses are used for both BBC and the base currency BTC. Every BCC +>>> > transaction must be enclosed into by a small BTC transaction that +>>> stores +>>> > the OP_RETURNs and pays for the fees. +>>> > +>>> > Are there any flaws in this design? +>>> > +>>> > Originally posted to BCT https://bitcointalk.org/index. +>>> php?topic=3D1574508.0, +>>> > but got no feedback so far, apparently everybody was consumed with +>>> bitfinex +>>> > drama and now mimblewimble. +>>> > +>>> > Tony +>>> +>>> > _______________________________________________ +>>> > bitcoin-dev mailing list +>>> > bitcoin-dev@lists.linuxfoundation.org +>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>>> +>>> +>>> -- +>>> Henning Kopp +>>> Institute of Distributed Systems +>>> Ulm University, Germany +>>> +>>> Office: O27 - 3402 +>>> Phone: +49 731 50-24138 +>>> Web: http://www.uni-ulm.de/in/vs/~kopp +>>> +>> +>> _______________________________________________ +>> bitcoin-dev mailing list +>> bitcoin-dev@lists.linuxfoundation.org +>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev +>> +> + +--089e01177b199ceb70053997f699 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">The whole point is in preventing every third party, includ= +ing miners, from seeing=C2=A0<span style=3D"font-size:12.8px">the details o= +f what is being spent and how.=C2=A0 The burden of verification is shifted = +to the owners of the coin (which is fair).</span><div><span style=3D"font-s= +ize:12.8px"><br></span></div><div><span style=3D"font-size:12.8px">In fact = +we could have miners recognize spend proofs and check that the same spend p= +roof is not entered into the blockchain more than once (which would be a si= +gn of double spend), but it is not required.=C2=A0 The coin owners can alre= +ady do that themselves.</span></div></div><div class=3D"gmail_extra"><br><d= +iv class=3D"gmail_quote">2016-08-09 0:41 GMT+03:00 James MacWhyte <span dir= +=3D"ltr"><<a href=3D"mailto:macwhyte@gmail.com" target=3D"_blank">macwhy= +te@gmail.com</a>></span>:<br><blockquote class=3D"gmail_quote" style=3D"= +margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"lt= +r">Wouldn't you lose the ability to assume transactions in the blockcha= +in are verified as valid, since miners can't see the details of what is= + being spent and how? I feel like this ability is bitcoin's greatest as= +set, and by removing it you're creating an altcoin different enough to = +not be connected to/supported by the main bitcoin project.</p> +<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Mon, Aug 8, 2016, 09:13 = +Tony Churyumoff via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.lin= +uxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundation.= +org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg= +in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"= +>Hi=C2=A0Henning,<div><br></div><div>1. The fees are paid by the enclosing = +BTC transaction.</div><div>2. The hash is encoded into an OP_RETURN.</div><= +/div><div dir=3D"ltr"><div><br></div><div>> Regarding the blinding facto= +r, I think you could just use HMAC.<br></div></div><div dir=3D"ltr"><div>Ho= +w exactly?</div></div><div dir=3D"ltr"><div><br></div><div>Tony</div></div>= +<div dir=3D"ltr"><div><br><div class=3D"gmail_extra"><br><div class=3D"gmai= +l_quote">2016-08-08 18:47 GMT+03:00 Henning Kopp <span dir=3D"ltr"><<a h= +ref=3D"mailto:henning.kopp@uni-ulm.de" target=3D"_blank">henning.kopp@uni-u= +lm.de</a>></span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:= +0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">= +Hi Tony,<br> +<br> +I see some issues in your protocol.<br> +<br> +1. How are mining fees handled?<br> +<br> +2. Assume Alice sends Bob some Coins together with their history and<br> +Bob checks that the history is correct. How does the hash of the txout<br> +find its way into the blockchain?<br> +<br> +Regarding the blinding factor, I think you could just use HMAC.<br> +<br> +All the best<br> +Henning<br> +<br> +<br> +On Mon, Aug 08, 2016 at 06:30:21PM +0300, Tony Churyumoff via bitcoin-dev w= +rote:<br> +> This is a proposal about hiding the entire content of bitcoin<br> +> transactions.=C2=A0 It goes farther than CoinJoin and ring signatures,= + which<br> +> only obfuscate the transaction graph, and Confidential Transactions, w= +hich<br> +> only hide the amounts.<br> +><br> +> The central idea of the proposed design is to hide the entire inputs a= +nd<br> +> outputs, and publish only the hash of inputs and outputs in the<br> +> blockchain.=C2=A0 The hash can be published as OP_RETURN.=C2=A0 The pl= +aintext of<br> +> inputs and outputs is sent directly to the payee via a private message= +, and<br> +> never goes into the blockchain.=C2=A0 The payee then calculates the ha= +sh and<br> +> looks it up in the blockchain to verify that the hash was indeed publi= +shed<br> +> by the payer.<br> +><br> +> Since the plaintext of the transaction is not published to the public<= +br> +> blockchain, all validation work has to be done only by the user who<br= +> +> receives the payment.<br> +><br> +> To protect against double-spends, the payer also has to publish anothe= +r<br> +> hash, which is the hash of the output being spent.=C2=A0 We=E2=80=99ll= + call this hash *spend<br> +> proof*.=C2=A0 Since the spend proof depends solely on the output being= + spent,<br> +> any attempt to spend the same output again will produce exactly the sa= +me<br> +> spend proof, and the payee will be able to see that, and will reject t= +he<br> +> payment.=C2=A0 If there are several outputs consumed by the same trans= +action,<br> +> the payer has to publish several spend proofs.<br> +><br> +> To prove that the outputs being spent are valid, the payer also has to= + send<br> +> the plaintexts of the earlier transaction(s) that produced them, then = +the<br> +> plaintexts of even earlier transactions that produced the outputs spen= +t in<br> +> those transactions, and so on, up until the issue (similar to coinbase= +)<br> +> transactions that created the initial private coins.=C2=A0 Each new ow= +ner of the<br> +> coin will have to store its entire history, and when he spends the coi= +n, he<br> +> forwards the entire history to the next owner and extends it with his = +own<br> +> transaction.<br> +><br> +> If we apply the existing bitcoin design that allows multiple inputs an= +d<br> +> multiple outputs per transaction, the history of ownership transfers w= +ould<br> +> grow exponentially.=C2=A0 Indeed, if we take any regular bitcoin outpu= +t and try<br> +> to track its history back to coinbase, our history will branch every t= +ime<br> +> we see a transaction that has more than one input (which is not uncomm= +on).<br> +> After such a transaction (remember, we are traveling back in time), we= +=E2=80=99ll<br> +> have to track two or more histories, for each respective input.=C2=A0 = +Those<br> +> histories will branch again, and the total number of history entries g= +rows<br> +> exponentially.=C2=A0 For example, if every transaction had exactly two= + inputs,<br> +> the size of history would grow as 2^N where N is the number of steps b= +ack<br> +> in history.<br> +><br> +> To avoid such rapid growth of ownership history (which is not only<br> +> inconvenient to move, but also exposes too much private information ab= +out<br> +> previous owners of all the contributing coins), we will require each<b= +r> +> private transaction to have exactly one input (i.e. to consume exactly= + one<br> +> previous output).=C2=A0 This means that when we track a coin=E2=80=99s= + history back in<br> +> time, it will no longer branch.=C2=A0 It will grow linearly with the n= +umber of<br> +> transfers of ownership.=C2=A0 If a user wants to combine several input= +s, he will<br> +> have to send them as separate private transactions (technically, sever= +al<br> +> OP_RETURNs, which can be included in a single regular bitcoin transact= +ion).<br> +><br> +> Thus, we are now forbidding any coin merges but still allowing coin<br= +> +> splits.=C2=A0 To avoid ultimate splitting into the dust, we will also = +require<br> +> that all private coins be issued in one of a small number of<br> +> denominations.=C2=A0 Only integer number of =E2=80=9Cbanknotes=E2=80= +=9D can be transferred, the<br> +> input and output amounts must therefore be divisible by the denominati= +on.<br> +> For example, an input of amount 700, denomination 100, can be split in= +to<br> +> outputs 400 and 300, but not into 450 and 250.=C2=A0 To send a payment= +, the<br> +> payer has to pick the unspent outputs of the highest denomination firs= +t,<br> +> then the second highest, and so on, like we already do when we pay in = +cash.<br> +><br> +> With fixed denominations and one input per transaction, coin histories= +<br> +> still grow, but only linearly, which should not be a concern in regard= + to<br> +> scalability given that all relevant computing resources still grow<br> +> exponentially.=C2=A0 The histories need to be stored only by the curre= +nt owner<br> +> of the coin, not every bitcoin node.=C2=A0 This is a fairer allocation= + of<br> +> costs.=C2=A0 Regarding privacy, coin histories do expose private trans= +actions<br> +> (or rather parts thereof, since a typical payment will likely consist = +of<br> +> several transactions due to one-input-per-transaction rule) of past co= +in<br> +> owners to the future ones, and that exposure grows linearly with time,= + but<br> +> it is still much much better than having every transaction immediately= + on<br> +> the public blockchain.=C2=A0 Also, the value of this information for p= +otential<br> +> adversaries arguably decreases with time.<br> +><br> +> There is one technical nuance that I omitted above to avoid distractio= +n.<br> +>=C2=A0 Unlike regular bitcoin transactions, every output in a private p= +ayment<br> +> must also include a blinding factor, which is just a random string.=C2= +=A0 When<br> +> the output is spent, the corresponding spend proof will therefore depe= +nd on<br> +> this blinding factor (remember that spend proof is just a hash of the<= +br> +> output).=C2=A0 Without a blinding factor, it would be feasible to pre-= +image the<br> +> spend proof and reveal the output being spent as the search space of a= +ll<br> +> possible outputs is rather small.<br> +><br> +> To issue the new private coin, one can burn regular BTC by sending it = +to<br> +> one of several unspendable bitcoin addresses, one address per denomina= +tion.<br> +>=C2=A0 Burning BTC would entitle one to an equal amount of the new priv= +ate coin,<br> +> let=E2=80=99s call it *black bitcoin*, or *BBC*.<br> +><br> +> Then BBC would be transferred from user to user by:<br> +> 1. creating a private transaction, which consists of one input and sev= +eral<br> +> outputs;<br> +> 2. storing the hash of the transaction and the spend proof of the cons= +umed<br> +> output into the blockchain in an OP_RETURN (the sender pays the<br> +> corresponding fees in regular BTC)<br> +> 3. sending the transaction, together with the history leading to its i= +nput,<br> +> directly to the payee over a private communication channel.=C2=A0 The = +first<br> +> entry of the history must be a bitcoin transaction that burned BTC to = +issue<br> +> an equal amount of BCC.<br> +><br> +> To verify the payment, the payee:<br> +> 1. makes sure that the amount of the input matches the sum of outputs,= + and<br> +> all are divisible by the denomination<br> +> 2. calculates the hash of the private transaction<br> +> 3. looks up an OP_RETURN that includes this hash and is signed by the<= +br> +> payee.=C2=A0 If there is more than one, the one that comes in the earl= +ier block<br> +> prevails.<br> +> 4. calculates the spend proof and makes sure that it is included in th= +e<br> +> same OP_RETURN<br> +> 5. makes sure the same spend proof is not included anywhere in the sam= +e or<br> +> earlier blocks (that is, the coin was not spent before).=C2=A0 Only tr= +ansactions<br> +> by the same author are searched.<br> +> 6. repeats the same steps for every entry in the history, except the f= +irst<br> +> entry, which should be a valid burning transaction.<br> +><br> +> To facilitate exchange of private transaction data, the bitcoin networ= +k<br> +> protocol can be extended with a new message type.=C2=A0 Unfortunately,= + it lacks<br> +> encryption, hence private payments are really private only when bitcoi= +n is<br> +> used over tor.<br> +><br> +> There are a few limitations that ought to be mentioned:<br> +> 1. After user A sends a private payment to user B, user A will know wh= +at<br> +> the spend proof is going to be when B decides to spend the coin.<br> +>=C2=A0 Therefore, A will know when the coin was spent by B, but nothing= + more.<br> +>=C2=A0 Neither the new owner of the coin, nor its future movements will= + be known<br> +> to A.<br> +> 2. Over time, larger outputs will likely be split into many smaller<br= +> +> outputs, whose amounts are not much greater than their denominations.<= +br> +> You=E2=80=99ll have to combine more inputs to send the same amount.=C2= +=A0 When you want<br> +> to send a very large amount that is much greater than the highest avai= +lable<br> +> denomination, you=E2=80=99ll have to send a lot of private transaction= +s, your<br> +> bitcoin transaction with so many OP_RETURNs will stand out, and their<= +br> +> number will roughly indicate the total amount.=C2=A0 This kind of priv= +acy<br> +> leakage, however it applies to a small number of users, is easy to avo= +id by<br> +> using multiple addresses and storing a relatively small amount on each= +<br> +> address.<br> +> 3. Exchanges and large merchants will likely accumulate large coin<br> +> histories.=C2=A0 Although fragmented, far from complete, and likely ou= +tdated, it<br> +> is still something to bear in mind.<br> +><br> +> No hard or soft fork is required, BBC is just a separate privacy prese= +rving<br> +> currency on top of bitcoin blockchain, and the same private keys and<b= +r> +> addresses are used for both BBC and the base currency BTC.=C2=A0 Every= + BCC<br> +> transaction must be enclosed into by a small BTC transaction that stor= +es<br> +> the OP_RETURNs and pays for the fees.<br> +><br> +> Are there any flaws in this design?<br> +><br> +> Originally posted to BCT <a href=3D"https://bitcointalk.org/index.php?= +topic=3D1574508.0" rel=3D"noreferrer" target=3D"_blank">https://bitcointalk= +.org/index.<wbr>php?topic=3D1574508.0</a>,<br> +> but got no feedback so far, apparently everybody was consumed with bit= +finex<br> +> drama and now mimblewimble.<br> +><br> +> Tony<br> +<br> +> ______________________________<wbr>_________________<br> +> bitcoin-dev mailing list<br> +> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= +ank">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br> +> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-= +dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb= +r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br> +<span><font color=3D"#888888"><br> +<br> +--<br> +Henning Kopp<br> +Institute of Distributed Systems<br> +Ulm University, Germany<br> +<br> +Office: O27 - 3402<br> +Phone: +49 731 50-24138<br> +Web: <a href=3D"http://www.uni-ulm.de/in/vs/~kopp" rel=3D"noreferrer" targe= +t=3D"_blank">http://www.uni-ulm.de/in/vs/~<wbr>kopp</a><br> +</font></span></blockquote></div><br></div></div></div> +______________________________<wbr>_________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org= +/mailman/listinfo/bitcoin-<wbr>dev</a><br> +</blockquote></div> +</blockquote></div><br></div> + +--089e01177b199ceb70053997f699-- + |