public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Ryan Grant <bitcoin-dev@rgrant.org>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Cc: Prayank <prayank@tutanota.de>
Subject: Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects
Date: Fri, 1 Oct 2021 20:15:56 +0000	[thread overview]
Message-ID: <CAMnpzfrNZ0vpiMVoH=0KW9jy1-vppudX3D7Z+aXpSp4h_7s=zw@mail.gmail.com> (raw)
In-Reply-To: <MkwZGYl--7-2@tutanota.de>

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.


  reply	other threads:[~2021-10-01 20:16 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-27  1:52 [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects Prayank
2021-09-27 10:13 ` ZmnSCPxj
2021-09-27 23:19   ` Prayank
2021-09-30 20:36     ` Ruben Somsen
2021-10-01  3:03       ` Prayank
2021-10-01 12:27         ` ZmnSCPxj
2021-10-01 15:55           ` Prayank
2021-10-01 20:15             ` Ryan Grant [this message]
2021-10-02  9:19               ` Prayank
2021-10-03  9:11                 ` Manuel Costa
2021-10-03 21:33                   ` Luke Dashjr
2021-10-04  3:59                     ` ZmnSCPxj
2021-11-18 20:29                       ` Prayank
2022-08-19  3:09                         ` Anthony Towns

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAMnpzfrNZ0vpiMVoH=0KW9jy1-vppudX3D7Z+aXpSp4h_7s=zw@mail.gmail.com' \
    --to=bitcoin-dev@rgrant.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=prayank@tutanota.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox