Good morning vjudeu,
> Some people think that sidechains are good. But to put them into some working > solution, people think that some kind of soft-fork is needed. However, it > seems that it can be done in a no-fork way, here is how to make it > permissionless, and introduce them without any forks. > > First, we should make a new chain that has zero coins. When the coin supply > is zero, it can be guaranteed that this chain is not generating any coins out > of thin air. Then, all that is needed, is to introduce coins to this chain, > just by signing a transaction from other chains, for example Bitcoin. In this > way, people can make signatures in a signet way, just to sign their > transaction output of any type, without moving real coins on the original > chain. > > Then, all that is needed, is to make a way to withdraw the coins. It could be > done by publishing the transaction from the original chain. It can be > copy-pasted to our chain, and can be used to destroy coins that were produced > earlier. In this way, our Merge-Mined chain has zero supply, and can only > temporary store some coins from other chains. > > Creating and destroying coins from other chains is enough to make a test > network. To make it independent, one more thing is needed, to get a mainnet > solution: moving coins inside that chain. When it comes to that, the only > limitation is the locking script. Normally, it is locked to some public key, > then by forming a signature, it is possible to move coins somewhere else. In > the Lightning Network, it is solved by forming 2-of-2 multisig, then coins > can be moved by changing closing transactions. > > But there is another option: transaction joining. So, if we have a chain of > transactions: A->B->C->...->Z, then if transaction joining is possible, it > can be transformed into A->Z transaction. After adding that missing piece, > sidechains can be enabled. > > > However, I mentioned before that this solution would require no forks. It > could, if we consider using Homomorphic Encryption. Then, it is possible to > add new features, without touching consensus. For example, by using > Homomorphic Encryption, it is possible to execute 2-of-2 multisig on some > P2PK output. That means, more things are possible, because if we can encrypt > things, then operate on encrypted data, and later decrypt it (and broadcast > to the network), then it can open a lot of new possible upgrades, that will > be totally permissionless and unstoppable. > > So, to sum up: by adding transaction joining in a homomorphic-encryption-way, > it may be possible to introduce sidechains in a no-fork way, no matter if > people wants that or not. Also, it is possible to add the hash of our chain > to the signature inside a Bitcoin transaction, then all data from the "zero > supply chain" can be committed to the Bitcoin blockchain, that would prevent > overwriting history. Also, Merged Mining could be used to reward sidechain > miners, so they will be rewarded inside the sidechain. I proposed something similar years ago --- more specifically, some kind of general ZKP system would allow us to pretty much write anything, and if it terminates, we can provide a ZKP of the execution trace. At the time it was impractical due to the ZKP systems of the time being *still* too large and too CPU-heavy *and* requiring a tr\*sted setup. Encrypting the amount in a homomorphic encryption such as Pedersen commitments / ElGamal commitments is how MimbleWimble coins (such as Grin) work. They achieve transactional cut-through in a similar manner due to the homomorphic encryption being what is validated by validators without revealing the exact balances, and with the only requirement being that a set of consumed outputs equals the set of created outputs (fees being an explicit output that has no encryption, and thus can be claimable by anyone and have a known value, which basically means that it is the miner that mines the transaction that can claim it). Regards, ZmnSCPxj Regards, ZmnSCPxj _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
