Confidential Transactions, Content privacy for Bitcoin transactions

[gmaxwell]

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.

[1715271757]

1715271757

[1715271757]

1715271757

[1715271757]

1715271757

[1715271757]

1715271757

[1715271757]

1715271757

[ABISprotocol]

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.

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.

[TierNolan]

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.

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.

Code:

<refund P2SH hash> <target hash> <sidechain definition> OP_1 OP_SIDECHAIN_OPERATION

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)

Code:

<target hash> <sidechain_identifier> OP_2 OP_SIDECHAIN_OPERATION

Code:

<refund P2SH hash> <target hash> <sidechain_identifier> OP_3 OP_SIDECHAIN_OPERATION

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.

[bitcreditscc]

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.

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.

Code:

<refund P2SH hash> <target hash> <sidechain definition> OP_1 OP_SIDECHAIN_OPERATION

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)

Code:

<target hash> <sidechain_identifier> OP_2 OP_SIDECHAIN_OPERATION

Code:

<refund P2SH hash> <target hash> <sidechain_identifier> OP_3 OP_SIDECHAIN_OPERATION

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

[TierNolan]

Well, 10000 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

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.

testnet <-> any standard side chain

or with mainnet.

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

[jabo38]

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.

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. 

[gmaxwell]

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.

[TheButterZone]

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 and used by default by all ordinary transactions.

[sickpig]

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.

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.

[spartacusrex]

(excuse obsequiousness but needs must)

#GMAX

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

[DumbFruit]

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

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?

"account" : "",

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;

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

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.

[oblivi]

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.

[TierNolan]

Does this mean that only the amount of the transactions will be obfuscated but the addresses still show up in the blockchain?

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

[Nicolas Dorier]

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

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 ?

[DumbFruit]

Will we ever be able to have totally obfuscated transactions that don't even show up in the blockchain (monero style)?

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.

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.

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

Will this be useable within sidechains's "alts" or can you use it within btc transactions too?

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

[smooth]

Will we ever be able to have totally obfuscated transactions that don't even show up in the blockchain (monero style)?

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.

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.

[SuperClam]

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

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.

[Giulio Prisco]

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.

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

[bitcreditscc]

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.

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.

[Giulio Prisco]

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