<div dir="ltr">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.<div><br></div><div>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.<br><br>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.<br><br>To protect 
against double-spends, the payer also has to publish another hash, which
 is the hash of the output being spent.  We’ll call this hash <b>spend proof</b>.
  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.<br><br>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 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 own transaction.<br><br>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’ll 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 inputs, the size of history would grow as 2^N where N is the number of steps back in history.<br><br>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’s 
history 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).<br><br>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 “banknotes” can 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, 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.<br><br>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 
owner of the coin, not every bitcoin node.  This is a fairer allocation 
of costs.  Regarding privacy, coin histories do expose private 
transactions (or rather parts thereof, since a typical payment will 
likely consist of several transactions due to one-input-per-transaction 
rule) of past coin owners to the future ones, and that exposure grows 
linearly with time, but it is still much much better than having every 
transaction immediately on the public blockchain.  Also, the value of 
this information for potential adversaries arguably decreases with time.<br><br>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 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 all possible outputs is rather small.<br><br>To issue 
the new private coin, one can burn regular BTC by sending it to one of 
several unspendable bitcoin addresses, one address per denomination. 
 Burning BTC would entitle one to an equal amount of the new private 
coin, let’s call it <b>black bitcoin</b>, or <b>BBC</b>.  <br><br>Then BBC would be transferred from user to user by:<br>1. creating a private transaction, which consists of one input and several outputs;<br>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)<br>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.<br><br>To verify the payment, the payee:<br>1. makes sure that the amount of the input matches the sum of outputs, and 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 
payee.  If there is more than one, the one that comes in the earlier 
block prevails.<br>4. calculates the spend proof and makes sure that it is included in the same OP_RETURN<br>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.<br>6. repeats the same steps for every entry in the history, except the first entry, which should be a valid burning transaction.<br><br>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.<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 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.<br>2. Over time, larger outputs will likely be split into 
many smaller outputs, whose amounts are not much greater than their 
denominations.  You’ll 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’ll 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 avoid by using multiple addresses and storing a 
relatively small amount on each address.<br>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.<br></div><div><br></div><div>No hard or soft fork is required, BBC is just a separate privacy preserving currency on top of bitcoin blockchain, and the same private keys and addresses are used for both BBC and the base currency BTC.  Every BCC transaction must be enclosed into by a small BTC transaction that stores the OP_RETURNs and pays for the fees.</div><div><br></div><div>Are there any flaws in this design?</div><div><br></div><div>Originally posted to BCT <a href="https://bitcointalk.org/index.php?topic=1574508.0">https://bitcointalk.org/index.php?topic=1574508.0</a>, but got no feedback so far, apparently everybody was consumed with bitfinex drama and now mimblewimble.</div><div><br></div><div>Tony</div><div><br></div></div>