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
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
|
Return-Path: <truthcoin@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 0CC5FC0011;
Thu, 24 Feb 2022 21:39:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id EDA93402E7;
Thu, 24 Feb 2022 21:39:44 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id jf3E-Xewx_vE; Thu, 24 Feb 2022 21:39:44 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com
[IPv6:2607:f8b0:4864:20::82c])
by smtp4.osuosl.org (Postfix) with ESMTPS id 12BF740183;
Thu, 24 Feb 2022 21:39:43 +0000 (UTC)
Received: by mail-qt1-x82c.google.com with SMTP id f18so761855qtb.3;
Thu, 24 Feb 2022 13:39:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=message-id:date:mime-version:user-agent:content-language:to
:references:from:subject:in-reply-to;
bh=wfumZgQIkWy8tBUdn1kxVbuBs7wIENmDNnnmcIP+4TI=;
b=KyvjRrnBz+qMHD8HIILI9ZrBcvIPjPaVjKJ0MK5/+koF/paZnHtJKUihCiUfvh/5F8
o45OtVR2A4GmgRcDHsc/bn4XaftaH3fxxK3GdrgB2LhXyW9lFaJEEaGj6Filf8B/ZiA5
iKq5ZJnbddWqWF83xJqDGp+Q3kZo1qvl29h6dQtq/rxiyvtJw0/mRWTiuRC/UFHXYIqg
5mxgWxGK9feG6+oC23zb0yUeUu07O9ceVgZz5oqvdTGqZHeizwAC5tOb56pNtDjVBQJk
MTDu8JS7ASuaEsT6iTUdI/3emPPRQGoJoimUbxWwE28OvLwNp78kz8ZbJFIrZNyZY/AN
SVyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:message-id:date:mime-version:user-agent
:content-language:to:references:from:subject:in-reply-to;
bh=wfumZgQIkWy8tBUdn1kxVbuBs7wIENmDNnnmcIP+4TI=;
b=kz3dz6sB/bRGdKggcqeOm35sTj+wNC5uOUJNs25INR5vRhRgef/SP84T1EH7vr0uh4
STIR6oqcezZYtH30W4SmqjMm0K/zHw07ycSsNO+wcMsW8Z5W/mvjByxzgZhOZjqbWatz
4l3lE72CKaReG2fOSdoKB3IfWw2K27NnFSgCYB0a73gz3dH76DY9XOaWawLH0Nq4heyP
EeoXgOt5C5HcH4SXg78IxgQP1pkzA3+S0a+ZBhBsfFuEfhFLDu1stL2Kkrj+MBeloHtc
SD0DrlcElB4fjloOx6tnF497eLKlk4Hhd9/chHPObvtlLVL1rFrvyzbRHB4BK02lmp+Q
RDag==
X-Gm-Message-State: AOAM531oy3YsOEXfZ8aWyJUKmrDcWNWx61U+DFxhzNAaNe5I27zAHKGN
34G4vd0eX8XvqHtYgu8sSNtW10jzrbQ=
X-Google-Smtp-Source: ABdhPJzRhlgT0xHm5wv0e4cMvOzP58zXcTjnVyGI6+UMfb+vlVr6Ah+viLzhLh4YfPeNVgHVoD3ncQ==
X-Received: by 2002:a05:622a:646:b0:2de:8dcb:95a0 with SMTP id
a6-20020a05622a064600b002de8dcb95a0mr4340166qtb.206.1645738782381;
Thu, 24 Feb 2022 13:39:42 -0800 (PST)
Received: from [192.168.0.165] (ool-45714b6d.dyn.optonline.net.
[69.113.75.109]) by smtp.googlemail.com with ESMTPSA id
m2-20020ae9e002000000b0050819df7151sm369342qkk.99.2022.02.24.13.39.41
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Thu, 24 Feb 2022 13:39:42 -0800 (PST)
Content-Type: multipart/alternative;
boundary="------------yJMl0nvCg1Ivscy9UpymGhIp"
Message-ID: <a047803b-0402-895d-f482-750a0dd24716@gmail.com>
Date: Thu, 24 Feb 2022 16:39:40 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Firefox/91.0 Thunderbird/91.5.0
Content-Language: en-US
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
"lightning-dev\\@lists.linuxfoundation.org"
<lightning-dev@lists.linuxfoundation.org>
References: <qfzN-NoT0oDddySCNEPQLaJaEqS56rBGxhD9HKvK6Z6qmdfRBUeeE3GGGpzlZSvwmEZbsL-FEitNm6J_LXKaKfIqlqPPCJ9I_CU2SsY1J8c=@protonmail.com>
From: Paul Sztorc <truthcoin@gmail.com>
In-Reply-To: <qfzN-NoT0oDddySCNEPQLaJaEqS56rBGxhD9HKvK6Z6qmdfRBUeeE3GGGpzlZSvwmEZbsL-FEitNm6J_LXKaKfIqlqPPCJ9I_CU2SsY1J8c=@protonmail.com>
Subject: Re: [bitcoin-dev] A Comparison Of LN and Drivechain Security In The
Presence Of 51% Attackers
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: Thu, 24 Feb 2022 21:39:45 -0000
This is a multi-part message in MIME format.
--------------yJMl0nvCg1Ivscy9UpymGhIp
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
On 2/24/2022 7:49 AM, ZmnSCPxj via bitcoin-dev wrote:
...
>> ... it is easy for 51% hashrate to double-spend in the LN ...
> ... the above statement is unequivocally ***true***.
Both LN and Drivechain are vulnerable to miner-theft; and both use their design to deter theft.
> However, I believe that the following important points must be raised:
>
> * A 51% miner can only attack LN channels it is a participant in.
> * A 51% miner can simultaneously attack all Drivechain-based sidechains and steal all of their funds.
In LN, the main obstacle is that your miner-coalition must first join the channel.
In DC, the main obstacle is that your miner-coalition must construct a txn obeying the Bip300 rules. Knowing that SPV proofs allow miner-theft, the Bip300 rules are designed specifically to try to thwart miner-theft.
***
I don't think I can stop people from being ignorant about Drivechain. But I can at least allow the Drivechain-knowledgable to identify each other.
So here below, I present a little "quiz". If you can answer all of these questions, then you basically understand Drivechain:
0. We could change DC to make miner-theft impossible, by making it a layer1 consensus rule that miners never steal. Why is this cure worse than the disease?
1. If 100% hashrate wanted to steal coins from a DC sidechain *as quickly as possible*, how long would this take (in blocks)?
2. Per sidechain per year (ie, per 52560 blocks), how many DC withdrawals can take place (maximum)? How many can be attempted?
(Ie, how does the 'train track metaphor' work, from ~1h5m in the "Overview and Misconceptions" video)?
3. Only two types of people should ever be using the DC withdrawal system at all.
3a. Which two?
3b. How is everyone else, expected to move their coins from chain to chain?
3c. (Obviously, this improves UX.) But why does it also improve security?
--
4. What do the parameters b and m stand for (in the DC security model)?
5. How can m possibly be above 1? Give an example of a sidechain-attribute which may cause this situation to arise.
6. For which range of m, is DC designed to deter sc-theft?
7. If DC could be changed to magically deter theft across all ranges of m, why would that be bad for sidechain users in general?
--
8. If imminent victims of a DC-based theft, used a mainchain UASF to prohibit the future theft-withdrawal, then how would this affect non-DC users?
9. In what ways might the BTC network one day become uncompetitive? And how is this different from caring about a sidechain's m and b?
--
10. If DC were successful, Altcoin-investors would be harmed. Two Maximalist-groups would also be slightly harmed -- who are these?
***
> Thus, LN usage is safer than Drivechain usage.
Neither LN nor DC, are intended for use by everyone in every circumstance.
DC can simulate a zcash sidechain, but it can not allow for instant off-chain payments. So DC-vs-LN would never be an apples-to-apples comparison, on any criterion.
The end user should be free to decide, what risks they take with their money. Today, users can sell their BTC for Solana (or BSV or whatever). So, to me it seems clear that they should be "allowed" to spend their BTC to a Bip300 script, just as they are allowed to open a LN channel.
-Paul
--------------yJMl0nvCg1Ivscy9UpymGhIp
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">
<div class="moz-cite-prefix">
<pre class="moz-quote-pre" wrap="">On 2/24/2022 7:49 AM, ZmnSCPxj via bitcoin-dev wrote:
...</pre>
</div>
<blockquote type="cite"
cite="mid:qfzN-NoT0oDddySCNEPQLaJaEqS56rBGxhD9HKvK6Z6qmdfRBUeeE3GGGpzlZSvwmEZbsL-FEitNm6J_LXKaKfIqlqPPCJ9I_CU2SsY1J8c=@protonmail.com">
<pre class="moz-quote-pre" wrap=""><blockquote type="cite"><pre>... it is easy for 51% hashrate to double-spend in the LN ...
</pre></blockquote>... the above statement is unequivocally ***true***.
</pre>
</blockquote>
</div>
<pre>
Both LN and Drivechain are vulnerable to miner-theft; and both use their design to deter theft.
<blockquote type="cite"><pre>However, I believe that the following important points must be raised:
* A 51% miner can only attack LN channels it is a participant in.
* A 51% miner can simultaneously attack all Drivechain-based sidechains and steal all of their funds.
</pre></blockquote>
In LN, the main obstacle is that your miner-coalition must first join the channel.
In DC, the main obstacle is that your miner-coalition must construct a txn obeying the Bip300 rules. Knowing that SPV proofs allow miner-theft, the Bip300 rules are designed specifically to try to thwart miner-theft.
***
I don't think I can stop people from being ignorant about Drivechain. But I can at least allow the Drivechain-knowledgable to identify each other.
So here below, I present a little "quiz". If you can answer all of these questions, then you basically understand Drivechain:
0. We could change DC to make miner-theft impossible, by making it a layer1 consensus rule that miners never steal. Why is this cure worse than the disease?
1. If 100% hashrate wanted to steal coins from a DC sidechain *as quickly as possible*, how long would this take (in blocks)?
2. Per sidechain per year (ie, per 52560 blocks), how many DC withdrawals can take place (maximum)? How many can be attempted?
(Ie, how does the 'train track metaphor' work, from ~1h5m in the "Overview and Misconceptions" video)?
3. Only two types of people should ever be using the DC withdrawal system at all.
3a. Which two?
3b. How is everyone else, expected to move their coins from chain to chain?
3c. (Obviously, this improves UX.) But why does it also improve security?
--
4. What do the parameters b and m stand for (in the DC security model)?
5. How can m possibly be above 1? Give an example of a sidechain-attribute which may cause this situation to arise.
6. For which range of m, is DC designed to deter sc-theft?
7. If DC could be changed to magically deter theft across all ranges of m, why would that be bad for sidechain users in general?
--
8. If imminent victims of a DC-based theft, used a mainchain UASF to prohibit the future theft-withdrawal, then how would this affect non-DC users?
9. In what ways might the BTC network one day become uncompetitive? And how is this different from caring about a sidechain's m and b?
--
10. If DC were successful, Altcoin-investors would be harmed. Two Maximalist-groups would also be slightly harmed -- who are these?
***
<blockquote type="cite"><pre>Thus, LN usage is safer than Drivechain usage.
</pre></blockquote>
Neither LN nor DC, are intended for use by everyone in every circumstance.
DC can simulate a zcash sidechain, but it can not allow for instant off-chain payments. So DC-vs-LN would never be an apples-to-apples comparison, on any criterion.
The end user should be free to decide, what risks they take with their money. Today, users can sell their BTC for Solana (or BSV or whatever). So, to me it seems clear that they should be "allowed" to spend their BTC to a Bip300 script, just as they are allowed to open a LN channel.
-Paul
</pre>
</body>
</html>
--------------yJMl0nvCg1Ivscy9UpymGhIp--
|
