Confidential Transactions: Enhancing Privacy in Bitcoin Transfers

So I’ve been playing around with the new Borromean ringsig for a bigger crypto project, and here’s what I’ve got: Confidential Transactions One of the coolest features being looked at in the Elements sidechain is Confidential Transactions. This cryptographic tech is meant to boost the privacy and security of Bitcoin. With this, the amounts involved in transactions are only visible to the people directly involved (and anyone they choose to share it with). The way Bitcoin’s ledger stays secure is through universal verification. Every user checks every transaction independently, without needing to trust anyone else. The downside? All transaction details have to be public to allow for this verification, which clashes with the usual need for privacy in regular financial dealings. Not having enough financial privacy can lead to big security risks for both personal and business transactions. Without proper safeguards, crooks can zero in on high-value targets, rivals can dig into your business secrets, and your bargaining power can take a hit. Plus, if sharing info often costs money, a lack of privacy could stifle free speech. Also, if privacy is lacking, it can mess with fungibility, meaning some coins could be seen as better or worse than others, which would hurt Bitcoin’s role as a currency.

This should be in the alt-coin section.    Haha, but i am taking a look and it seems very interesting, some of the stuff is above my head but definitely worth studying. I'm glad you branched out and tried something new unburdening yourself of the self-imposed shackles BTC is suffering from.

Sounds like a credible idea for a side-chain for sure. I particularly like how CT could impose a more appropriate data visibility model for bitcoin overall; public transaction information that is required to assure system integrity is still available to all users, and private transaction information that only the involved parties require is now rendered private, yet still provable in a way that anyone can verify if they are provided with the data and the blinding factor. And all without much (arguably none) chain bloat. Off topic  (): when can we expect to see code available that allows a chain like this to be mined?

If this materializes, will we see two kinds of Bitcoins traded in exchanges, standard Bitcoins that trade at $x, and tainted Bitcoins that have been in the privacy sidechain trading at $x/2 or so? OP, would you feel comfortable putting all your BTC through that sidechain?

Taint tracking is inherently against the fungibility property of money.  Moving money into the side chain and back doesn't really do much mixing, since you can still follow the transactions.

Well, I'm impressed. Why you went to the trouble to implement your ring signature scheme makes a lot more sense now.

Perhaps you've not caught on that this makes coinjoins and coinswaps tremendously more private and useful; since joining with anyone at any time improves your privacy, with no need to coordinate values. You can think of it in these terms:  CoinJoin and CoinSwap are efficient metadata privacy protection systems, but their effectiveness is undermined by the content not being private.  CT is a content privacy system. The two compose very nicely. (And the RPCs in elements should be all setup to integrate with external coinjoin.). Uh. Interesting position, (checks posting history), ah. Thanks for taking the time to step away from your ordinary posting in Dash/Darkcoin threads to chime in here.   I reject your premise: A bitcoin system where fungibility had failed enough to produce the situation you described would have already failed as a money. as that outcome would be untenable.  It's also not a theory that is well supported by current practices as there seems to be little such effect for coins moved through a variety of altcoin exchanges which are rumored to be primarily frequented for (inept) money laundering purposes.

Is the exponent also encrypted? And if so, could you give some more detail on how you deal with amounts with different exponents?

Interesting ~ this probably sounds anti-privacy a bit for me to ask perhaps at this stage :-) but do you have a screencap of what it looks like (GUI) when this process (confidential transactions as described thus far in your post) is being done?   (Note:  I haven't dug into Elements... yet. :-) )

There is nothing much to see. You just have an address. You send coins to it.  The fact that the world can't see the values is basically invisible to the user.  Looks just like testnet. From the CLI you can see more. Here is an example where I send 0.25 testnet to myself. $ ./alpha-cli getnewaddress 22E8QKHaTijFemPDwKvAk9qoTgagPfp8nBQiry87MMU1h2gQbF9xzLoyG8oWnakxEcPqQmhDtd2Wrut Cy $ ./alpha-cli sendtoaddress 22E8QKHaTijFemPDwKvAk9qoTgagPfp8nBQiry87MMU1h2gQbF9xzLoyG8oWnakxEcPqQmhDtd2Wrut Cy 0.25 ab4201ee651c1396d35d799e68d59f3bb75581cc7fff1deed5efaf670973fbc9 $ ./alpha-cli listtransactions "*" 2 [     {         "account" : "",         "address" : "22E8QKHaTijFemPDwKvAk9qoTgagPfp8nBQiry87MMU1h2gQbF9xzLoyG8oWnakxEcPqQmhDtd2Wrut Cy",         "category" : "receive",         "amount" : 0.25000000,         "vout" : 0,         "confirmations" : 0,         "txid" : "ab4201ee651c1396d35d799e68d59f3bb75581cc7fff1deed5efaf670973fbc9",         "walletconflicts" : [         ],         "time" : 1433908060,         "timereceived" : 1433908060     },     {         "account" : "",         "address" : "22E8QKHaTijFemPDwKvAk9qoTgagPfp8nBQiry87MMU1h2gQbF9xzLoyG8oWnakxEcPqQmhDtd2Wrut Cy",         "category" : "send",         "amount" : -0.25000000,         "vout" : 0,         "fee" : -0.00005479,         "confirmations" : 0,         "txid" : "ab4201ee651c1396d35d799e68d59f3bb75581cc7fff1deed5efaf670973fbc9",         "walletconflicts" : [         ],         "time" : 1433908060,         "timereceived" : 1433908060     } ] #then we can see how the world sees it. $ ./alpha-cli getrawtransaction ab4201ee651c1396d35d799e68d59f3bb75581cc7fff1deed5efaf670973fbc9 1 {     "txid" : "ab4201ee651c1396d35d799e68d59f3bb75581cc7fff1deed5efaf670973fbc9",     "version" : 1,     "locktime" : 0,     "fee" : 0.00005479,     "vin" : [         {             "txid" : "76c4b906eaebdfc7685d1870aa3c4d57c8dce2fe7b924a7147c410ebffa8bee2",             "vout" : 0,             "scriptSig" : {                 "asm" : "0c0315abc52bced031a61ef1d8987470794540e46890b25b1f0f2b73b39d85ca37056e60fbf9a33 70c11ef7229575d937fd2935c9024ed2b1bc4a6fd473d3a9e01 0359134c3055c290a7a0499f0dfb78742ce964c1c4c8e17407898d5d05956c894e",             },             "sequence" : 4294967295         }     ],     "vout" : [         {             "value-minimum" : 0.00000000,             "value-maximum" : 42.94967295,             "ct-exponent" : 0,             "ct-bits" : 32,             "n" : 0,             "scriptPubKey" : {                 "asm" : "OP_DUP OP_HASH160 fd23ecdd4fb918bd88a319294b1f0ede5f701165 OP_EQUALVERIFY OP_CHECKSIG",                 "reqSigs" : 1,                 "type" : "pubkeyhash",                 "addresses" : [                     "n4bSHiZXaApHquce1KEB8tfCZH7ZpDnUYe"                 ]             }         },         {             "value-minimum" : 0.00000000,             "value-maximum" : 42.94967295,             "ct-exponent" : 0,             "ct-bits" : 32,             "n" : 1,             "scriptPubKey" : {                 "asm" : "OP_DUP OP_HASH160 fd5eff1963631488f624513719e866d92eae83e5 OP_EQUALVERIFY OP_CHECKSIG",                 "hex" : "76a914fd5eff1963631488f624513719e866d92eae83e588ac",                 "reqSigs" : 1,                 "type" : "pubkeyhash",                 "addresses" : [                     "n4cf44LWhzi5KtbTaA1YHFBLWtgn89TF4K"                 ]             }         }     ] }

So, addresses are 0x19: Alpha testnet blinded key 0x6F: Public key flag <public key> <20 byte hash> <CRC> The 20 byte hash is for pay to public key hash.  It seems the public/blinding key operates on a per-wallet basis.  Doesn't that basically kill privacy?

No, because it doesn't show up on the network; though sure it's not ideal-- it was just an implementation expedient: that has no impact on the consensus behavior, and it can be fixed to have one blinding key per scriptpubkey. No-- it could be, but the overhead of that is quite considerable.  The exponent is public (note how it's shown on the getrawtransaction view), and just a property of the range proof, not the value itself-- so there is no complication in combining. It's set to whatever value the user wants, using it doesn't restrict the values you can send, though if your exponent is >0 your least significant digits are non-private.

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 coinjoins 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?

Since this hides transaction amounts doesn't this make CoinJoin impossible at the same time? Attaching transactions between two people or businesses can be a serious breach of privacy even if the actual amounts are unknown.

The output "values" are random looking curve points and proofs that they are within range. You can move them around just like normal coinjoin outputs.  You just have to keep the output value and proof as a single unit. Two sets of fees can be added together too to give one fee output. This means that you can do coinjoin without having to have all the outputs the same amount.

I don't understand how that works. CoinJoin works by rearranging input such that the output values remains the same. If the inputs values are unknown, how could that be calculated? Edit: You can ignore me, it's going to take me a while to wrap my head around this, if I ever manage it. If this protocol does what it says it does, then this is probably the biggest innovation to Bitcoin since.. well.. Ever. Edit2: Speaking of which, is this going to make it to Bitcoin core or is this expected to remain on a sidechain?

Fair enough, but it still works then.  Inputs don't need range proofs.  The coinjoin system can be used to scramble the inputs (as long as they have the right sighash).  The outputs (plus public fee) can be summed and proved to be equal to the sum of the inputs.  There is an additional proof required that all outputs are positive.  This prevents people spending 1BTC and getting -5BTC and 6 BTC, and then just ignoring the -5BTC output.

Inputs do not have an exponent.  The exponent is a property of the range proof, not of the values themselves. They work by scaling the basis the proof operates over. Right now elements alpha wallet only lets the exponent be changed by a config file setting.    This exactly?  No-- but some optimized, mature, and superior version... sometime in the future? I certainly plan to work towards that end. There are other people who work on software in this space which wouldn't support it, however. Aside, as TierNolan pointed out-- this composes perfectly with coinjoin and coinswap, and the interface is setup to facilitate coinjoin already; in coinjoin the participants need not learn each others values.  And in the case of coinswaps the swap transactions can be made indistinguishable from ordinary payments to a single key due to the switch to schnorr signatures.

Summing it up, it really does demonstrably add confidentiality right now, and it can be done at this time.  I'm curious to know only what sort of process would be logical to see this evolve into an option for Core (and ultimately other wallets) - I think someone else asked this in the context of the sidechain question as well (bitcoin core development track or be on sidechain)? (Edit:  I think you answered my question in response to someone else asking the  same thing while I was typing this, basically it sounds like it's unlikely to make it into core in the near term if I understand it properly... it would need some further development and refinement and maybe, more acceptance from core developers?)

No matter how good this gets, the split over block size has caused a rift in BTC users and developers alike, some will be against this just as others fought the raise in block size. This will never get into core, likely we'll have another person threatening a hardfork. It's unfortunate how things turned out. only way this makes it in  is if a ton of concessions are made or they branch off.