Bitcoin Forum

I mentioned that I was using the new Borromean ringsig (https://bitcointalk.org/index.php?topic=1077994.0) as a building block for a larger cryptosystem, Here it is:

Confidential Transactions

One of the most powerful new features being explored in the Elements (https://bitcointalk.org/index.php?topic=1085271.0) sidechain is Confidential Transactions, a cryptographic tool to improve the privacy and security of Bitcoin. This feature keeps the amounts transferred visible only to participants in the transaction (and those they designate).

The security of the Bitcoin ledger is made possible by universal verification: each participant individually and autonomously verifies that each transaction is valid, without trusting any third party.  An unfortunate side effect is that all the transaction data must be conspicuously public so it can be verified, which is at odds with the normal expectation of privacy for traditional monetary instruments.

Insufficient financial privacy can have serious security and privacy implications for both commercial and personal transactions. Without adequate protection, thieves and scammers can focus their efforts on known high-value targets, competitors can learn business details, and negotiating positions can be undermined. Since publishing often requires spending money, lack of privacy can chill free speech.  Insufficient privacy can also result in a loss of fungibility--where some coins are treated as more acceptable than others--which would further undermine Bitcoin's utility as money.

Bitcoin partially addresses the privacy problem by using pseudonymous addresses. If someone does not know which users own which addresses, the privacy impact is reduced. But any time you transact with someone you learn at least one of their addresses. From there, you can trace out other connected addresses and estimate the values of their transactions and holdings. For example, suppose your employer pays you with Bitcoin and you later spend those coins on your rent and groceries. Your landlord and the supermarket will both learn your income, and could charge you higher prices as your income changes or target you for theft.

There are existing deployed techniques that further improve privacy in Bitcoin (such as CoinJoin, which merges the transaction history of users by making joint payments), but the utility of these techniques is reduced by the fact that it's possible to track amounts.

There have been proposed cryptographic techniques to improve privacy in Bitcoin-like systems, but so far all of them result in breaking "pruning" (section 7 of Bitcoin.pdf) and result in participants needing a perpetually growing database to verify new transactions, because these systems prevent learning which coins have been spent. Most proposed cryptographic privacy systems also have poor performance, high overhead, and/or require new and very strong (and less well understood) cryptographic assumptions.

Confidential Transactions improves the situation by making the transaction amounts private, while preserving the ability of the public network to verify that the ledger entries still add up. It does this without adding any new basic cryptographic assumptions to the Bitcoin system, and with a manageable level of overhead.

CT is possible due to the cryptographic technique of additively homomorphic commitments. As a side-effect of its design, CT also enables the additional exchange of private "memo" data (such as invoice numbers or refund addresses) without any further increase in transaction size, by reclaiming most of the overhead of the CT cryptographic proofs.


The technology behind Confidential Transactions
A high level technical primer

---

This work was originally proposed by Adam Back on Bitcointalk in his 2013 thread "bitcoins with homomorphic value" (https://bitcointalk.org/index.php?topic=305791.0). To build CT I had to implement several new cryptosystems which work in concert, and invented a generalization of ring signatures and several novel optimizations to make the result reasonably efficient.

The basic tool that CT is based on is a Pedersen commitment.

A commitment scheme lets you keep a piece of data secret but commit to it so that you cannot change it later. A simple commitment scheme can be constructed using a cryptographic hash:

  commitment = SHA256( blinding_factor || data )

If you tell someone only the commitment then they cannot determine what data you are committing to (given certain assumptions about the properties of the hash), but you can later reveal both the data and the blinding factor and they can run the hash and verify that the data you committed to matches. The blinding factor is present because without one, someone could try guessing at the data; if your data is small and simple, it might be easy to just guess it and compare the guess to the commitment.

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

In other words, the commitment preserves addition and the commutative property applies.

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

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

and so on.

Our specific Pedersen commitments are constructed using elliptic curve points. [The reader need not understand elliptic curve cryptography, beyond accepting the black box behaviors I describe here.]

Normally an ECC pubkey is created by multiplying a generator for the group (G) with the secret key (x):
  Pub = xG

The result is usually serialized as a 33-byte array.

ECC public keys obey the additively homomorphic property mentioned before:

   Pub1 + Pub2 = (x1 + x2 (mod n))G.

(This fact is used by the BIP32 HD wallet scheme to allow third parties to generate fresh Bitcoin addresses for people.)

The Pedersen commitment is created by picking an additional generator for the group (which we'll call H) such that no one knows the discrete log for H with respect to G (or vice versa), meaning no one knows an x such that xG = H. We can accomplish this by using the cryptographic hash of G to pick H:

    H = to_point(SHA256(ENCODE(G)))

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.  You can verify just using the commutative property of addition that all the relationships given for an additively homomorphic commitment scheme hold.

The Pedersen commitments are information-theoretically private: for any commitment you see, there exists some blinding factor which would make any amount match the commitment. Even an attacker with infinite computing power could not tell what amount you committed to, if your blinding factor was truly random. They are computationally secure against fake commitment, in that you can't actually compute that arbitrary mapping; if you can it means you can find the discrete log of the generators with respect to each other, which means that the security of the group is compromised.

With this tool in hand we can go and replace the normal 8-byte integer amounts in Bitcoin transactions with 33-byte Pedersen commitments.

If the author of a transaction takes care in picking their blinding factors so that they add up correctly, then the network can still verify the transaction by checking that its commitments add up to zero:

    (In1 + In2 + In3 + plaintext_input_amount*H...) -
     (Out1 + Out2 + Out3 + ... fees*H) == 0.

This requires making the fees in a transaction explicit, but that's generally desirable.

The commitment and its checking are quite simple. Unfortunately, without additional measures this scheme is insecure.

The problem is that the group is cyclic, and addition is mod P (a 256-bit prime number that defines the order of the group). As a result, addition of large values can 'overflow' and behave like negative amounts. This means that a sums-to-zero behavior still holds when some outputs are negative, effectively allowing the creation of 5 coins from nothing:

 (1 + 1) - (-5 + 7) == 0

This would be interpreted as "someone spends two bitcoins, gets a '-5' bitcoin out that they discard out, and a 7 bitcoin output".

In order to prevent this, when there are multiple outputs we must prove that each committed output is within a range which cannot overflow (e.g. [0, 2^64)).

We could just disclose the amounts and blinding factors so that the network could check, but this would lose all of the privacy. So, instead, we need to prove that a committed amount is within the range but reveal nothing else about it: we need an additional cryptosystem to prove the range of a Pedersen commitment. We use a scheme similar to Schoenmakers’ binary decomposition but with many optimizations (including not using binary).

To build this we start with a basic EC signature. If a signature is constructed so that the 'message' is the hash of the pubkey, the signature proves that the signer knew the private key, which is the discrete log of the pubkey with respect to some generator.

For a 'pubkey' like P = xG + aH, no one knows the discrete log of P with respect to G because of the addition of H, because no one knows an x for xG = H----_unless_ a is 0. If a is zero then P = xG and the discrete log is just x; someone could sign for that pubkey.

A pedersen commitment can be proven to be a commitment to a zero by just signing a hash of the commitment with the commitment as the public key. Using the public key in the signature is required to prevent setting the signature to arbitrary values and solving for the commitment. The private key used for the signature is just the blinding factor.

Going further, let’s say I want to prove C is a commitment to 1 without telling you the blinding factor. All you do is compute

   C' = C - 1H

and ask me to provide a signature (with respect to G) with pubkey C'. If I can do that, the C must be a commitment to 1 (or else I've broken the EC discrete log security).

To avoid giving away the amount we need yet another cryptographic construct: a ring signature.  A ring signature is a signature scheme where there are two (or more) pubkeys and the signature proves that the signer knows the discrete log of at least one of the pubkeys.

So with that we can construct a scheme where I prove a commitment that C is either 0 or 1--we call this an "OR proof".

First, I give you C, and you compute C':

    C' = C - 1H

Then I provide a ring signature over {C, C'}.

If C was a commitment to 1 then I do not know its discrete log, but C' becomes a commitment to 0 and I do know its discrete log (just the blinding factor). If C was a commitment to 0 I know its discrete log, and I don't for C'.  If it was a commitment to any other amount, none of the result will be zero and I won't be able to sign.

This works for any pair of numbers, just by suitably pre-processing the amounts that are put into the ring... or even for more than two numbers.

Say I want to prove to you that C is in the range [0, 32). Now that we have an OR proof, imagine I send you a collection of commitments and OR proofs for each of them:

C1 is 0 or 1 C2 is 0 or 2 C3 is 0 or 4 C4 is 0 or 8 C5 is 0 or 16.

If I pick the blinding factors for C1..5 correctly then I can arrange it so that C1 + C2 + C3 + C4 + C5 == C.  Effectively I have built up the number in binary, and a 5-bit number can only be in the range [0,32).

Numerous optimizations are required to make this more efficient:

First, I propose a new ring signature formulation, a Borromean ring signature

• , which is especially efficient: it requires only 32 bytes per pubkey, plus 32 bytes which can be shared by many separate rings. This is has twice the asymptotic efficiency of previously proposed constructions for this application.
• https://github.com/Blockstream/borromean_paper/raw/master/borromean_draft_0.01_34241bb.pdf

Instead of expressing the amount directly, CT amounts are expressed using a decimal floating point where the digits are multiplied by a base 10 exponent.  This means that you can prove large amounts with small proofs, so long as they have few significant digits in base 10: e.g., 11.2345 and .0112345 can have the same size proof, even though one number is a thousand times larger.

There is also a non-private "minimum amount" sent, which allows a smaller proof to cover a larger range if the user doesn't mind leaking some information about the minimum amount (which might already be public for external reasons); this also allows the least significant digits to be non-zero when an exponent is used. Minimum amounts are supported by first subtracting the minimum, then proving that the result is non-negative.

The mantissa of the floating point is encoded using rings of size 4 (base 4) rather than binary, because this minimizes the number of commitments sent while not using any more signature data than base 2.

The final mantissa digit commitment can be skipped, backwards constructing it from the value being proven and the other digits, etc.

Finally, by careful use of derandomized signing in the prover, it's possible for the receiver of the coins--who shares a secret with the sender, due to ECDH key agreement with the receivers pubkey--to 'rewind' the proof and use it to extract a message sent by the sender which is 80% of the size of the proof.  We use this to signal the value and blinding factor to the receiver, but it could also be used to carry things like reference numbers or refund addresses.

The result is that a proof for a 32-bit value is 2564 bytes, and simultaneously may convey 2048 bytes of message. A 32-bit proof can cover a range of 42.94967296 BTC with 1e-8 precision, or 429.4967296 BTC with 1e-7 precision, and so on. My implementation is able to verify over 1300 32-bit range proofs per second on an i7-4770R, and there are many performance optimizations still possible.

The implementation supports proofs of any mantissa size or exponent, with the parameters controlled by the sender. Performance and size are linear in the number of mantissa bits, and odd numbers of bits are supported (by switching to radix-2 for the last digit).

In Elements, the range proofs are only required in cases where there are multiple confidential value outputs (including fees).  Transactions that merge multiple confidential amounts into a single output do not need range proofs since the fact that all the inputs were in range is sufficient.

By sharing the scanning key used to establish the shared secret used by the rewindable range proofs, this approach is completely compatible with watching wallets; users can share these keys with auditors to enable them to view their transaction amounts.

Future work may use the fact that proofs can support a minimum value to also allow skipping the range proofs when there is a single confidential output even when fees are being paid, or allow nodes to skip or delay verifying most range proofs by using fraud proofs.

The system presented here depends on no new fundamental cryptographic assumptions, only the hardness of the discrete log problem in the secp256k1 group and a random oracle assumption, just like the normal signatures in Bitcoin.

While the size of the range proofs are non-trivial, they are still an order of magnitude smaller and faster to verify than some alternatives (like Zerocoin), and most of their space can be reclaimed to communicate additional data between users, a feature which is often requested but hard to justify in a public broadcast network. Similar to signatures, the range proofs can be placed on separate tree branches in blocks to allow clients that don’t care about (e.g. historical ones) to skip receiving them.

Most importantly, this scheme is compatible with pruning and does not make the verification state for Bitcoin grow forever. It is also compatible with CoinJoin and CoinSwap, allowing for transaction graph privacy as well while simultaneously fixing the most severe limitation of these approaches to privacy (that transaction amounts compromise their privacy).

Unlike some other proposals, this system is not just speculation or pure cryptography without integration with the Bitcoin system.

Confidential Transactions is enabled in Elements (https://bitcointalk.org/index.php?topic=1085271.0) and used by default by all ordinary transactions.

The source code for the just the underlying cryptosystem is also available (https://github.com/ElementsProject/secp256k1-zkp/commit/bd067945ead3b514fba884abd0de95fc4b5db9ae).

This should be in the alt-coin section.   :D

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  (;D): 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.

Don't be so sure. I think there is at least even odds that the recent drama will ultimately make it easier to deploy improved privacy in the system.

This is somewhat OT probably, but look at it this way... suppose this effort to force everyone to go and accept the hard fork doesn't go exactly the way some people think it does... the consensus / acceptance isn't there and it just flops ~ which I submit is actually an outcome with a fairly high degree of probability... suppose on the other hand there would actually occur a hard fork (which we don't need and I don't support - there are other ways to handle the issues beyond Gavin's proposal to move to XT).

In the latter example, the Confidential Transactions would still work, but it would (like a lot of things, or maybe... everything else?) be even more difficult to implement, because people would be trying to determine how to work it into _two_ big things over time rather than one (both XT and Core, because for those who do not change to the new fork [that is, who remain with their current version of their wallet software, etc] they would be with the old one and still be doing transactions, of course).

(edit:  From a post at http://cointelegraph.com/news/114505/web-wallet-providers-divided-over-andresens-20-mb-block-size-increase-proposal - Coinkite Founder and CTO Peter D. Gray commented,
"I think if no consensus is found, that we probably will not have a fork. If the major Bitcoin miners do not endorse the new specification, and Bitcoin-Xt goes in some other direction, then it would become an altcoin, and 'not bitcoin'. For hard-fork decisions like this one on the table, the miners have basically all the power needed to set policy. And that's how it should be.”)

In any event, it should be clear that the "hard fork" presents additional complications... which make things more difficult... and IMHO the hard fork is unnecessary, but I won't get into why here.

Again, I feel I am straying OT from the primary substance of this post, but maybe it was necessary to mention it anyway in response to the question presented.

A feature they could add would be direct sidechain support of some kind.  This would give the following

testnet <-> elements <-> any standard side chain

This would require a definition of a side chain.  It would have to be limited so that it is compatible, but it could still be made pretty flexible.

The specification would only need to define how "unlock" transactions are encoded in the side chain.  All side chains would need to have a standard header chain.  

A soft fork on mainnet could be used to add new POW (or POS or whatever) hashing methods for side chains.

The merkle tree could be hash(unlock_outputs_merkle_root || sidechain_specific_merkle_root).  The side-chain can do whatever it wants with the side-chain specific root.

If this was included with mainnet, then elements itself could use it to connect to mainnet.

A soft fork could add the new opcodes to mainnet.


This defines a new side chain.  It would include info on how to parse the header chain for the side chain and also how long the lock timeout should take.

New POW algorithms could be added using a soft fork.

A minimum output value could be used to prevent spamming (say 10 BTC)

<sidechain_identifier> = hash(<sidechain definition>)
<target hash> = target of coins on the sidechain (sidechain specific meaning [20 bytes])
<refund P2SH> = P2SH address to claim the output (valid until the sidechain activates)


These operations lock the output on mainnet.  The refund P2SH is only needed until the sidechain activates.

When more than 1000 BTC is moved to a sidechain, it activates.  This locks all funds sent to the side chain for 1024 blocks.  This is to give miners a chance to SPV sync with the sidechain's header chain.

1000 BTC might be to low.  Potentially, there could be 21,000 side-chains.

Well, 1000 BTC is too high, hell even 10 BTC would be rejected. Also if BTC adds sidechain support based on this, people will want it to be

testnet <-> elements <-> any standard side chain

testnet <-> any standard side chain

This is the total locked funds for a side chain.  You are expecting the bitcoin miners to track your chain, so some spam/DOS protection is needed. 

The 100 largest altcoin has a market cap of around $150k.  That would be around the 1000 BTC mark.

Starting side chains wouldn't have that much capital though.

Side chains could be recommended to start with a federated peg like Elements.  The P2SH refund script could be pay to multi-sig.  Once the sidechain activates (>100BTC capital), then the federation would be automatically disbanded.


or with mainnet.

The point is that elements could demonstrate that it works before adding it to mainnet.

as far as I understand both sidechains and blocksize increase will need a hardfork.  There might be some grand compromise where both sides agree to let the other sides project in. 

Thats a complete misunderstanding, and I have no clue where you could have gotten it from-- can you specify so I can go hunt down that location and get them to fix it?  PM please-- this is offtopic for this thread.

I won't be so sure. Just to make an example: Justus Ranvier want to completely remove the max size cap, but at the same time really he does want confidential transaction integrated into the bitcoin protocol (check his btctalk post history to get a proof).

I think that btc devs are infelligent enough to evaluate properly and objectively new ideas. That said, everything could happen.

(excuse obsequiousness but needs must)

#GMAX

'When you realise you're in the presence of greatness..'

Ok, so at the end of this we have a series of signatures that prove that the signers know the Blinding Factor that corresponds to the commitments that are either 0 or a number and corresponds to C which (in this example) is a number between 0(inclusive) and 32.
Shouldn't this be the equation?
C1 + C2 + C3 + C4 + C5 <= C (Since the miner only knows C is [0,32) )
Edit: Nope. This would be the same thing: 0 <= C1 +C2 +C3 +C4 + C5 < 32

What's this "account" line for?

So the miner doesn't need to verify,  or know, the transaction amounts because the sender can only create a valid public key that corresponds to a valid Blinding Factor (private key) that corresponds to a valid transaction amount? Normally, this could be attacked by a sender repeatedly spending to a valid amount, but this would create negative outputs, that you prevent by also having users prove that all outputs are positive, which you talk about here;


Am I sort of on the right track?
Edit2: Nope, that has nothing to do with the "negative outputs" problem. (1) - (1 + 1) != 0

One thing I'm still not getting is couldn't you repeatedly spend in the same block? So if you have a valid 2 btc transaction (From a 2btc output), could you keep sending transactions from that output like 1.9, 1.8, and so on (Which the miner would see as C1, C2, etc), none of which would appear negative until one is accepted in a block.
Edit3: Presumably all outputs from an input must be sequential, and is verified accordingly.

Does this mean that only the amount of the transactions will be obfuscated but the addresses still show up in the blockchain? Im a math and coding retard so I need this in layman words to know what this feature exactly does.
Will this be useable within sidechains's "alts" or can you use it within btc transactions too?
Will we ever be able to have totally obfuscated transactions that don't even show up in the blockchain (monero style)? what is the impact of such improvements in privacy regulations wise? i don't think the government will like the idea of it because they can't tax your shit. If it's difficult now with coin mixers and whatever, imagine in the future.

You are supposed to use a different address for each transaction anyway.

Each transaction will effectively say "Address X paid Address Y some amount (possibly zero)".

How can it be integrated in Bitcoin, to what I have see, it needs a new way to represent the value of a TxOut.
It would need a new version of transaction to work with bitcoin right ?

Monero uses Cryptonote which uses ring signatures to hide the sender of any given transaction such that it isn't possible to accurately connect given outputs with given inputs unless the sender revealed that information. Last I knew transactions, and their amounts, definitely were openly visible on their blockchain.

This problem is inversely proportional to how decentralized the system is. Check out "torrents" for reference.

This will be available on Bitcoin core after a hard fork. When that happens you'll hear about it..

Somewhat. Amounts are broken up into power-of-10 denominated pieces and each piece may be payment to one or another payee, or change. So the amount is obfuscated by the number of ways the pieces can be allocated into these bins.

So a payment of 100+20+3 could be a payment of 23 and change of 100, a payment of 120 and change of 3, two separate payments of 100 and 3 along with change of 20, etc. When there are more pieces the number of possible combinations increases.

It isn't true, however, that Monero transactions are something that doesn't even show up on a blockchain. They do show up and the total amount (payments plus change plus fee) can be seen as equal to the total inputs, which helps visible integrity of the money supply. You don't have a complete black box like zerocash where certain types of flaws could mean that infinite coins could be created (as was once possible in Bitcoin due to a bug) and never detected. Although you still do need to rely on the integrity of Monero's key images to ensure coins can't be double spent.

Strong of ideals.

Walking the moral road is rarely accomplished without conflict.

Keep walking, Gregory Maxwell - the quality of our children's future may well depend on it.

But isn't innovation outside core exactly what sidechains are for?

Ah...in theory...

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

I fully support undoing the patch that limited blocks down to 1 MB, let's revert to the original plan. But that alone is not enough, which is why i  also support ideas like this as well, to create a more rounded and robust solution together.

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.

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?

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.

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

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

This is about range proofs but I asked about commitments.

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

No, see above.

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.

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

Bump.

 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.