diff options
| author | Tony Churyumoff <tony991@gmail.com> | 2016-08-08 19:03:28 +0300 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-08-08 16:03:32 +0000 |
| commit | ba5a0ad7f58d1a65794f1ed696d27ebc83fe121d (patch) | |
| tree | d3f6caf6e9e16e6a19b27c88630866ce3be0d4d8 | |
| parent | 863c4be0d79daea1de4e16b5f1bbc47b2fe3bc5d (diff) | |
| download | pi-bitcoindev-ba5a0ad7f58d1a65794f1ed696d27ebc83fe121d.tar.gz pi-bitcoindev-ba5a0ad7f58d1a65794f1ed696d27ebc83fe121d.zip | |
Re: [bitcoin-dev] Hiding entire content of on-chain transactions
| -rw-r--r-- | 45/7af3d16268f961316c058de7f03654223865bf | 675 |
1 files changed, 675 insertions, 0 deletions
diff --git a/45/7af3d16268f961316c058de7f03654223865bf b/45/7af3d16268f961316c058de7f03654223865bf new file mode 100644 index 000000000..75c530b71 --- /dev/null +++ b/45/7af3d16268f961316c058de7f03654223865bf @@ -0,0 +1,675 @@ +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 A63A582B + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 8 Aug 2016 16:03:32 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2A93D212 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 8 Aug 2016 16:03:30 +0000 (UTC) +Received: by mail-wm0-f54.google.com with SMTP id o80so148877518wme.1 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 08 Aug 2016 09:03:30 -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=GnGTvLUJAL/yMbPRa12qGPZ8fsGY8rTU/2GeOa+Uqug=; + b=n7u1ldGNEnHqdu2T57OwKsVaMIN0oTg6E6ICnhyXIl7LZ/iu9DHkAKNDDe2jRZkRp/ + cW+vBRKpHIaQyUsaxCIIf8BgvkmJQZTYocMtd30V5T1LQgvmUn3GOIaqxvRCyud5dKhs + Nk0VpJz0Gf/x5qPfM/mCoIrTAoHEq2JUKH0WncaKbFqpWvZFegg2n3xRgpRrOfX7U+7X + rN342RtzLtGxaCYJ59dTvweV5g9VFdlTRA5Y2thy5U4Bo6j8ambJDMAs1IbhalorKYjH + djekVs9bdOhMLapsV43L9/JZoRG9gpbjy6GL4mjxqsfMIZ3i17WXsEvNj9ugGSISNQvY + sSMA== +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=GnGTvLUJAL/yMbPRa12qGPZ8fsGY8rTU/2GeOa+Uqug=; + b=kfTcZtwWaEzINqwqumttpk4+JpZCrW1V5Igl6igwsAHll2/UGBcnaGJZ/iQXfJnw0Q + Bx+ZIG+fIG68cS7otZl7B89VoHRkRPENunJxDhRuMqHq3cFJgdjCnTcjRt5zAelh6c8O + XfeG28VVMBeUZZSej12PfDFjWqPtWCKHnodYvkyAMGc8HW3xrNdGNJ1y2ma1oy1XE8y8 + RVxxV1Jco3174yigpoS7qNGtadhFDggXvKXChUrFF0xUmtsHGZJ2IyqBZg0xdsFZZjus + qlGguK9KGpLqFx3W8JuDXmR3Hq8p3wX2ZdT+hhrGEfsX8xtM8xch6gLHDH0/MOk642JJ + eJSA== +X-Gm-Message-State: AEkooutR5h/aX+PPmlh1oueTK7u3KZ9Mi2xZRuP+Jx/CRP/6o1RzmZdK+Y8O3IQINy0R4UdgvKHUZU4ObUakIg== +X-Received: by 10.194.148.19 with SMTP id to19mr94306285wjb.81.1470672208701; + Mon, 08 Aug 2016 09:03:28 -0700 (PDT) +MIME-Version: 1.0 +Received: by 10.194.100.161 with HTTP; Mon, 8 Aug 2016 09:03:28 -0700 (PDT) +Reply-To: tony.991@gmail.com +In-Reply-To: <20160808154707.GB2196@banane.informatik.uni-ulm.de> +References: <CAL3p6zpADtYFQnQUr3Efk6V59+K+bB3tPQQMGT9weiafU=43zA@mail.gmail.com> + <20160808154707.GB2196@banane.informatik.uni-ulm.de> +From: Tony Churyumoff <tony991@gmail.com> +Date: Mon, 8 Aug 2016 19:03:28 +0300 +Message-ID: <CAL3p6zo1xBEu90MDHSK4TNX0DL2QXxq5vC48a2cFnX0JCD=RvQ@mail.gmail.com> +To: Henning Kopp <henning.kopp@uni-ulm.de> +Content-Type: multipart/alternative; boundary=089e01177b1994c3770539918eab +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: Mon, 08 Aug 2016 16:12:40 +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 16:03:32 -0000 + +--089e01177b1994c3770539918eab +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +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, which +> > 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 an= +d +> > outputs, and publish only the hash of inputs and outputs in the +> > blockchain. The hash can be published as OP_RETURN. The plaintext of +> > 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 and +> > 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 another +> > hash, which is the hash of the output being spent. We=E2=80=99ll call = +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 sam= +e +> > spend proof, and the payee will be able to see that, and will reject th= +e +> > 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 to +> send +> > the plaintexts of the earlier transaction(s) that produced them, then t= +he +> > plaintexts of even earlier transactions that produced the outputs spent +> in +> > those transactions, and so on, up until the issue (similar to coinbase) +> > 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 o= +wn +> > transaction. +> > +> > If we apply the existing bitcoin design that allows multiple inputs and +> > multiple outputs per transaction, the history of ownership transfers +> would +> > grow exponentially. Indeed, if we take any regular bitcoin output and +> try +> > to track its history back to coinbase, our history will branch every ti= +me +> > 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. Those +> > histories will branch again, and the total number of history entries +> grows +> > exponentially. For example, if every transaction had exactly two input= +s, +> > the size of history would grow as 2^N where N is the number of steps ba= +ck +> > in history. +> > +> > To avoid such rapid growth of ownership history (which is not only +> > inconvenient to move, but also exposes too much private information abo= +ut +> > previous owners of all the contributing coins), we will require each +> > private transaction to have exactly one input (i.e. to consume exactly +> one +> > previous output). This means that when we track a coin=E2=80=99s histo= +ry back in +> > time, it will no longer branch. It will grow linearly with the number = +of +> > transfers of ownership. If a user wants to combine several inputs, he +> will +> > have to send them as separate private transactions (technically, severa= +l +> > 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 requir= +e +> > that all private coins be issued in one of a small number of +> > denominations. Only integer number of =E2=80=9Cbanknotes=E2=80=9D can = +be transferred, +> the +> > input and output amounts must therefore be divisible by the denominatio= +n. +> > For example, an input of amount 700, denomination 100, can be split int= +o +> > outputs 400 and 300, but not into 450 and 250. To send a payment, the +> > 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 histories +> > still grow, but only linearly, which should not be a concern in regard = +to +> > scalability given that all relevant computing resources still grow +> > exponentially. The histories need to be stored only by the current own= +er +> > of the coin, not every bitcoin node. This is a fairer allocation of +> > costs. Regarding privacy, coin histories do expose private transaction= +s +> > (or rather parts thereof, since a typical payment will likely consist o= +f +> > several transactions due to one-input-per-transaction rule) of past coi= +n +> > owners to the future ones, and that exposure grows linearly with time, +> but +> > it is still much much better than having every transaction immediately = +on +> > the public blockchain. Also, the value of this information for potenti= +al +> > 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 payment +> > must also include a blinding factor, which is just a random string. Wh= +en +> > the output is spent, the corresponding spend proof will therefore depen= +d +> 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-image +> the +> > spend proof and reveal the output being spent as the search space of al= +l +> > possible outputs is rather small. +> > +> > To issue the new private coin, one can burn regular BTC by sending it t= +o +> > 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 first +> > 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 the +> > 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 network +> > 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 wha= +t +> > 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 more. +> > 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. Wh= +en 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 transactions= +, 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 avoi= +d +> by +> > using multiple addresses and storing a relatively small amount on each +> > 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 store= +s +> > 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 +> + +--089e01177b1994c3770539918eab +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">Hi=C2=A0Henning,<div><br></div><div>1. The fees are paid b= +y the enclosing BTC transaction.</div><div>2. The hash is encoded into an O= +P_RETURN.</div><div><br></div><div>> Regarding the blinding factor, I th= +ink you could just use HMAC.<br></div><div>How exactly?</div><div><br></div= +><div>Tony</div><div><br><div class=3D"gmail_extra"><br><div class=3D"gmail= +_quote">2016-08-08 18:47 GMT+03:00 Henning Kopp <span dir=3D"ltr"><<a hr= +ef=3D"mailto:henning.kopp@uni-ulm.de" target=3D"_blank">henning.kopp@uni-ul= +m.de</a>></span>:<br><blockquote class=3D"gmail_quote" style=3D"margin:0= +px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">H= +i 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">bitcoin-dev@l= +ists.<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 class=3D""><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> + +--089e01177b1994c3770539918eab-- + |