Topic: Confidential Transactions, Content privacy for Bitcoin transactions - page 2. (Read 14708 times)

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

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.

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

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.

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.

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

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 ?

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

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.

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.

(excuse obsequiousness but needs must)

#GMAX

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

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.

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.

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. 

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.

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

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)

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

Code:

OP_2 OP_SIDECHAIN_OPERATION

Code:

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.

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.

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.