diff options
| author | James MacWhyte <macwhyte@gmail.com> | 2016-08-09 00:03:17 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2016-08-09 00:03:31 +0000 |
| commit | 8780d4cc5a2e8aeaf09fad4927c36b4e4dec300a (patch) | |
| tree | b101482ef824fa8ab52ab30eebe3c0af90861b15 /05 | |
| parent | 60340a85242108ae11c003b752d2039200313f27 (diff) | |
| download | pi-bitcoindev-8780d4cc5a2e8aeaf09fad4927c36b4e4dec300a.tar.gz pi-bitcoindev-8780d4cc5a2e8aeaf09fad4927c36b4e4dec300a.zip | |
Re: [bitcoin-dev] Hiding entire content of on-chain transactions
Diffstat (limited to '05')
| -rw-r--r-- | 05/301fa24e437a63a09c4681a2c18c042faa9178 | 804 |
1 files changed, 804 insertions, 0 deletions
diff --git a/05/301fa24e437a63a09c4681a2c18c042faa9178 b/05/301fa24e437a63a09c4681a2c18c042faa9178 new file mode 100644 index 000000000..f462ce641 --- /dev/null +++ b/05/301fa24e437a63a09c4681a2c18c042faa9178 @@ -0,0 +1,804 @@ +Return-Path: <keatonatron@gmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 1544A71 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 9 Aug 2016 00:03:31 +0000 (UTC) +X-Greylist: whitelisted by SQLgrey-1.7.6 +Received: from mail-qk0-f171.google.com (mail-qk0-f171.google.com + [209.85.220.171]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E002A22A + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 9 Aug 2016 00:03:28 +0000 (UTC) +Received: by mail-qk0-f171.google.com with SMTP id t7so62092876qkh.0 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 08 Aug 2016 17:03:28 -0700 (PDT) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; + h=mime-version:references:in-reply-to:from:date:message-id:subject:to + :cc; bh=HkiHO/09ejPx7RmeOeTSfyXr1n5EWBBGmQwP+qihVA4=; + b=AMniLRElJ44uMT7JCJT3Ga/UqrIFwBEPW66hbw74FXC4ewvlrFOsTbdy2QzAVQgNUA + 3RwbYJDlAwT+od/iCuINC8GUTK8oXRY2gG0U3jsMGy/Jp+vKd1hAYXy7yS93KHQ3xnaI + SEunHKW3jVWEnrv4bjmO9ijZt4kcWB8/1uGvRy6vcs5/WvCPawIHGKdgRMXqJAaBbDUH + h6G53O8ZCRMnlXhmGUXtM9NVow2K3mnqzowbApngMM55Bn7bkLMKM7j4tb9u6m3EqLd3 + QGVeFk5tgMsmJK/hKNWZ32my/SdRhVrbAbMIiJG45p/NRCwya7fhqX8viV5FoZRIYRMe + QMDQ== +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:mime-version:references:in-reply-to:from:date + :message-id:subject:to:cc; + bh=HkiHO/09ejPx7RmeOeTSfyXr1n5EWBBGmQwP+qihVA4=; + b=M8xjWY1jvhEP5MX+qB+Q9FCXAHHeckFgD6mpw7Pg+qPvwsa3P3z8vK9YAbCg5gPAJP + kBxJw1F6cStV7o9s8JSZMeJTucXILORvp/BviAwP9IWiBdJVFFU7n6luXbaMku7Ot+O0 + SWFry8OawsJ0JjmCV9XfJQvECPCkjigoMNCVASISS5V7RvFz7s4AKHn+B0GX1g1+uVGa + KPiY2qZuO9feS85AisAO3U9CEer+FrCLCtBg+StfFqUCpbxO7Sg7S6klH5cLfnnDvfrA + 6TJvcj2q47kpL3jkgcgBjKtt5cyexjzGQs8MiyOULxmgvRWvRZ86d9Vm8KLY/6TIRYyE + Wcpg== +X-Gm-Message-State: AEkoouuEuYZL1JClkhPk+YZf07Rhpjnxni86EwIWDuKqlYZPD87T4N26TTtcr3cwA0ueARbXGxrkht/6Vy5f9Q== +X-Received: by 10.55.78.19 with SMTP id c19mr30146926qkb.193.1470701007949; + Mon, 08 Aug 2016 17:03:27 -0700 (PDT) +MIME-Version: 1.0 +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> + <CAL3p6zp5wcr4bK13n1F51XeKPahjUTNUziZq2MN7PRDA_BzGBg@mail.gmail.com> +In-Reply-To: <CAL3p6zp5wcr4bK13n1F51XeKPahjUTNUziZq2MN7PRDA_BzGBg@mail.gmail.com> +From: James MacWhyte <macwhyte@gmail.com> +Date: Tue, 09 Aug 2016 00:03:17 +0000 +Message-ID: <CAH+Axy6JiK-giXRTxENRCZbX7g0NuU=hq02O3j2Ac8HZ0ZhfFg@mail.gmail.com> +To: tony.991@gmail.com +Content-Type: multipart/alternative; boundary=001a114a838826550e0539984320 +X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW + autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +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: Tue, 09 Aug 2016 00:03:31 -0000 + +--001a114a838826550e0539984320 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +That is a good point. As you said, it puts a lot more burden on the coin +holders. One big downside would be data management. Instead of simply +backing up a single HD private key, the user would have to back up entire +histories of every output that has been sent to them if they want to secure +their funds. + +It also requires them to be online to receive payments, and I think finding +a method of sending the private message containing the coin's history is +going to be a bit of a challenge. If you connect directly to the recipient +to convey the information through traditional channels, anonymity is lost. +Sending messages through the bitcoin network is one option to protect +anonymity, but without active pathfinding there's no guarantee the payee +will even get the message. I'm assuming you'd have to essentially replace +tx messages with encrypted BBC histories, and mempools are quite full as it +is. + +Tony, do you have any more thoughts on exactly how users would convey the +private messages to payees? + +On Mon, Aug 8, 2016 at 4:42 PM Tony Churyumoff <tony991@gmail.com> wrote: + +> The whole point is in preventing every third party, including miners, fro= +m +> 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 owner= +s +> 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 +>> are verified as valid, since miners can't see the details of what is bei= +ng +>> 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 connec= +ted +>> 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, +>>>> 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 +>>>> and +>>>> > 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 publi= +c +>>>> > 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 ca= +ll 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 +>>>> to send +>>>> > the plaintexts of the earlier transaction(s) that produced them, the= +n +>>>> the +>>>> > 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 hi= +s +>>>> own +>>>> > 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 +>>>> 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. Tho= +se +>>>> > 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 +>>>> exactly one +>>>> > previous output). This means that when we track a coin=E2=80=99s hi= +story +>>>> 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, +>>>> 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 c= +an 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, t= +he +>>>> > 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 i= +n +>>>> cash. +>>>> > +>>>> > With fixed denominations and one input per transaction, coin histori= +es +>>>> > 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 +>>>> 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 consis= +t +>>>> 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 +>>>> immediately 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 +>>>> payment +>>>> > 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 th= +e +>>>> > 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 +>>>> all +>>>> > possible outputs is rather small. +>>>> > +>>>> > To issue the new private coin, one can burn regular BTC by sending i= +t +>>>> 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 fir= +st +>>>> > entry of the history must be a bitcoin transaction that burned BTC t= +o +>>>> 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 th= +e +>>>> > 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 +>>>> 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 +>>>> 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. = + 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 transacti= +ons, your +>>>> > bitcoin transaction with so many OP_RETURNs will stand out, and thei= +r +>>>> > 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 ea= +ch +>>>> > 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 BC= +C +>>>> > 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 +>>> +>> +> + +--001a114a838826550e0539984320 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr">That is a good point. As you said, it puts a lot more burd= +en on the coin holders. One big downside would be data management. Instead = +of simply backing up a single HD private key, the user would have to back u= +p entire histories of every output that has been sent to them if they want = +to secure their funds.<div><br></div><div>It also requires them to be onlin= +e to receive payments, and I think finding a method of sending the private = +message containing the coin's history is going to be a bit of a challen= +ge. If you connect directly to the recipient to convey the information thro= +ugh traditional channels, anonymity is lost. Sending messages through the b= +itcoin network is one option to protect anonymity, but without active pathf= +inding there's no guarantee the payee will even get the message. I'= +m assuming you'd have to essentially replace tx messages with encrypted= + BBC histories, and mempools are quite full as it is.<br><br>Tony, do you h= +ave any more thoughts on exactly how users would convey the private message= +s to payees?</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On = +Mon, Aug 8, 2016 at 4:42 PM Tony Churyumoff <<a href=3D"mailto:tony991@g= +mail.com">tony991@gmail.com</a>> wrote:<br></div><blockquote class=3D"gm= +ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le= +ft:1ex"><div dir=3D"ltr">The whole point is in preventing every third party= +, including miners, from seeing=C2=A0<span style=3D"font-size:12.8px">the d= +etails of 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-size: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 sa= +me spend proof is not entered into the blockchain more than once (which wou= +ld be a sign of double spend), but it is not required.=C2=A0 The coin owner= +s can already do that themselves.</span></div></div><div class=3D"gmail_ext= +ra"><br><div 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"_bla= +nk">macwhyte@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"ltr">Wouldn't you lose the ability to assume transactions in th= +e blockchain 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 g= +reatest asset, 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.linuxfoundation.org</= +a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin: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></di= +v><div dir=3D"ltr"><div><br></div><div>> Regarding the blinding factor, = +I think you could just use HMAC.<br></div></div><div dir=3D"ltr"><div>How e= +xactly?</div></div><div dir=3D"ltr"><div><br></div><div>Tony</div></div><di= +v dir=3D"ltr"><div><br><div class=3D"gmail_extra"><br><div class=3D"gmail_q= +uote">2016-08-08 18:47 GMT+03:00 Henning Kopp <span dir=3D"ltr"><<a href= +=3D"mailto:henning.kopp@uni-ulm.de" target=3D"_blank">henning.kopp@uni-ulm.= +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.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> +> _______________________________________________<br> +> bitcoin-dev mailing list<br> +> <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl= +ank">bitcoin-dev@lists.linuxfoundation.org</a><br> +> <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-= +dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org= +/mailman/listinfo/bitcoin-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/~kopp</a><br> +</font></span></blockquote></div><br></div></div></div> +_______________________________________________<br> +bitcoin-dev mailing list<br> +<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">= +bitcoin-dev@lists.linuxfoundation.org</a><br> +<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" = +rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail= +man/listinfo/bitcoin-dev</a><br> +</blockquote></div> +</blockquote></div><br></div> +</blockquote></div> + +--001a114a838826550e0539984320-- + |