Hiding entire content of on-chain transactions

[tonych]

I want to share one idea about making bitcoin transactions private, i.e. not published to the blockchain.  I use this design in an altcoin I’m currently working on, but it is equally applicable to Bitcoin.

Bitcoin is an unusual currency in that it necessarily makes all transactions public in its blockchain. This, in turn, necessitates unusual usage patterns (such as having to keep multiple addresses, avoid address reuse, and avoid joining outputs from different transactions), which make bitcoin look even more “foreign” to an ordinary user.

There are multiple known ways to improve privacy, to name just a few (the list is far from comprehensive):
- coinjoin https://bitcointalk.org/index.php?topic=279249.0 allows to obfuscate transactions by mixing inputs and outputs of multiple unrelated  transactions.  Someone has to arrange the mixing, and users have to take special steps to actually make use of the service.
- ring signatures https://cryptonote.org/ allow to obfuscate the real signer of a transaction.  The amounts and the receivers of funds are left visible.
- confidential transactions https://people.xiph.org/~greg/confidential_values.txt allow to hide the amounts of inputs and outputs but leaves the “who” and “whom” still visible on the blockchain.  The cost of CTs is a significantly increased size of the transaction that has to be stored on the common blockchain, therefore the cost is beared by everyone.

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.

I’ll be glad to hear any thoughts on this design.

[tonych]

The first coin to implement this idea: https://bitcointalk.org/index.php?topic=1608859.0

[dinofelis]

You are reinventing zerocoin.

[tonych]

You are reinventing zerocoin.

Not at all.  Zerocoin is based on zero knowledge proofs, while Byteball's private payments don't rely on any advanced crypto, just plain old hashes.

[dinofelis]

Ok, I didn't quite get what you are proposing then.

Look at the following attack:

I pay you amount X.  Hence I also can calculate the spend proof YOU would have to provide to show that you spent X to someone else.

I can hence post the hash of spending YOUR output to the block chain, which will make it impossible for YOU to spend the money further.

Why would I do that ?  Because if I'm holding still a large amount of BBC coin, the less of it is in circulation, the scarcer it will be and in principle, the higher its price.  In reality, of course, if it is possible for the previous payer to destroy your ownership at any moment, the value will rather plummet.   There may also be another reason why I destroy the money I give you when it is yours: I may not like that our history is transmitted further.  If I kill your money, you won't be spending it and this history will not be transmitted further in principle.

Is my attack valid ?

[tonych]

Of course, I thought about it
The attack won't work because the spend proof must be sent from the owner's address, not from any address.

[dinofelis]

Of course, I thought about it
The attack won't work because the spend proof must be sent from the owner's address, not from any address.

What is an address ?  e-mail or so ?
How do others checking the block chain know that this private transaction belongs to an address and how do they find out who had send what from which address ?  I think I'm missing something.  If you mean an address on a P2P networks, Kademlia style, then you've undone the anonymity.  Because if the address of the sender is included in the block chain, then, eh, the spending history is just as pseudonymous as bitcoin (your address is associated with all you do).  And it would also mean that your coins are attached to your P2P address private key.

[tonych]

Of course, I thought about it
The attack won't work because the spend proof must be sent from the owner's address, not from any address.

What is an address ?  e-mail or so ?
How do others checking the block chain know that this private transaction belongs to an address and how do they find out who had send what from which address ?  I think I'm missing something.  If you mean an address on a P2P networks, Kademlia style, then you've undone the anonymity.  Because if the address of the sender is included in the block chain, then, eh, the spending history is just as pseudonymous as bitcoin (your address is associated with all you do).  And it would also mean that your coins are attached to your P2P address private key.

In the simplest case, address is a hash of the public key, or something similar.
The validators need to check one simple thing: if there are two transactions that (1) embed the same spend proof and (2) are signed by the same address (roughly equivalent to private key), it is a double-spend.  Everything else is fine.

[iGotSpots]

Just use an exchange if you don't want your transactions on the blockchain. A public ledger is kind of the whole point; anything else enables too much fuckery

[dinofelis]

Of course, I thought about it
The attack won't work because the spend proof must be sent from the owner's address, not from any address.

What is an address ?  e-mail or so ?
How do others checking the block chain know that this private transaction belongs to an address and how do they find out who had send what from which address ?  I think I'm missing something.  If you mean an address on a P2P networks, Kademlia style, then you've undone the anonymity.  Because if the address of the sender is included in the block chain, then, eh, the spending history is just as pseudonymous as bitcoin (your address is associated with all you do).  And it would also mean that your coins are attached to your P2P address private key.

In the simplest case, address is a hash of the public key, or something similar.
The validators need to check one simple thing: if there are two transactions that (1) embed the same spend proof and (2) are signed by the same address (roughly equivalent to private key), it is a double-spend.  Everything else is fine.

Ah, essentially, you mean that the spend proof is in fact nothing else but a "burning transaction".

Ok, it took some time to start understanding it, but I'm starting to see now what you mean (I think).

Correct me if I'm wrong.  The problem that Satoshi faced was to
1) avoid double spending, and for that, it is necessary to have a common, distributed ledger of spending proofs and
2) prove that you have an "original" coin, and not a newly invented one
and the way that Satoshi proposed to solve this was to put *the entire transaction* on the common ledger: you can see when the previous spend happened, and you can trace back each coin to its legit creation.

Indeed is there no way to "transmit a file" where the file is the money, like a bank note, because files can be copied.

What you propose, essentially, is to go back partially to "files are bank notes", and these files are individual transaction histories of the coin.  On the common ledger only needs to be registered the hash of a spending signature.  The "bank note file" itself needs to carry a proof of legit creation (in your proposal, a burning of bitcoin).

That is indeed not a bad idea !   It is of course not very private, in the sense that each individual "bank note" carries with it its entire spending history, but on the other hand, only the people receiving it get that file (and not the entire planet), and because of the linear nature of it, if one uses different signatures for each bank note, there's no "network analysis" that can be performed, so the pseudonymous nature is perfectly anonymous in this case, because no "joins and splits" can happen.

So if I understand correctly, the public block chain is just a "bag of hashes" which cannot be verified or anything by any node or miner.  It is just a block chain of "data".  These data only have meaning for the people receiving "banknote files", which allows them to check the validity of the whole "banknote".  The hashes are in fact nothing else but hashes of "signed transactions", like with bitcoin, except that only the *signature hash* goes on the public block chain, and the actual transaction data remain on the individual banknote file.  Is that the gist ?  In fact, you need, as you say, TWO signatures (or hashes of signatures): one is the transaction signature (including the new beneficiary) and the other is the "spend" signature of simply the previous output.  The first signature (spending signature) makes that you cannot do double spending any more (you have invalidated the file up to the point where you transmit it), and the second signature allows the receiver to have a valid "new address" that he can spend (and only he, because only he has the secret key that goes with it like on bitcoin).

This is indeed a very, very good idea !  Money becomes more "physical" again: it are files !

Now, the question is: how does the mining work ?  Or is this meant as a parasite on top of the bitcoin block chain ?

The thing is, you need to burn a bitcoin to obtain something, irreversibly, that is not a bitcoin at all.  Nobody is going to burn a bitcoin to have a new altcoin.  You would automatically give that altcoin the value of a bitcoin, if you could redeem the whole payment history against a bitcoin again.  But then, what you have constructed, is a *private sidechain* on top of bitcoin.

You "lock up a bitcoin" in the side chain.  The side chain is not public, but is just the private "money file". Any legit owner along the chain can transmit the chain to the next one (as you describe more or less), OR can redeem the bitcoin from the original transaction, and as such, end the side chain.  It is not *entirely* what you propose, but close. 
The redeeming of the bitcoin at the end of the chain is probably somewhat more tricky.

[dinofelis]

Just use an exchange if you don't want your transactions on the blockchain. A public ledger is kind of the whole point; anything else enables too much fuckery

I would agree with you that in a free society, having payments "in the open" is better than allowing for secrecy.  However, we do not live in a free society: there are states everywhere.  States are criminal syndicates that have the monopoly of violence over a territory, and their prime action is to extort people of their production of value, mostly to use that extorted value to buy them more power of violence and extortion.  In most countries, this extortion amounts to grossly half of the value that is created by the people.   You cannot allow to have a new system of payment that is transparent, as this would kill all hopes to hide it from the state syndicate.

[Come-from-Beyond]

I want to share one idea about making bitcoin transactions private, i.e. not published to the blockchain...

In short, you delay the moment when transaction data are published but they are still published, right?

[dinofelis]

In short, you delay the moment when transaction data are published but they are still published, right?

As far as I understood it, no.  The public block chain only contains hashes of transactions that are never made public themselves on the chain, but are simply transmitted as a file from payer to payee as a growing individual private chain.  But if you're not in the list of payer-payee along a coin, you normally never get to see this list.  Only nonsense-like hashes from pieces of this growing chain are publicly published on the common block chain.
These hashes are meaningless, and cannot be verified, by people apart from those having access to the private file that is only transmitted from payer to payee.  Once you've given out the file, as payer, to a payee, you can't understand the future of that file either.

Of course, nothing stops a future payee to publish somewhere, say, on a bulletin board, the whole file he got up to that point, which would render the entire history of that particular coin public and would make the relevant hashes on the block chain verifiable.  But then, as it is a single list, the pseudonymous addresses occurring there - as far as one uses unique addresses - cannot be linked to any identity elsewhere either.  In the case of a linear list, pseudonymity is in fact anonymity.

[tonych]

Ah, essentially, you mean that the spend proof is in fact nothing else but a "burning transaction".

No, spend proof and burning transaction are not the same.  Burning transaction happens only once to convert bitcoins to BBC, while spend proof is sent with every subsequent transfer of the private currency.

Ok, it took some time to start understanding it, but I'm starting to see now what you mean (I think).

Correct me if I'm wrong.  The problem that Satoshi faced was to
1) avoid double spending, and for that, it is necessary to have a common, distributed ledger of spending proofs and
2) prove that you have an "original" coin, and not a newly invented one
and the way that Satoshi proposed to solve this was to put *the entire transaction* on the common ledger: you can see when the previous spend happened, and you can trace back each coin to its legit creation.

Indeed is there no way to "transmit a file" where the file is the money, like a bank note, because files can be copied.

What you propose, essentially, is to go back partially to "files are bank notes", and these files are individual transaction histories of the coin.  On the common ledger only needs to be registered the hash of a spending signature.  The "bank note file" itself needs to carry a proof of legit creation (in your proposal, a burning of bitcoin).

That is indeed not a bad idea !   It is of course not very private, in the sense that each individual "bank note" carries with it its entire spending history, but on the other hand, only the people receiving it get that file (and not the entire planet), and because of the linear nature of it, if one uses different signatures for each bank note, there's no "network analysis" that can be performed, so the pseudonymous nature is perfectly anonymous in this case, because no "joins and splits" can happen.

So if I understand correctly, the public block chain is just a "bag of hashes" which cannot be verified or anything by any node or miner.  It is just a block chain of "data".  These data only have meaning for the people receiving "banknote files", which allows them to check the validity of the whole "banknote".  The hashes are in fact nothing else but hashes of "signed transactions", like with bitcoin, except that only the *signature hash* goes on the public block chain, and the actual transaction data remain on the individual banknote file.  Is that the gist ?  In fact, you need, as you say, TWO signatures (or hashes of signatures): one is the transaction signature (including the new beneficiary) and the other is the "spend" signature of simply the previous output.  The first signature (spending signature) makes that you cannot do double spending any more (you have invalidated the file up to the point where you transmit it), and the second signature allows the receiver to have a valid "new address" that he can spend (and only he, because only he has the secret key that goes with it like on bitcoin).

This is indeed a very, very good idea !  Money becomes more "physical" again: it are files !

Wow, you made a good job of explaining the concept in a clearer way!  Anyone who didn't understand the OP should jump here and read your post.  Except for one correction: in the below paragraph, where you say "signature" you are actually referring to "hash" rather than a cryptographic signature.

So if I understand correctly, the public block chain is just a "bag of hashes" which cannot be verified or anything by any node or miner.  It is just a block chain of "data".  These data only have meaning for the people receiving "banknote files", which allows them to check the validity of the whole "banknote".  The hashes are in fact nothing else but hashes of "signed transactions", like with bitcoin, except that only the *signature hash* goes on the public block chain, and the actual transaction data remain on the individual banknote file.  Is that the gist ?  In fact, you need, as you say, TWO signatures (or hashes of signatures): one is the transaction signature (including the new beneficiary) and the other is the "spend" signature of simply the previous output.  The first signature (spending signature) makes that you cannot do double spending any more (you have invalidated the file up to the point where you transmit it), and the second signature allows the receiver to have a valid "new address" that he can spend (and only he, because only he has the secret key that goes with it like on bitcoin).

Now, the question is: how does the mining work ?  Or is this meant as a parasite on top of the bitcoin block chain ?

We are talking about two similar but distinct designs here:
1) BBC proposed in the OP is a parasite on top of the bitcoin blockchain.  It was never implemented.
2) Blackbytes in Byteball, the coin I launched earlier this week https://bitcointalk.org/index.php?topic=1608859.0, there is no mining at all, the coin is in testnet phase, and you can already play with blackbytes.

The thing is, you need to burn a bitcoin to obtain something, irreversibly, that is not a bitcoin at all.  Nobody is going to burn a bitcoin to have a new altcoin.  You would automatically give that altcoin the value of a bitcoin, if you could redeem the whole payment history against a bitcoin again.  But then, what you have constructed, is a *private sidechain* on top of bitcoin.

You "lock up a bitcoin" in the side chain.  The side chain is not public, but is just the private "money file". Any legit owner along the chain can transmit the chain to the next one (as you describe more or less), OR can redeem the bitcoin from the original transaction, and as such, end the side chain.  It is not *entirely* what you propose, but close. 
The redeeming of the bitcoin at the end of the chain is probably somewhat more tricky.

You can't redeem BBC back to bitcoin.  "Unburning" would mean dumping the entire history of the coin to the public, which is clearly against its purpose.  But you can exchange it.

[dinofelis]

Wow, you made a good job of explaining the concept in a clearer way!  Anyone who didn't understand the OP should jump here and read your post.  Except for one correction: in the below paragraph, where you say "signature" you are actually referring to "hash" rather than a cryptographic signature.

So if I understand correctly, the public block chain is just a "bag of hashes" which cannot be verified or anything by any node or miner.  It is just a block chain of "data".  These data only have meaning for the people receiving "banknote files", which allows them to check the validity of the whole "banknote".  The hashes are in fact nothing else but hashes of "signed transactions", like with bitcoin, except that only the *signature hash* goes on the public block chain, and the actual transaction data remain on the individual banknote file.  Is that the gist ?  In fact, you need, as you say, TWO signatures (or hashes of signatures): one is the transaction signature (including the new beneficiary) and the other is the "spend" signature of simply the previous output.  The first signature (spending signature) makes that you cannot do double spending any more (you have invalidated the file up to the point where you transmit it), and the second signature allows the receiver to have a valid "new address" that he can spend (and only he, because only he has the secret key that goes with it like on bitcoin).

Well, then I missed something, exactly for the attack I previously mentioned, and your answer.  If the "spend proof" is just a hash which everybody can calculate, then my earlier proposed attack is valid.  Your mentioning of "it can only be send from the right owner", in this language, means a cryptographic *signature* (that's what "send" means here).  Otherwise, if I pay you, I KNOW the transaction and hence the output that you are going to spend, and I CAN calculate the hash of that and post it on the block chain.  If, however, this is not a hash, but a signature with *your private key* (corresponding to the address I'm sending it to), then I cannot post this signature as I know your address, but I don't know your private key.

I see it this way:

The private coin file consists of:
(signature of proof of burn of bitcoin with bitcoin private key that burned it ; transaction containing Joe's address ; transaction containing Jack's address signed with Joe's secret key ; transaction containing Alice's address, signed with Jack's secret key ; ... transaction containing MY address ; transaction containing YOUR address signed with MY key)

On the public block chain, there is the actual burning of the bitcoin  ; .... there must be a spend proof SIGNED BY JOE of of the transaction to Joe so that Jack can verify the spending, but that ONLY JOE can produce.  There must be the hash of the transaction from Jack to Joe.

But now, the spend proof by Jack must be signed with Jack's private key, or otherwise, JOE CAN POST THIS TOO.  However, only Jack can SIGN it.  Alice can verify it, because she has Jack's public key (his address) ; Joe can verify this too, but he doesn't care.  But ONLY JACK MUST BE ABLE TO PRODUCE THE SPEND PROOF.  As such, everybody that Jack would like to take with a double-spend can verify that it was spend (as all of them get the file, and get his public key, and can verify the signature on the block of the previous transaction Joe->Jack).  

A hash is good enough for the new transaction, as this only needs to render the transaction that goes with the spending unique.  
But a hash is not good enough for the spend proof, because otherwise, the previous owner can post it too (with a fake hash of a transaction, rendering the coin unspendable).

You can't redeem BBC back to bitcoin.  "Unburning" would mean dumping the entire history of the coin to the public, which is clearly against its purpose.  But you can exchange it.

The thing is, one could think of a cryptographic way to redeem the bitcoin, instead of burning it, style Lightning network, so that in the end, only one transaction needs to be broadcast, to the final owner.  I don't know exactly how to do this, but it must be possible in some way.

[tonych]

Well, then I missed something, exactly for the attack I previously mentioned, and your answer.  
....

I think you are missing that both hashes that represent the private transaction are already enclosed into a regular public transaction that is signed as usual:

private_transaction: {
  regular_public_inputs: [...],
  regular_public_outputs: [...],
  hash_of_private_payload: ".....",
  spend_proof: "....",
  signature_of_all_the_above: "...."
}

The bolded part is what makes a private transaction different from a regular one.  It is covered by the signature and we know who signed it.

You can't redeem BBC back to bitcoin.  "Unburning" would mean dumping the entire history of the coin to the public, which is clearly against its purpose.  But you can exchange it.

The thing is, one could think of a cryptographic way to redeem the bitcoin, instead of burning it, style Lightning network, so that in the end, only one transaction needs to be broadcast, to the final owner.  I don't know exactly how to do this, but it must be possible in some way.

Still seems unlikely that it is possible, but if you find a way, I'll be glad to know.

[johny08]

make sense the theory. I am excited to see a life real world test if its working. I am pretty sure there will be some flows to be corrected. Simple solutions are almost never working in complex systems.

[spartacusrex]

Hashing is so coool.. 

Confidential Hash Based TXN Chains does something similar..

https://bitcointalk.org/index.php?topic=1298588.0

It only hashes the values.. not the whole TXN, BUT does not need to grow indefinitely (pruneable).

[propcorn]

and how can you get fungibility with this ?

[dzimbeck]

this only works if the payload hash stays the same for each anonymous partner does it not? Otherwise, it would just be a chain of nonsense hashes that could claim to contain anything. A user could collude with themselves and spread fake funds over many accounts with data that is apparently okay as the new recipient can't confirm or deny the validity of previous transactions. It doesn't seem like it would be easy to hide data because the spending transaction needs to get change as well which would have to be public to know quantity.

If the payload hash is always the same i guess it makes sense however it would not allow coins to be subdivided would it not be similar to minting a coin? Also when the data becomes non-private it would be easy to expose everyone involved.