Confidential Transactions, Content privacy for Bitcoin transactions

[bitcreditscc]

But for this to work it has to be tethered to the BTC chain...and there we'll have our Bitcoin world war II

In fact, I foresee considerable opposition to implement sidechain hooks in Bitcoin Core. But sidechains can add so much value to Bitcoin that the change is likely to be implemented. If not, Bitcoin might soon become obsolete and give way to an equivalent network that implements extensibility via sidechains.

I wonder what happens when the regulators realize that sidechains can put privacy and anonymity back ;-)

It won't be "considerable" this is likely to be all out war, think about the statements made by core devs with regard to alternate coins.....then they go and cook this up.... so they will get immense push back for that, then there is the personal interest vector, then there are those who will oppose a means of getting back @ them for this block size issue

All this before technical debates have even started...

[Carlton Banks]

But for this to work it has to be tethered to the BTC chain...and there we'll have our Bitcoin world war II

In fact, I foresee considerable opposition to implement sidechain hooks in Bitcoin Core. But sidechains can add so much value to Bitcoin that the change is likely to be implemented. If not, Bitcoin might soon become obsolete and give way to an equivalent network that implements extensibility via sidechains.

I wonder what happens when the regulators realize that sidechains can put privacy and anonymity back ;-)

It won't be "considerable" this is likely to be all out war, think about the statements made by core devs with regard to alternate coins.....then they go and cook this up.... so they will get immense push back for that, then there is the personal interest vector, then there are those who will oppose a means of getting back @ them for this block size issue

All this before technical debates have even started...

What you're underestimating is the duration of the war. Sure, it will spread confusion, anger, defiance etc, but trends are so short these days, it'll probably blow over in a week or two. XT comes to irritate every now and again, but the enthusiasm doesn't last long.

[bitcreditscc]

But for this to work it has to be tethered to the BTC chain...and there we'll have our Bitcoin world war II

In fact, I foresee considerable opposition to implement sidechain hooks in Bitcoin Core. But sidechains can add so much value to Bitcoin that the change is likely to be implemented. If not, Bitcoin might soon become obsolete and give way to an equivalent network that implements extensibility via sidechains.

I wonder what happens when the regulators realize that sidechains can put privacy and anonymity back ;-)

It won't be "considerable" this is likely to be all out war, think about the statements made by core devs with regard to alternate coins.....then they go and cook this up.... so they will get immense push back for that, then there is the personal interest vector, then there are those who will oppose a means of getting back @ them for this block size issue

All this before technical debates have even started...

What you're underestimating is the duration of the war. Sure, it will spread confusion, anger, defiance etc, but trends are so short these days, it'll probably blow over in a week or two. XT comes to irritate every now and again, but the enthusiasm doesn't last long.

We can only hope....

What i hate the most is today's cat rustling type of journalism. Somehow they can take any issue and whip up the world into a frenzy blowing things way out of proportion and spreading panic. Most of the crashes this week can be attributed to media's doomsday kind of reporting, if they even get a whiff of another issues, we'll all rue the day.

[ABISprotocol]

Hello,

To gmaxwell,

Recently I posted an update to this page at https://abisprotocol.github.io/ABIS/

See commit at: https://github.com/ABISprotocol/ABIS/commit/6cfce05d65bcabe6d8529ac429ea48aee5214e96

Wondering what you think of this development and how the concept could be used for development of both private and small transactions in bitcoin?

[tonych]

Given our two generators we can build a commitment scheme like this:

   commitment = xG + aH

Here x is our secret blinding factor, and a is the amount that we're committing to.  

Does it mean that x and a are to be communicated privately (off-chain) from sender to recipient of coins? Anything else that is communicated privately?

Also, are commitments required for outputs only or you need to include input commitments as well in your transaction data? If including input commitments, I wonder if it makes sense changing their blinding factors, not just copying them from source outputs.

[gmaxwell]

Does it mean that x and a are to be communicated privately (off-chain) from sender to recipient of coins? Anything else that is communicated privately?
Also, are commitments required for outputs only or you need to include input commitments as well in your transaction data? If including input commitments, I wonder if it makes sense changing their blinding factors, not just copying them from source outputs.

x is private by virtue of being the conveyed by an ECDH key negotiation. No external communication is required.  (E.g. go build elements alpha, and give me an address from it and I'll send you some coins!).

They're required for outputs only, and technically only when there are multiple outputs. Inputs are already known to be in range by virtue of having been created as outputs.

[tonych]

x is private by virtue of being the conveyed by an ECDH key negotiation. No external communication is required. 

Do the wallets still need to connect directly, without touching the blockchain? How the receiver would learn the amount then?

(E.g. go build elements alpha, and give me an address from it and I'll send you some coins!).

Do I have to be online at the same time as you?

They're required for outputs only, and technically only when there are multiple outputs. Inputs are already known to be in range by virtue of having been created as outputs.

This is about range proofs but I asked about commitments.

[waxwing]

x is private by virtue of being the conveyed by an ECDH key negotiation. No external communication is required.  

Do the wallets still need to connect directly, without touching the blockchain? How the receiver would learn the amount then?

No, the idea is that addresses in Elements alpha contain an ECDH pubkey, so the sender can (non-interactively) send secret information to the receiver using ECDH key exchange. The amount of the transaction output is embedded into the range proof, without taking up more space (it's actually XORed in). No prior interaction is needed between sender and receiver (that's a pretty fundamental requirement of course).

Do I have to be online at the same time as you?

No, see above.

They're required for outputs only, and technically only when there are multiple outputs. Inputs are already known to be in range by virtue of having been created as outputs.

This is about range proofs but I asked about commitments.

Both Pedersen commitments and range proofs are published to the network for each vout (utxo).

You might find this doc I wrote useful if you're looking into the details: https://github.com/AdamISZ/ConfidentialTransactionsDoc/blob/master/essayonCT.pdf. For example, the diagram at the end (page 20) of the transaction layout.

[tonych]

You might find this doc I wrote useful if you're looking into the details: https://github.com/AdamISZ/ConfidentialTransactionsDoc/blob/master/essayonCT.pdf. For example, the diagram at the end (page 20) of the transaction layout.

Thanks, the doc was very useful for understanding the details.

[ABISprotocol]

Bump.

[neerajmittal]

 Well, I'm impressed. Why you went to the trouble to implement your ring signature scheme makes a lot more sense now.Since the vast majority of transactions will be <42.94967295 BTC, almost all transactions will have exponent zero. So, transactions with exponent >0 will stand out and be much less anonymous. And the inputs and outputs to coin joins will need to have the same exponent.Nothing against it, the space saved is worth the loss of anonymity for very large transactions. But it is probably best to warn people about it so that no one uses confidential transactions incorrectly.Also, if I have several inputs with different exponents (let's say 0,1 and 2) and I want join them into a single ouput, will the protocol force me to have two outputs (with exp 0 and 2) or will it round down the amount.

   



   

[BlackHatCoiner]

A Pedersen commitment works like the above but with an additional property: commitments can be added, and the sum of a set of commitments is the same as a commitment to the sum of the data (with a blinding key set as the sum of the blinding keys):

  C(BF1, data1) + C(BF2, data2) == C(BF1 + BF2, data1 + data2) C(BF1, data1) - C(BF1, data1) == 0

There's a mistake in that line, which confused me at first, but then I saw the same introduction of CT in your old webpage, where you have it corrected: http://web.archive.org/web/20150628230410/https://people.xiph.org/~greg/confidential_values.txt.

It's:

Code:

C(BF1, data1) + C(BF2, data2) == C(BF1 + BF2, data1 + data2)
C(BF1, data1) - C(BF1, data1) == 0

That change of line is important, otherwise it seems like you're multiplying commitments. I don't know if Pederson's commitment multiplication makes any sense, it certainly does not in here. Only addition.


In my understanding, and please correct me if I'm wrong, there's a direct connection between blinding factor (r) and data (a). Taking the example by gmaxwell:

If data_n = {1,1,2} and BF_n = {5,10,15} then:

  C(BF1, data1) + C(BF2, data2) - C(BF3, data3) == 0

It is clear that, just as data1 + data2 = data3, the same equation applies with BF_n values. Therefore, if I'm spending input_1 and input_2 to create input_3, does the recipient need to know BF1 and BF2, so that they can construct BF3? Is BF3 known by both the sender and the receiver?

[gmaxwell]

Indeed, that was a lost linebreak in the post.

The recipient needs to know the blinding factor of their output at least to spend the coin.


But the sender and the recipient have a shared secret,  e.g. the recipient has a public key and the sender has a public key (their address),  so the parties can ECDH to get a shared secret.

In the CT implementation I created I went a step forward and used the shared secret to derive a key used for generating all the randomness in the range proof.  The recipient can undo that randomness and extract data hidden inside the range proof...  though this means almost the entire size of the range proof can be recovered as a communication channel from payer to payee.

There has been subsequent development, particular of bulletproofs which is much more communications and computationally efficient than big CT style range proofs, and much more flexible too.  Their smaller size more than makes up for the fact that they don't support the trick of hiding data in the range proof's randomness.

[BlackHatCoiner]

But the sender and the recipient have a shared secret,  e.g. the recipient has a public key and the sender has a public key (their address),  so the parties can ECDH to get a shared secret.

So that's how the sender can pay the recipient non-interactively.

There has been subsequent development, particular of bulletproofs which is much more communications and computationally efficient than big CT style range proofs, and much more flexible too.

Does Liquid use a more communications and computationally efficient CT?

Has it ever been proposed in Bitcoin? It's a shame Bitcoin can't have even this decent privacy improvement with minor burden placed on verification.

[gmaxwell]

I don't really know what liquid's doing, it was released a fair time after I left blockstream.  I think I'd heard that it was still on the original CT, though they had developed an upgrade using one of the successor systems but it wasn't deployed yet.  This could be outdated.

These systems make difficult tradeoffs, as the technology improves maybe it would be easier to make a case for deploying them.  Fortunately there are other privacy techniques that work today without additions to the system, though they're not a one to one alternative.

[BlackHatCoiner]

These systems make difficult tradeoffs

I get the tradeoff of solutions like ring signatures (spend index size and transaction size orders larger), or stealth addresses (scanning all transactions), but what's so difficult tradeoff with CT? The computation is very inexpensive, as far as I understand, and the transaction is slightly larger in size.

I personally like this solution more than ring signatures and stealth addresses, if I had to choose one. You're certain that it works, there is no attack vector, as in ring signatures, and it certainly does a lot better in terms of privacy than stealth addresses.

[gmaxwell]

These systems make difficult tradeoffs

I get the tradeoff of solutions like ring signatures (spend index size and transaction size orders larger), or stealth addresses (scanning all transactions), but what's so difficult tradeoff with CT? The computation is very inexpensive, as far as I understand, and the transaction is slightly larger in size.

I personally like this solution more than ring signatures and stealth addresses, if I had to choose one. You're certain that it works, there is no attack vector, as in ring signatures, and it certainly does a lot better in terms of privacy than stealth addresses.

The proofs are big, so significant tx size increases, and a crypto break results in undetectable inflation.

[Kruw]

The proofs are big, so significant tx size increases, and a crypto break results in undetectable inflation.

I remember this undetectable inflation issue happened with Zcash: https://bitcoinist.com/zcash-inflation-bug-infinite-tokens/

[BlackHatCoiner]

The proofs are big, so significant tx size increases, and a crypto break results in undetectable inflation.

Indeed. It can go up to 3x the size of a regular Bitcoin transaction, so my bad. It'd be better then if confidential transactions happened on a layer on top.

Regarding undetectable inflation, this could occur if an efficient algorithm for solving the discrete logarithm problem is discovered, to the best of my understanding. However, in that scenario, wouldn't all the cryptographic primitives that Bitcoin relies on become obsolete? For instance, even if undetectable inflation doesn't happen, there would be no security, as private keys could be computed from public keys.

[gmaxwell]

The proofs are big, so significant tx size increases, and a crypto break results in undetectable inflation.

Indeed. It can go up to 3x the size of a regular Bitcoin transaction, so my bad. It'd be better then if confidential transactions happened on a layer on top.

Regarding undetectable inflation, this could occur if an efficient algorithm for solving the discrete logarithm problem is discovered, to the best of my understanding. However, in that scenario, wouldn't all the cryptographic primitives that Bitcoin relies on become obsolete? For instance, even if undetectable inflation doesn't happen, there would be no security, as private keys could be computed from public keys.

There could just be a flaw in an implementation rather than a DL break.  Monero suffered from that, for example-- they implemented a CT variant over ed25519 instead of secp256k1 and didn't correctly extinguish the cofactor, making it possible to spend coins multiple times.  Fortunately the nature of that break was such that you could detect it once you knew about it, so they were able to verify that it got fixed before it was exploited (some other blockchains were not so lucky, however).

But also, in the case of a DL break being used against private keys there are alternative signature systems that could be easily deployed... either in advance when it seemed a break was likely or in response to initial theft (which might well be limited due to to the computational cost of the attack).    This all would be bad of course, but nowhere near as bad as someone undetectable printing coins out of thin air for years.

There are options, for example if the privacy is optional and the whole pool of private coins share a limit on the number of coins that can be withdrawn then if there were concerns of a break people could pull their coins out of the private bucket and when the public counter of coins  in it hits zero no more withdraws are possible--  limiting the exposure.

But it might be better to develop schemes which are unconditionally sound.

There are also some middle ground techniques that might be possible... that's why is an open area of research.