Side-chains will introduce a new level of privacy to bitcoin

Here is the post to the thread "Improve transaction privacy / fungibility in Bitcoin Core and the Bitcoin system [meta tracking issues]"

Break it down into the known risks as axioms, then present infinity type assumptions to them to describe the "best" solution in a non-infinity world.

Core Axioms
1. The Internet is based on IP communications.
2. Your direct peers know your IP.
3. Your outputs will be recorded in a public ledger.
4. Your inputs will be recorded in a ledger.
5. Various transaction in the ledger are associated with identities by third-parties.

Second Level Axioms (Networking)
1. The more hops between you and the reader of the ledger, the less chance there is of associating your inputs/outputs with your IP. (Infinite hops eliminates the association.)
2. Encryption between hops can help protect from network snooping.

Third Level Axioms (Transactions)
1. Increased participants in a transaction reduces individual identity. (Infinite participants in a transaction eliminates identity.)
2. Increased anonymity between participants in a transaction decreases identity.
3. Increased cost of transaction (net loss) decreases risk of information gathering only participants.
4. Increased spending stake decreases risk of information gathering only participants.
5. Increased profit stake increases risk of information gathering only participants, and can negate #4.
6. The primary privacy goal is to eliminate the association of the input Bitcoin address from the output address.

Fourth Level Axioms (Randomization Through Pooling)
1. Increased pools size increase individual identity outside pool.
2. Increased hops to pool increases identity within pool.
3. Hashes and public keys can decrease identity within pool.
4. Increasing pool size can increase transaction latency.
5. The pool needs a means of output the transactions in a way that minimizes exposure of input identity.
6. Minimizing viewers of the building of the pool minimizes risk of those outside it identifying participants.
7. Destruction of the pool after it completes its mission minimizes leakage of its internal history. Absolute destruction may not be obtainable, but this is an avenue that could be explored to at least minimize persistence of its past.
8. Separating the input from the output increases privacy.

Looking at this, it appears like a side-chain can be used to build a pool. However, obtaining a desirable size can result in significant latency. Perhaps one inevitable trade-off is increased latency for increased privacy.

The trick is to create a pool protocol with the following goals:
1. Individual nodes, especially non-participants in a pool, have minimal knowledge of each pool while still facilitating its building.
2. Building of the pool is completely decentralized.
2. Have algorithms that match participants to create a complete pool.
3. Have the ability to prove to Bitcoin that the final transaction is authentic.
4. Allows the creator(s) of the final transaction to do so without being participants in it.

Example Use Case
Joe wants to send 1 BTC to Sally. He specifies that the pool size must include no less than 100 participants, and each participant must have a stake of no less than 0.1 BTC.

Joe authorizes the side-chain to withdraw 1 BTC from Bitcoin while securing the output within the side-chain. Only the node who can execute the final pooled transaction with BTC can know the recipient, and that node will by then have no way of knowing it was from Joe. The only known by intermediary nodes is the amount of the transaction. The encrypted output is "authenticated" but unknown.

This permits the authenticated output to become part of the temporary ledge as a candidate for a pool. When enough candidates build, and perhaps other "proof of work" criteria was met, the pool transaction outputs could be sent to Bitcoin. At this point, no details of the pool are persisted within the side-chain.

Challenges
1. Cryptography must hide the destination address from all but the last node.
2. The side-chain must be trust-less, yet be able to act on behalf of Joe with his permission, particularly with regard to withdrawing his BTC.
3. The side-chain must be able to protect Alice's BTC after that point.
4. The final node transferring Alice's BTC must be able to do so, yet without the ability to steal it.
5. The final node should not require any knowledge of how the pool was built. It just knows the requirements were completed.
6. There needs to be a way to ensure that this does not result in duplicate Bitcion transactions. How will the input and output transactions be created on Bitcoin?

This last challenge appears to require that side-chains become a feature of Bitcoins. This could eliminate the concept of a final node completely, as this side-chain could reach consensus and simply "broadcast" the final transaction to Bitcoin. That way, 100 nodes could do this, and it wouldn't matter.

Integrating with Bitcoin
Whether this pooling became a part of the Bitcoin is irrelevant because no matter what, the building of a pool requires a side-chain. It makes sense to just put general side-chain capability in Bitcoin, and just consider this a use-case.

Bitcoin can define this as a collateral side-chain, "locking" withdrawals until outputs are made, maintaining a side-chain balance. This would mean that Joe's 1 BTC would be locked, perhaps with an expiration. Alternately, a side-chain could "deposit" with Bitcoin collateral equal to the maximum withdrawal balance. A hybrid of these two could be possible as well. Regardless, to build a pool totalling 100 BTC these funds would have to either be provided as collateral to Bitcoin first, or temporarily "lock" withdrawals (tx inputs) until the pool dispersed its funds back to Bitcoin (tx outputs). Ideally, many pools would build simultaneously to separate withdrawals from deposits, though. So, we could realistically be talking about 1000 BTC to support 10x100 BTC pools building at once. If it could only build one at a time, then inputs could be associated with output pool.

Side chains can charge TX fees, which can then be used to recoup any collateral, or free up any locked funds. Competition between side chains would keep these fees low.

In any event, I don't see this type of side-chain happening without a well designed fork of Bitcoin to enable it. I also, given the axioms, don't see this type of privacy being possible without a hard fork.

Ironically, I didn't imagine this requiring side chains when I started writing this. This is the first time I really thought it out, as well. Now that I have, I think I really love them. Despite the accusations of them favoring Bitstream, if designed right, they will be equally beneficial to EVERYONE. In this scheme, it is entirely decentralized and trust-less. Anyone can fire up a side-chain and potentially profit from it. Anyone can use any side chain open to the public, such as the privacy one I just described. Public ones will compete, creating an open marketplace. And, as I described, the side-chain itself can choose to be completely decentralized and trust-less. Nodes will have to run it, and will require an incentive, possibly earning transaction fees. But, that's no different than Bitcoin today.

Topic: Side-chains will introduce a new level of privacy to bitcoin (Read 367 times)