1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
|
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 812D2C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Jun 2022 16:37:29 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 6D2DC842F9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Jun 2022 16:37:29 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level:
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
FROM_LOCAL_NOVOWEL=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=protonmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id keGmd-jxS14O
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Jun 2022 16:37:28 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24])
by smtp1.osuosl.org (Postfix) with ESMTPS id 44DF7841B3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 5 Jun 2022 16:37:28 +0000 (UTC)
Date: Sun, 05 Jun 2022 16:37:24 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1654447046; x=1654706246;
bh=6pwwN2NfQS9UMJRdcjM90hzk6Ng+B7D1BaLiZg+0Vl4=;
h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To:
Feedback-ID:Message-ID;
b=OX06MxX/r02OqMa4mvz2aq2h6Ec57u/AFbs8kOwOA6gV9Hcx9tkpwRXN9NfeLAk0n
F/932Jo8YWvJ3p0Gx7FjWCUXIE9o3Jtp+2vR238N95Fg4krRo7jbwmJGefbEvg8nBH
NXVkzKT5pwpDNrFEdAH2lJGA7zdj7bEQEmmPDToL7ZvHr39BgbuHVMkSyg0wYNXjM0
4VSibNzR7d50pm29+WBnGkYEdfoyEqo00nebS4jNIPbM3TrfCPTOu528m14l4UHUpH
8fOboqwoKLis8kK682eH9wYCM/cqr8jErWbnKpfaI2NU0MuFdnska/vroAQomkAjNe
24UBxSfGrdOJA==
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 05 Jun 2022 16:37:29 -0000
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
|
