Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 8099071 for ; Tue, 9 Aug 2016 00:18:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f170.google.com (mail-qk0-f170.google.com [209.85.220.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4984E23E for ; Tue, 9 Aug 2016 00:18:33 +0000 (UTC) Received: by mail-qk0-f170.google.com with SMTP id p186so212666583qkd.1 for ; Mon, 08 Aug 2016 17:18:33 -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=md6FC1cBQ4noIAgHDe6fkTUnPv9BA26TkYpvCpzRat8=; b=kMadk9aF6yGojoeRwjofHeCIvM54WfP7TsyNs7uXZGqBAUNTeZxfsLniXlX4M4WxAd +PjMF/QIRy6uLHu7x8Re7JQkZemptaBvrxiutUO2pHv1cxSnCDfZE4UIVmqFLwwC/yL/ UYvGTVaysTQZCtNbp22CS6rvLtktSmbuTMmgK1cYLhMY6NyOVDab8E39rgFw7WSYSl4I 41fZpsJzCH5ZcdzqnYXN+2ca7Q6eFgDa4t6Ry+c9dSs8cYUP7NS7Eq8Lh+yghd7tfAfW Gks8PyGCzUH+8r3LuWxRAs61/ashUI5QCLrWYmu5zEYEIJ8Yp/Q/sDipF04qf50m4JS8 gmtQ== 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=md6FC1cBQ4noIAgHDe6fkTUnPv9BA26TkYpvCpzRat8=; b=HCjx6ynpjAUl/9FPkhHSkQ6mWQ6BsRo/94zvhJNg9WcaRPbJQHKcQPERHSpJF96rT8 DKiN2YG4dFSnWuiOWEBMOfntSyt5LB8v+QTSMYfOalmWokcGfuKKEg7rrBtyOrmZ4aZ0 mp9CDKHZfY8qtZ3SR6qiCgGrMGvXlK7YzD61B0mpRv/e+7Dr7tiEpdZVsZyd7lM7AiSN 4Zt56o0ld5IgY20ZNK9zJ9gUkxoixOSJqPlFy7J0hbNSRoEuseomhF3AhWT2wEdyZxBi FPBAaMj1SB3L+45+Y6XUBeHsM79Kqlq2cgrMtCjITNgGL0G7e+By+rAf9jXrBD4blqjp gnFw== X-Gm-Message-State: AEkoousPZjKnMqkUkEvN6hTr1ee+bVtIYkkeUm7jG7EhnaGpSAMv7jbYKZy+/z0YVU9goXEZH3NhfLn3SetSfw== X-Received: by 10.55.43.138 with SMTP id r10mr30116820qkr.234.1470701912454; Mon, 08 Aug 2016 17:18:32 -0700 (PDT) MIME-Version: 1.0 References: <20160808154707.GB2196@banane.informatik.uni-ulm.de> In-Reply-To: From: James MacWhyte Date: Tue, 09 Aug 2016 00:18:21 +0000 Message-ID: To: tony.991@gmail.com Content-Type: multipart/alternative; boundary=001a1147afce101ea205399879c7 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2016 00:18:35 -0000 --001a1147afce101ea205399879c7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable One more thought about why verification by miners may be needed. Let's say Alice sends Bob a transaction, generating output C. A troll, named Timothy, broadcasts a transaction with a random hash, referencing C's output as its spend proof. The miners can't tell if it's valid or not, and so they include the transaction in a block. Now Bob's money is useless, because everyone can see the spend proof referenced and thinks it has already been spent, even though the transaction that claims it isn't valid. Did I miss something that protects against this? On Mon, Aug 8, 2016 at 4:42 PM Tony Churyumoff 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 : > >> 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 : >>> >>>> 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 >>> >> > --001a1147afce101ea205399879c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One more thought about why verification by miners may be n= eeded.

Let's say Alice sends Bob a transaction, gene= rating output C.

A troll, named Timothy, broadcast= s a transaction with a random hash, referencing C's output as its spend= proof. The miners can't tell if it's valid or not, and so they inc= lude the transaction in a block. Now Bob's money is useless, because ev= eryone can see the spend proof referenced and thinks it has already been sp= ent, even though the transaction that claims it isn't valid.

Did= I miss something that protects against this?

On Mon, Aug 8, 2016 at 4:42 PM Tony Churyumoff <tony991@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
The whole point is in preven= ting every third party, including miners, from seeing=C2=A0the details of what is being spent and how.=C2=A0 The burd= en of verification is shifted to the owners of the coin (which is fair).

In fact we could have miners recognize spend proofs a= nd 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.= =C2=A0 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 assu= me transactions in the blockchain are verified as valid, since miners can&#= 39;t see the details of what is being spent and how? I feel like this abili= ty is bitcoin's greatest asset, and by removing it you're creating = an altcoin different enough to not be connected to/supported by the main bi= tcoin project.


On Mon, Aug 8, 2016, 09:13 = Tony Churyumoff via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
Hi= =C2=A0Henning,

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 e= xactly?

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 w= rote:
> This is a proposal about hiding the entire content of bitcoin
> transactions.=C2=A0 It goes farther than CoinJoin and ring signatures,= which
> only obfuscate the transaction graph, and Confidential Transactions, w= hich
> only hide the amounts.
>
> The central idea of the proposed design is to hide the entire inputs a= nd
> outputs, and publish only the hash of inputs and outputs in the
> blockchain.=C2=A0 The hash can be published as OP_RETURN.=C2=A0 The pl= aintext of
> inputs and outputs is sent directly to the payee via a private message= , and
> never goes into the blockchain.=C2=A0 The payee then calculates the ha= sh and
> looks it up in the blockchain to verify that the hash was indeed publi= shed
> by the payer.
>
> 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 > receives the payment.
>
> To protect against double-spends, the payer also has to publish anothe= r
> hash, which is the hash of the output being spent.=C2=A0 We=E2=80=99ll= call this hash *spend
> proof*.=C2=A0 Since the spend proof depends solely on the output being= spent,
> any attempt to spend the same output again will produce exactly the sa= me
> spend proof, and the payee will be able to see that, and will reject t= he
> payment.=C2=A0 If there are several outputs consumed by the same trans= action,
> 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 = the
> plaintexts of even earlier transactions that produced the outputs spen= t in
> those transactions, and so on, up until the issue (similar to coinbase= )
> transactions that created the initial private coins.=C2=A0 Each new ow= ner of the
> coin will have to store its entire history, and when he spends the coi= n, 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 an= d
> multiple outputs per transaction, the history of ownership transfers w= ould
> grow exponentially.=C2=A0 Indeed, if we take any regular bitcoin outpu= t and try
> to track its history back to coinbase, our history will branch every t= ime
> we see a transaction that has more than one input (which is not uncomm= on).
> 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.=C2=A0 = Those
> histories will branch again, and the total number of history entries g= rows
> exponentially.=C2=A0 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 b= ack
> in history.
>
> To avoid such rapid growth of ownership history (which is not only
> inconvenient to move, but also exposes too much private information ab= out
> 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).=C2=A0 This means that when we track a coin=E2=80=99s= history back in
> time, it will no longer branch.=C2=A0 It will grow linearly with the n= umber of
> transfers of ownership.=C2=A0 If a user wants to combine several input= s, he will
> have to send them as separate private transactions (technically, sever= al
> OP_RETURNs, which can be included in a single regular bitcoin transact= ion).
>
> Thus, we are now forbidding any coin merges but still allowing coin > splits.=C2=A0 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.=C2=A0 Only integer number of =E2=80=9Cbanknotes=E2=80= =9D can be transferred, the
> input and output amounts must therefore be divisible by the denominati= on.
> For example, an input of amount 700, denomination 100, can be split in= to
> outputs 400 and 300, but not into 450 and 250.=C2=A0 To send a payment= , the
> payer has to pick the unspent outputs of the highest denomination firs= t,
> 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.=C2=A0 The histories need to be stored only by the curre= nt owner
> of the coin, not every bitcoin node.=C2=A0 This is a fairer allocation= of
> costs.=C2=A0 Regarding privacy, coin histories do expose private trans= actions
> (or rather parts thereof, since a typical payment will likely consist = of
> several transactions due to one-input-per-transaction rule) of past co= in
> 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.=C2=A0 Also, the value of this information for p= otential
> adversaries arguably decreases with time.
>
> There is one technical nuance that I omitted above to avoid distractio= n.
>=C2=A0 Unlike regular bitcoin transactions, every output in a private p= ayment
> must also include a blinding factor, which is just a random string.=C2= =A0 When
> the output is spent, the corresponding spend proof will therefore depe= nd on
> 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
> spend proof and reveal the output being spent as the search space of a= ll
> 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 denomina= tion.
>=C2=A0 Burning BTC would entitle one to an equal amount of the new priv= ate 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 sev= eral
> outputs;
> 2. storing the hash of the transaction and the spend proof of the cons= umed
> 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 i= nput,
> directly to the payee over a private communication channel.=C2=A0 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<= br> > payee.=C2=A0 If there is more than one, the one that comes in the earl= ier block
> prevails.
> 4. calculates the spend proof and makes sure that it is included in th= e
> same OP_RETURN
> 5. makes sure the same spend proof is not included anywhere in the sam= e or
> earlier blocks (that is, the coin was not spent before).=C2=A0 Only tr= ansactions
> by the same author are searched.
> 6. repeats the same steps for every entry in the history, except the f= irst
> entry, which should be a valid burning transaction.
>
> To facilitate exchange of private transaction data, the bitcoin networ= k
> protocol can be extended with a new message type.=C2=A0 Unfortunately,= it lacks
> encryption, hence private payments are really private only when bitcoi= n 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 wh= at
> the spend proof is going to be when B decides to spend the coin.
>=C2=A0 Therefore, A will know when the coin was spent by B, but nothing= more.
>=C2=A0 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.<= br> > You=E2=80=99ll have to combine more inputs to send the same amount.=C2= =A0 When you want
> to send a very large amount that is much greater than the highest avai= lable
> denomination, you=E2=80=99ll have to send a lot of private transaction= s, your
> 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
> leakage, however it applies to a small number of users, is easy to avo= id by
> using multiple addresses and storing a relatively small amount on each=
> address.
> 3. Exchanges and large merchants will likely accumulate large coin
> histories.=C2=A0 Although fragmented, far from complete, and likely ou= tdated, it
> is still something to bear in mind.
>
> No hard or soft fork is required, BBC is just a separate privacy prese= rving
> currency on top of bitcoin blockchain, and the same private keys and > addresses are used for both BBC and the base currency BTC.=C2=A0 Every= BCC
> transaction must be enclosed into by a small BTC transaction that stor= es
> 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 bit= finex
> 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/mail= man/listinfo/bitcoin-dev

--001a1147afce101ea205399879c7--