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
|
Return-Path: <prayank@tutanota.de>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 3B33AC000D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 2 Oct 2021 09:19:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 300CC400EA
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 2 Oct 2021 09:19:42 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, HTML_MESSAGE=0.001,
RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=tutanota.de
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id xxSZRjoUwbLW
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 2 Oct 2021 09:19:40 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162])
by smtp2.osuosl.org (Postfix) with ESMTPS id 86F82400C3
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 2 Oct 2021 09:19:40 +0000 (UTC)
Received: from w3.tutanota.de (unknown [192.168.1.164])
by w1.tutanota.de (Postfix) with ESMTP id C2653FBF64C;
Sat, 2 Oct 2021 09:19:37 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1633166377;
s=s1; d=tutanota.de;
h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender;
bh=4ZcERkBklxdalO1yTMbLV1Y/+9kZKjIJ+gytbwBW0xY=;
b=zzgPnzN3vIUm6WOb5ylsNuCxWc+58JvOa80MqhPQPkUT8fDxgR4gkcRCat2ViYMo
GdeH6Rful6XxFAJGSvM4YTTpjNpIdo7EvJcaWSo8FN9QHx0oa51YwmqNQQsvm7yxCKJ
UlGrPX+JQhYC3hzyujT+konyDHwCNshbANSLFMTd1Uny/8T1Tacx0UG5GolHOUX1i0O
QQdrJFSVcA/dixy3IFYeZLuGBUgaipKMmY7816Sq5VZYk5bPeq5WBhkjBS7BlT/ISKf
k/rQlK+i/a1Rju3pp5yjzjmc6lZ/4nuHRy2XGTzdKwuyrl3s8izqN03ahN72SPe9ajK
jDk5iJVKrw==
Date: Sat, 2 Oct 2021 11:19:37 +0200 (CEST)
From: Prayank <prayank@tutanota.de>
To: Ryan Grant <bitcoin-dev@rgrant.org>
Message-ID: <Ml-IIuL--3-2@tutanota.de>
In-Reply-To: <CAMnpzfrNZ0vpiMVoH=0KW9jy1-vppudX3D7Z+aXpSp4h_7s=zw@mail.gmail.com>
References: <MkZx3Hv--3-2@tutanota.de>
<yp9mJ2Poc_Ce91RkrhjnTA3UPvdh0wUyw2QhRPZEyO3gPHZPhmnhqER_4b7ChvmRh8GcYVPEkoud6vamJ9lGlQPi-POF-kyimBWNHz2RH3A=@protonmail.com>
<MkdYcV9--3-2@tutanota.de>
<CAPv7TjbvRE-b33MeYucUfr6CTooCRSH42hwSn5dMiJ4LODATRQ@mail.gmail.com>
<MktnWM7--3-2@tutanota.de>
<qNjz-H23x07OJjnf5Try4Qp8l5s23SQxhEE8yAfNbrniN34u2vM72FVFSDJxHg4HNTL8tdcm-KKT8h6XVRwOwN0ZmckxzWiMlNFmLbMNuHc=@protonmail.com>
<MkwZGYl--7-2@tutanota.de>
<CAMnpzfrNZ0vpiMVoH=0KW9jy1-vppudX3D7Z+aXpSp4h_7s=zw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_847733_668536719.1633166377777"
X-Mailman-Approved-At: Sat, 02 Oct 2021 09:20:22 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Mock introducing vulnerability in important
Bitcoin projects
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, 02 Oct 2021 09:19:42 -0000
------=_Part_847733_668536719.1633166377777
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
This looks interesting although I don't understand few things:
> The scheme should include public precommitments collected at ceremonial intervals.
How would this work? Can you explain with an example please.
> Upon assignment, the dev would have community approval to opportunistically insert a security flaw
Who is doing the assignment?
--
Prayank
A3B1 E430 2298 178F
Oct 2, 2021, 01:45 by bitcoin-dev@rgrant.org:
> Due to the uneven reputation factor of various devs, and uneven review
> attention for new pull requests, this exercise would work best as a
> secret sortition.
>
> Sortition would encourage everyone to always be on their toes rather
> than only when dealing with new github accounts or declared Red Team
> devs. The ceremonial aspects would encourage more devs to participate
> without harming their reputation.
>
> https://en.wikipedia.org/wiki/Sortition
> https://en.wikipedia.org/wiki/Red_team
>
> The scheme should include public precommitments collected at
> ceremonial intervals.
>
> where:
> hash1 /* sortition ticket */ = double-sha256(secret)
> hash2 /* public precommitment */ = double-sha256(hash1)
>
> The random oracle could be block hashes. They could be matched to
> hash1, the sortition ticket. A red-team-concurrency difficulty
> parameter could control how many least-significant bits must match to
> be secretly selected. The difficulty parameter could be a matter of
> group consensus at the ceremonial intervals, based on a group decision
> on how much positive effect the Red Team exercise is providing.
>
> Upon assignment, the dev would have community approval to
> opportunistically insert a security flaw; which, when either caught,
> merged, or on timeout, they would reveal along with the sortition
> ticket that hashes to their public precommitment.
>
> Sortition Precommitment Day might be once or twice a year.
>
------=_Part_847733_668536719.1633166377777
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"content-type" content=3D"text/html; charset=3DUTF-8=
">
</head>
<body>
<div>This looks interesting although I don't understand few things:<br></di=
v><div dir=3D"auto"><br></div><div dir=3D"auto">> The scheme should incl=
ude public precommitments collected at ceremonial intervals.<br></div><div =
dir=3D"auto"><br></div><div dir=3D"auto">How would this work? Can you expla=
in with an example please.<br></div><div dir=3D"auto"><br></div><div dir=3D=
"auto">> Upon assignment, the dev would have community approval to oppor=
tunistically insert a security flaw<br></div><div dir=3D"auto"><br></div><d=
iv dir=3D"auto">Who is doing the assignment?<br></div><div><br></div><div>-=
- <br></div><div>Prayank<br></div><div><br></div><div dir=3D"auto">A3B1 E43=
0 2298 178F<br></div><div><br></div><div><br></div><div><br></div><div>Oct =
2, 2021, 01:45 by bitcoin-dev@rgrant.org:<br></div><blockquote class=3D"tut=
anota_quote" style=3D"border-left: 1px solid #93A3B8; padding-left: 10px; m=
argin-left: 5px;"><div>Due to the uneven reputation factor of various devs,=
and uneven review<br></div><div>attention for new pull requests, this exer=
cise would work best as a<br></div><div>secret sortition.<br></div><div><br=
></div><div>Sortition would encourage everyone to always be on their toes r=
ather<br></div><div>than only when dealing with new github accounts or decl=
ared Red Team<br></div><div>devs. The ceremonial aspects would encourage m=
ore devs to participate<br></div><div>without harming their reputation.<br>=
</div><div><br></div><div> https://en.wikipedia.org/wiki/Sortition<br></div=
><div> https://en.wikipedia.org/wiki/Red_team<br></div><div><br></div><div>=
The scheme should include public precommitments collected at<br></div><div>=
ceremonial intervals.<br></div><div><br></div><div>where:<br></div><div> ha=
sh1 /* sortition ticket */ =3D double-sha256(secret)<br></div><div> has=
h2 /* public precommitment */ =3D double-sha256(hash1)<br></div><div><br></=
div><div>The random oracle could be block hashes. They could be matched to=
<br></div><div>hash1, the sortition ticket. A red-team-concurrency difficu=
lty<br></div><div>parameter could control how many least-significant bits m=
ust match to<br></div><div>be secretly selected. The difficulty parameter =
could be a matter of<br></div><div>group consensus at the ceremonial interv=
als, based on a group decision<br></div><div>on how much positive effect th=
e Red Team exercise is providing.<br></div><div><br></div><div>Upon assignm=
ent, the dev would have community approval to<br></div><div>opportunistical=
ly insert a security flaw; which, when either caught,<br></div><div>merged,=
or on timeout, they would reveal along with the sortition<br></div><div>ti=
cket that hashes to their public precommitment.<br></div><div><br></div><di=
v>Sortition Precommitment Day might be once or twice a year.<br></div></blo=
ckquote><div dir=3D"auto"><br></div> </body>
</html>
------=_Part_847733_668536719.1633166377777--
|
