Topic: Confidential Transactions, Content privacy for Bitcoin transactions (Read 14708 times)

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.

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.

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

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

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.

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.

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

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.

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.

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:

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:

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?

 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.

   



   

Bump.

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

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).

This is about range proofs but I asked about commitments.