Date: Sun, 05 Jun 2022 16:37:24 +0000
To: vjudeu@gazeta.pl,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <_Wxebx3JnH8Rt96A6OJjHaGDvElF_k7ezcQBFbdJ--fITmbuiv7dhg84ie4lSfLaf9OchIexAjs1bnltz5jagajhlQoqX_-aAhN6abpvVJ8=@protonmail.com>
In-Reply-To: <162963804-b06af81ec3655f4e1950de9136310c7a@pmq3v.m5r2.onet>
References: <162963804-b06af81ec3655f4e1950de9136310c7a@pmq3v.m5r2.onet>
Feedback-ID: 2872618:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] Using Merged Mining on a separate zero supply
	chain, instead of sidechains
Precedence: list


Good morning vjudeu,


> Some people think that sidechains are good. But to put them into some wor=
king 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 perm=
issionless, and introduce them without any forks.
>
> First, we should make a new chain that has zero coins. When the coin supp=
ly is zero, it can be guaranteed that this chain is not generating any coin=
s 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 the=
ir transaction output of any type, without moving real coins on the origina=
l chain.
>
> Then, all that is needed, is to make a way to withdraw the coins. It coul=
d 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 produc=
ed earlier. In this way, our Merge-Mined chain has zero supply, and can onl=
y 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 co=
ins 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 piec=
e, 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 t=
o add new features, without touching consensus. For example, by using Homom=
orphic Encryption, it is possible to execute 2-of-2 multisig on some P2PK o=
utput. That means, more things are possible, because if we can encrypt thin=
gs, 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 c=
hain 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 si=
dechain 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 *st=
ill* too large and too CPU-heavy *and* requiring a tr\*sted setup.

Encrypting the amount in a homomorphic encryption such as Pedersen commitme=
nts / ElGamal commitments is how MimbleWimble coins (such as Grin) work.
They achieve transactional cut-through in a similar manner due to the homom=
orphic encryption being what is validated by validators without revealing t=
he exact balances, and with the only requirement being that a set of consum=
ed 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 kno=
wn value, which basically means that it is the miner that mines the transac=
tion that can claim it).

Regards,
ZmnSCPxj

Regards,
ZmnSCPxj