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 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’ll 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 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, 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. > > > > 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. > > > > 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). > > > > 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. > > > > 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. > > > > 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. > > > > 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 *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 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’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. > > 3. Exchanges and large merchants will likely accumulate large coin > > histories. Although fragmented, far from complete, and likely outdated, > it > > is still something to bear in mind. > > > > No hard or soft fork is required, BBC is just a separate privacy > preserving > > currency on top of bitcoin blockchain, and the same private keys and > > addresses are used for both BBC and the base currency BTC. Every BCC > > transaction must be enclosed into by a small BTC transaction that stores > > the OP_RETURNs and pays for the fees. > > > > Are there any flaws in this design? > > > > Originally posted to BCT https://bitcointalk.org/index. > php?topic=1574508.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 >