path: root/d1/493a5756bf4e47b7ce2e146947308664186089

Return-Path: <manecosta@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 079CFC000D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  3 Oct 2021 09:12:07 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id D4E584019B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  3 Oct 2021 09:12:06 +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: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
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 AX06t33maJlg
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  3 Oct 2021 09:12:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-pj1-x1035.google.com (mail-pj1-x1035.google.com
 [IPv6:2607:f8b0:4864:20::1035])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 55A51400F3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun,  3 Oct 2021 09:12:05 +0000 (UTC)
Received: by mail-pj1-x1035.google.com with SMTP id
 d13-20020a17090ad3cd00b0019e746f7bd4so1765241pjw.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 03 Oct 2021 02:12:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=xcfaHw8Zq6xMkPp4ocIpfaz8je6o+S23DvYEI6jIy18=;
 b=M63VAtIXrG6s/73mWAmwDI6to5gj2D5m0cd2+cOaVutdJTbCCHjgdk1QXbtvaf8fwc
 marK2Bdw75aaNgD8bsN+MNPe+3dKllKwca5W7Iju8wKdJCwQtdJuddKEKaeDq5Ld2smU
 TJj/8g8rN4OFszqKUPHFCrVjC+rNIo0n20sHx+ZTpbew5nfw9Aza40DFVQPoLDTNrki8
 PER4GVSsTN76EAQipEmPbruC6IeHPne6wNx7Ac4HDyEuBrkTfAyZj1uKjdBMCA7qxjQ9
 hJpSH1f2QZ3rOp8rxYLIdDrBxVyrhfJ6xoA/CzuK+C9FWrdIO1AeWEffizLLJS7V5YOE
 0lPQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=xcfaHw8Zq6xMkPp4ocIpfaz8je6o+S23DvYEI6jIy18=;
 b=Gry4JPQZCr/IcYLNwBGQYP3vkGZ9N7sSGsPRnPlCQkPfr3DpkpwB+8vE8hs369bB06
 DSrZZQK46N6B33GixK1a+sV1GZlZ1ST5hXjzjUgqysaayT7kKv6YCAV/3VMtU8nNL1vL
 sViQ5tYYf6oYQqxDoy5xIszX2GuJv56qJRCUJhroquyLxzUw0g0yhrUL8th0cQiQQWAC
 N/pWxnGxc0IiVeUhxCs2VEvG0tLcsjgzWM3egP4tiqX0QVLh/T9J6kWoJL2Rv3SHe9Oo
 ClmWuKz2WaUcH0jBmc8URyAudQQFDnqTWyQO6DWu/+DcdsgzSE5+KFaaVgUFrilhA5w1
 SP6g==
X-Gm-Message-State: AOAM533av6q0RW37iOPFgA/3wvTQhKQhcx827e2AnFehO9nZBzHF+wZm
 l0eKEqLNBBLQI9cOpTL23ouC2+GPTykxhiSKAmFYguRcLxc=
X-Google-Smtp-Source: ABdhPJxXj5O9OTeLtieXAY9K0u6eLfRJ2GSatwXm0g1AazNeQeyrsX8AKex2h1oZGKkE/LFP2TRRkbw9sSdM9yU0jmQ=
X-Received: by 2002:a17:90a:af92:: with SMTP id
 w18mr23558168pjq.98.1633252324703; 
 Sun, 03 Oct 2021 02:12:04 -0700 (PDT)
MIME-Version: 1.0
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>
 <Ml-IIuL--3-2@tutanota.de>
In-Reply-To: <Ml-IIuL--3-2@tutanota.de>
From: Manuel Costa <manecosta@gmail.com>
Date: Sun, 3 Oct 2021 10:11:53 +0100
Message-ID: <CAAxiurb1_-p2yO8183MvB2x_i9H+WAo9t0RH85faRrrKz9YxGg@mail.gmail.com>
To: Prayank <prayank@tutanota.de>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000a484f005cd6f3041"
X-Mailman-Approved-At: Sun, 03 Oct 2021 15:08:45 +0000
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: Sun, 03 Oct 2021 09:12:07 -0000

--000000000000a484f005cd6f3041
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Good morning everyone,

Just wanted to point out a few things for discussion which may or may not
be obvious:

1) A simple scheme as described by ZmnSCPxj first can lead way for a
standardized process where people can excuse their legitimate attempts to
actually introduce vulnerabilities, where they create the precommit and
then attempt to introduce the vulnerability. If it goes wrong they have
plausible deniability by revealing it and possibly saving their reputation.
2) A more complex scheme as described by Ryan (from my very rough
understanding) seems to imply a random selection of team for attempting the
attack, which might be limiting, since someone willing to do it and with
enough knowledge to attempt it properly might not be picked.

It seems to me that an ideal process would start from the will to attempt
it from one person (or group), which then by some process similar to what
Ryan described will pick at random a team of people to back up his claim to
be doing it in good faith. With that selection done, the initial person
would warn and gather from the randomly chosen participants a set of
signatures for a similar message as described by ZmnSCPxj and only then go
ahead with the attempt. This way you achieve:

- One person can initiate it at will.
- Other people (provably chosen at random) are insiders to that information
and have a shared precommit.
- You can't not reveal your intent in case it isn't caught, since other
randomly chosen people are in on it.
- You can't pick a specific group of people which might be willing to
collude with you to achieve a similar situation to 1).

Another important consideration is that depending on the size of the team
to be insiders, we might by chance deplete the relevant pool of outsiders
which would be adequate for reviewing the specific details of the
vulnerability being introduced.

Prayank via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> escreveu no
dia s=C3=A1bado, 2/10/2021 =C3=A0(s) 10:20:

> 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 */ =3D double-sha256(secret)
> hash2 /* public precommitment */ =3D 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.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000a484f005cd6f3041
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Good morning everyone,<d=
iv><br></div><div>Just wanted to point out a few things for discussion whic=
h may or may not be obvious:</div><div><br></div><div>1) A simple scheme as=
 described by ZmnSCPxj first can lead way for a standardized process where =
people can excuse their legitimate attempts to actually introduce vulnerabi=
lities, where they create the precommit and then attempt to introduce the v=
ulnerability. If it goes wrong they have plausible deniability by revealing=
 it and possibly saving their reputation.</div><div>2) A more complex schem=
e as described by Ryan (from my very rough understanding) seems to imply a =
random selection of team for attempting the attack, which might be limiting=
, since someone willing to do it and with enough knowledge to attempt it pr=
operly might not be picked.<br><br>It seems to me that an ideal process wou=
ld start from the will to attempt it from one person (or group), which then=
 by some process similar to what Ryan described will pick at random a team =
of people to back up his claim to be doing it in good faith. With that sele=
ction done, the initial person would warn and gather from the randomly chos=
en participants a set of signatures for a similar message as described by=
=C2=A0ZmnSCPxj and only then go ahead with the attempt. This way you achiev=
e:<br><br>- One person can initiate it at will.<br>- Other people (provably=
 chosen at random) are insiders to that information and have a shared preco=
mmit.<br>- You can&#39;t not reveal your intent in case it isn&#39;t caught=
, since other randomly chosen people are in on it.<br>- You can&#39;t pick =
a specific group of people which might be willing to collude with you to ac=
hieve a similar situation to 1).</div><div><br></div><div>Another important=
 consideration is that depending on the size of the team to be insiders, we=
 might by chance deplete the relevant pool of outsiders which would be adeq=
uate for reviewing the specific details of the vulnerability being introduc=
ed.</div></div></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">Prayank via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-=
dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt=
; escreveu no dia s=C3=A1bado, 2/10/2021 =C3=A0(s) 10:20:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">
 =20
   =20
 =20
  <div>
<div>This looks interesting although I don&#39;t understand few things:<br>=
</div><div dir=3D"auto"><br></div><div dir=3D"auto">&gt; The scheme should =
include public precommitments collected at ceremonial intervals.<br></div><=
div dir=3D"auto"><br></div><div dir=3D"auto">How would this work? Can you e=
xplain with an example please.<br></div><div dir=3D"auto"><br></div><div di=
r=3D"auto">&gt; Upon assignment, the dev would have community approval to o=
pportunistically insert a security flaw<br></div><div dir=3D"auto"><br></di=
v><div dir=3D"auto">Who is doing the assignment?<br></div><div><br></div><d=
iv>-- <br></div><div>Prayank<br></div><div><br></div><div dir=3D"auto">A3B1=
 E430 2298 178F<br></div><div><br></div><div><br></div><div><br></div><div>=
Oct 2, 2021, 01:45 by <a href=3D"mailto:bitcoin-dev@rgrant.org" target=3D"_=
blank">bitcoin-dev@rgrant.org</a>:<br></div><blockquote style=3D"border-lef=
t:1px solid rgb(147,163,184);padding-left:10px;margin-left:5px"><div>Due to=
 the uneven reputation factor of various devs, and uneven review<br></div><=
div>attention for new pull requests, this exercise would work best as a<br>=
</div><div>secret sortition.<br></div><div><br></div><div>Sortition would e=
ncourage everyone to always be on their toes rather<br></div><div>than only=
 when dealing with new github accounts or declared Red Team<br></div><div>d=
evs.  The ceremonial aspects would encourage more devs to participate<br></=
div><div>without harming their reputation.<br></div><div><br></div><div> <a=
 href=3D"https://en.wikipedia.org/wiki/Sortition" target=3D"_blank">https:/=
/en.wikipedia.org/wiki/Sortition</a><br></div><div> <a href=3D"https://en.w=
ikipedia.org/wiki/Red_team" target=3D"_blank">https://en.wikipedia.org/wiki=
/Red_team</a><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> hash1 /* sortition ticket */     =
=3D double-sha256(secret)<br></div><div> hash2 /* public precommitment */ =
=3D double-sha256(hash1)<br></div><div><br></div><div>The random oracle cou=
ld be block hashes.  They could be matched to<br></div><div>hash1, the sort=
ition ticket.  A red-team-concurrency difficulty<br></div><div>parameter co=
uld control how many least-significant bits must match to<br></div><div>be =
secretly selected.  The difficulty parameter could be a matter of<br></div>=
<div>group consensus at the ceremonial intervals, based on a group decision=
<br></div><div>on how much positive effect the Red Team exercise is providi=
ng.<br></div><div><br></div><div>Upon assignment, the dev would have commun=
ity approval to<br></div><div>opportunistically insert a security flaw; whi=
ch, when either caught,<br></div><div>merged, or on timeout, they would rev=
eal along with the sortition<br></div><div>ticket that hashes to their publ=
ic precommitment.<br></div><div><br></div><div>Sortition Precommitment Day =
might be once or twice a year.<br></div></blockquote><div dir=3D"auto"><br>=
</div>  </div>

_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000a484f005cd6f3041--