From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3B33AC000D for ; 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 ; 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 ; 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 ; 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 To: Ryan Grant Message-ID: In-Reply-To: References: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
This looks interesting although I don't understand few things:

> The scheme should incl= ude public precommitments collected at ceremonial intervals.

How would this work? Can you expla= in with an example please.

> Upon assignment, the dev would have community approval to oppor= tunistically insert a security flaw

Who is doing the assignment?

-= -
Prayank

A3B1 E43= 0 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 exer= cise would work best as a
secret sortition.
Sortition would encourage everyone to always be on their toes r= ather
than only when dealing with new github accounts or decl= ared Red Team
devs. The ceremonial aspects would encourage m= ore 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:
ha= sh1 /* sortition ticket */ =3D double-sha256(secret)
has= h2 /* 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 difficu= lty
parameter could control how many least-significant bits m= ust match to
be secretly selected. The difficulty parameter = could be a matter of
group consensus at the ceremonial interv= als, based on a group decision
on how much positive effect th= e Red Team exercise is providing.

Upon assignm= ent, the dev would have community approval to
opportunistical= ly insert a security flaw; which, when either caught,
merged,= or on timeout, they would reveal along with the sortition
ti= cket that hashes to their public precommitment.

Sortition Precommitment Day might be once or twice a year.

------=_Part_847733_668536719.1633166377777--