summaryrefslogtreecommitdiff
path: root/67/c4488b799aea8a07ace887a4820f332c99b8b1
blob: 3cddf982c946b825c20af68b8ae1a9001e52f76e (plain)
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
Return-Path: <ZmnSCPxj@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6B760C001A;
 Sat, 26 Feb 2022 07:39:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 58B9182FEA;
 Sat, 26 Feb 2022 07:39:44 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level: 
X-Spam-Status: No, score=-1.599 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, RCVD_IN_MSPIKE_H5=0.001,
 RCVD_IN_MSPIKE_WL=0.001, 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 WiXk5WiZlZX6; Sat, 26 Feb 2022 07:39:43 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
 [185.70.40.135])
 by smtp1.osuosl.org (Postfix) with ESMTPS id 585B882F31;
 Sat, 26 Feb 2022 07:39:43 +0000 (UTC)
Date: Sat, 26 Feb 2022 07:39:36 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1645861180;
 bh=XCVZVqoMWvC8+TZKjGvlNb49l4NDA4u3KWP+fvnSBds=;
 h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
 References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID;
 b=biFZTrlfhkD4CQ6hVdAYH4mm0DT6vzn5Ifep0ZKb0b/RM3vdpDp31PffdrJCDB3rL
 KBLX3w0EfMcajbQyMiAxvQMX5hQKtyiFdA+uj0HNRaa7qWrWdPEHTcyt4eDdP46ZLh
 qQfagfcAnUzXQaBQzXU1xozWTHavG+nYm8YbkKduAEmOW2ypnG+8U1oxmZoPIc/6cw
 jnz4gFIw2I2syhTGWw6GbEezTNdyTLiBjPPiDehOd+s1B0qvLRwZnMUxHFyUoawX+j
 8qC63Jg0tF2Ge/8IpD513szNeeoTrP9D/19hHwAMM6/mlc08blkP+DUGZaSUat5UxT
 TRt/9/QDE4WLQ==
To: Paul Sztorc <truthcoin@gmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <M6pN0qkZsl6BUonPHbqh9XQNpOnGoywK_muHcMu7Uwtzb1cYyxXaS6T7U1TJ69yf_s95Os3wGq58Ibct5KdGc35gXXB80kDXNJNW7Yb2nc8=@protonmail.com>
In-Reply-To: <a047803b-0402-895d-f482-750a0dd24716@gmail.com>
References: <qfzN-NoT0oDddySCNEPQLaJaEqS56rBGxhD9HKvK6Z6qmdfRBUeeE3GGGpzlZSvwmEZbsL-FEitNm6J_LXKaKfIqlqPPCJ9I_CU2SsY1J8c=@protonmail.com>
 <a047803b-0402-895d-f482-750a0dd24716@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: "lightning-dev\\\\@lists.linuxfoundation.org"
 <lightning-dev@lists.linuxfoundation.org>
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: Sat, 26 Feb 2022 07:39:44 -0000


Good morning Paul,


> 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 laye=
r1 consensus rule that miners never steal. Why is this cure worse than the =
disease?

Now miners are forced to look at all sideblocks, not optionally do so if it=
 is profitable for them.

> 1. If 100% hashrate wanted to steal coins from a DC sidechain *as quickly=
 as possible*, how long would this take (in blocks)?

13,150 (I think this is how you changed it after feedback from this list, I=
 think I remember it was ~3000 before or thereabouts.)

> 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 "Ov=
erview and Misconceptions" video)?

I hate watching videos, I can read faster than anyone can talk (except mayb=
e Laolu, he speaks faster than I can process, never mind read).

~4 times (assuming 52560 block per year, which may vary due to new miners, =
hashrate drops, etc)

> 3. Only two types of people should ever be using the DC withdrawal system=
 at all.
>   3a. Which two?

a.  Miners destroying the sidechain because the sidechain is no longer viab=
le.
b.  Aggregators of sidechain-to-minechain transfers and large whales.

>   3b. How is everyone else, expected to move their coins from chain to ch=
ain?

Cross-system atomic swaps.
(I use "System" here since the same mechanism works for Lightning channels,=
 and channels are not blockchains.)

>   3c. (Obviously, this improves UX.) But why does it also improve securit=
y?

Drivechain-based pegged transfers are aggregates of many smaller transfers =
and thus every transfer out from the sidechain contributes its "fee" to the=
 security of the peg.

> --
> 4. What do the parameters b and m stand for (in the DC security model)?

m is how much people want to kill a sidechain, 0 =3D everybody would be sad=
 if it died and would rather burn all their BTC forever than continue livin=
g, 1 =3D do not care, > 1 people want to actively kill the sidechain.

b is how much profit a mainchain miner expects from supporting a sidechain =
(do not remember the unit though).
Something like u =3D a + b where a is the mainchain, b is the sidechain, u =
is the total profit.
Or fees?  Something like that.

> 5. How can m possibly be above 1? Give an example of a sidechain-attribut=
e which may cause this situation to arise.

The sidechain is a total scam.
A bug may be found in the sidechain that completely negates any security it=
 might have, thus removing any desire to protect the sidechain and potentia=
lly make users want to destroy it completely rather than let it continue.
People end up hating sidechains completely.

> 6. For which range of m, is DC designed to deter sc-theft?

m <=3D 1

> 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?

Because the sidechain would already be part of mainchain consensus.

> --
> 8. If imminent victims of a DC-based theft, used a mainchain UASF to proh=
ibit the future theft-withdrawal, then how would this affect non-DC users?

If the non-DC users do not care, then they are unaffected.
If the non-DC users want to actively kill the sidechain, they will countera=
ttack with an opposite UASF and we have a chainsplit and sadness and mutual=
 destruction and death and a new subreddit.

> 9. In what ways might the BTC network one day become uncompetitive? And h=
ow is this different from caring about a sidechain's m and b?

If it does not enable scaling technology fast enough to actually be able to=
 enable hyperbitcoinization.

Sidechains are not a scaling solution, so caring about m and b is different=
 because your focus is not on scaling.

> --
> 10. If DC were successful, Altcoin-investors would be harmed. Two Maximal=
ist-groups would also be slightly harmed -- who are these?

Dunno!


Regards,
ZmnSCPxj