+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 7728EC0012

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Thu, 18 Nov 2021 20:29:29 +0000 (UTC)

+Received: from localhost (localhost [127.0.0.1])

+ by smtp2.osuosl.org (Postfix) with ESMTP id 726A9400F2

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Thu, 18 Nov 2021 20:29:29 +0000 (UTC)

+X-Virus-Scanned: amavisd-new at osuosl.org

+X-Spam-Flag: NO

+X-Spam-Score: 0.701

+X-Spam-Level:

+X-Spam-Status: No, score=0.701 tagged_above=-999 required=5

+ tests=[BAYES_50=0.8, 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, TRACKER_ID=0.1]

+ 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 WFOvuXlSzT8L

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Thu, 18 Nov 2021 20:29:28 +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 B54C9400B5

+ for <bitcoin-dev@lists.linuxfoundation.org>;

+ Thu, 18 Nov 2021 20:29:27 +0000 (UTC)

+Received: from w3.tutanota.de (unknown [192.168.1.164])

+ by w1.tutanota.de (Postfix) with ESMTP id D5B48FA0389;

+ Thu, 18 Nov 2021 20:29:24 +0000 (UTC)

+DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1637267364;

+ 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=KkOc+Ga6iEeVKzPb+Km/XOY/ZG7eTSTaO06KFbQVOF0=;

+ b=kn8WPWyGqum9DngYBqBCtEFcAgjN18JNps2uradu1UMvl3lLl2F5VO+Ma+0IvpFg

+ juf+JDYOEEGcBstMs1vVn3TsEs596tntAHQwhjht75ETk1r4coQTCPY1jqk33kI8mTw

+ kCUibK84vYK4xJFcoW8rrz+5MD9wBqgXBUGbW+909MKaHnL98FOTcbDe72U/scazMQy

+ jYoG6O4+kxHv580f2JHgBtm1JUzelpdt5lcQ0SsINn91QY2qPZIJpFxroWoSGWaxbh9

+ N7llLh4rPKTWUOoam/PhuyPAfFcppqHGXwHwXaYZtVwo+m23thjS6gWdEvTBmORVEX0

+ rfPKaVVPCQ==

+Date: Thu, 18 Nov 2021 21:29:24 +0100 (CET)

+From: Prayank <prayank@tutanota.de>

+To: ZmnSCPxj <ZmnSCPxj@protonmail.com>

+Message-ID: <MoojKWD--3-2@tutanota.de>

+In-Reply-To: <sez9AuvBEnKKkLkJ4aivnaLJz5M5VFz3yTOdreTGmFb6RzwMv7h0dRFbEiB1_aup4Daw7t9YwlZKp2YvbgCu1fzym28cHhlzRVC3efmfBpE=@protonmail.com>

+References: <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>

+ <CAAxiurb1_-p2yO8183MvB2x_i9H+WAo9t0RH85faRrrKz9YxGg@mail.gmail.com>

+ <202110032133.44726.luke@dashjr.org>

+ <sez9AuvBEnKKkLkJ4aivnaLJz5M5VFz3yTOdreTGmFb6RzwMv7h0dRFbEiB1_aup4Daw7t9YwlZKp2YvbgCu1fzym28cHhlzRVC3efmfBpE=@protonmail.com>

+MIME-Version: 1.0

+Content-Type: multipart/alternative;

+ boundary="----=_Part_1230047_2095624064.1637267364859"

+X-Mailman-Approved-At: Sat, 20 Nov 2021 00:03:34 +0000

+Cc: Bitcoin Dev <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: Thu, 18 Nov 2021 20:29:29 -0000

+

+------=_Part_1230047_2095624064.1637267364859

+Content-Type: text/plain; charset=UTF-8

+Content-Transfer-Encoding: 7bit

+

+Good morning ZmnSCPxj,

+

+> Indeed, I believe we should take the position that "review process is as much a part of the code as the code itself, and should be tested regularly".

+

+Agree. Review process is an important part of open source Bitcoin projects. We should test and verify if everything is working as expected or there is any scope for improvement.

+

+> as they cannot opt out of "the real thing" other than to stop developing entirely

+

+True and it won't be as obvious as this. Nobody will announce it on dev mailing list and will use proxies (not networks but humans)

+

+After reading all the emails, personally experiencing review process especially on important issues like privacy and security, re-evaluating everything and considering the time I can spend on this, I have decided to do this exercise for 3 projects with just 1 account. I have created a salted hash for the username as you had mentioned in the first email:

+

+f40bcb13dbcbf7b6245becb757777586c22798ed7360cd9853572152ddf07a39

+

+3 Bitcoin projects are Bitcoin Core (full node implementation), LND (LN implementation) and Bisq (DEX).

+

+Pull requests will be created in next 6 months. If vulnerability gets caught during review, will publicly announce here that the project caught the PR and reveal the de-commitment publicly. If not caught during review, will privately reveal both the inserted vulnerability and the review failure via the normal private vulnerability-reporting channels. A summary with all the details will be shared later.

+

+This exercise cannot be same as one of the active developers trying to do the same thing because of few reasons mentioned by Ryan Grant in one of the emails: uneven reputation factor of various devs, and uneven review attention for new pull requests. However, I am expecting few interesting results which will help improve the review process hence make Bitcoin more secure.

+

+Will end the email by rephrasing one of the tweets from a respected cypherpunk recently: Independent thought is critical in aircraft crash investigations and in bitcoin development. Immunity from peer pressure can be very helpful during review process.

+

+

+--

+Prayank

+

+A3B1 E430 2298 178F

+

+

+

+Oct 4, 2021, 09:29 by ZmnSCPxj@protonmail.com:

+

+>

+> Good morning Luke,

+>

+>> All attempts are harmful, no matter the intent, in that they waste

+>> contributors' time that could be better spent on actual development.

+>>

+>> However, I do also see the value in studying and improving the review process

+>> to harden it against such inevitable attacks. The fact that we know the NSA

+>> engages in such things, and haven't caught one yet should be a red flag.

+>>

+>

+> Indeed, I believe we should take the position that "review process is as much a part of the code as the code itself, and should be tested regularly".

+>

+>> Therefore, I think any such a scheme needs to be at least opt-out, if not

+>> opt-in. Please ensure there's a simple way for developers with limited time

+>> (or other reasons) to be informed of which PRs to ignore to opt-out of this

+>> study. (Ideally it would also prevent maintainers from merging - maybe

+>> possible since we use a custom merging script, but what it really needs to

+>> limit is the push, not the dry-run.)

+>>

+>

+> Assuming developers are normal humans with typical human neurology (in particular a laziness circuit), perhaps this would work?

+>

+> Every commit message is required to have a pair of 256-bit hex words.

+>

+> Public attempts at attack / testing of the review process will use the first 256-bit as a salt, and when the salt is prepended to the string "THIS IS AN ATTACK" and then hashed with e.g. SHA256, should result in the second 256-bit word.

+>

+> Non-attacks / normal commits just use random 256-bit numbers.

+>

+> Those opting-out to this will run a script that checks commit messages for whether the first 256-bit hexword concatenated with "THIS IS AN ATTACK", then hashed, is the second 256-bit hexword.

+>

+> Those opting-in will not run that script and ignore the numbers.

+>

+> The script can be run as well at the maintainer.

+>

+> Hopefully, people who are not deliberately opting out will be too lazy to run the script (as is neurotypical for humans) and getting "spoilered" on this.

+>

+> ***HOWEVER***

+>

+> We should note that a putative NSA attack would of course not use the above protocol, and thus no developer can ever opt out of an NSA attempt at inserting vulnerabilities; thus, I think it is better if all developers are forced to opt in on the "practice rounds", as they cannot opt out of "the real thing" other than to stop developing entirely.

+>

+> Regards,

+> ZmnSCPxj

+>

+

+

+------=_Part_1230047_2095624064.1637267364859

+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>Good morning ZmnSCPxj,<br></div><div dir=3D"auto"><br></div><div dir=

+=3D"auto">&gt; Indeed, I believe we should take the position that "review p=

+rocess is as much a part of the code as the code itself, and should be test=

+ed regularly".<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">Agree=

+. Review process is an important part of open source Bitcoin projects. We s=

+hould test and verify if everything is working as expected or there is any =

+scope for improvement.<br></div><div dir=3D"auto"><br></div><div dir=3D"aut=

+o">&gt; as they cannot opt out of "the real thing" other than to stop devel=

+oping entirely<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">True =

+and it won't be as obvious as this. Nobody will announce it on dev mailing =

+list and will use proxies (not networks but humans)<br></div><div dir=3D"au=

+to"><br></div><div dir=3D"auto">After reading all the emails, personally ex=

+periencing review process especially on important issues like privacy and s=

+ecurity, re-evaluating everything and considering the time I can spend on t=

+his, I have decided to do this exercise for 3 projects with just 1 account.=

+ I have created a salted hash for the username as you had mentioned in the =

+first email:<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">f40bcb1=

+3dbcbf7b6245becb757777586c22798ed7360cd9853572152ddf07a39<br></div><div dir=

+=3D"auto"><br></div><div dir=3D"auto">3 Bitcoin projects are Bitcoin Core (=

+full node implementation), LND (LN implementation) and Bisq (DEX).<br></div=

+><div dir=3D"auto"><br></div><div dir=3D"auto">Pull requests will be create=

+d in next 6 months. If vulnerability gets caught during review, will public=

+ly announce here that the project caught the PR and reveal the de-commitmen=

+t publicly. If not caught during review, will privately reveal both the ins=

+erted vulnerability and the review failure via the normal private vulnerabi=

+lity-reporting channels. A summary with all the details will be shared late=

+r.<br></div><div dir=3D"auto"><br></div><div dir=3D"auto">This exercise can=

+not be same as one of the active developers trying to do the same thing bec=

+ause of few reasons mentioned by Ryan Grant in one of the emails: uneven re=

+putation factor of various devs, and uneven review attention for new pull r=

+equests. However, I am expecting few interesting results which will help im=

+prove the review process hence make Bitcoin more secure.<br></div><div dir=

+=3D"auto"><br></div><div>Will end the email by rephrasing one of the tweets=

+ from a respected cypherpunk recently: Independent thought is critical in a=

+ircraft crash investigations and in bitcoin development. Immunity from peer=

+ pressure can be very helpful during review process.<br></div><div dir=3D"a=

+uto"><br></div><div dir=3D"auto"><br></div><div>-- <br></div><div>Prayank<b=

+r></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 4, 2021, 09:29 by ZmnSCPxj=

+@protonmail.com:<br></div><blockquote class=3D"tutanota_quote" style=3D"bor=

+der-left: 1px solid #93A3B8; padding-left: 10px; margin-left: 5px;"><div><b=

+r></div><div>Good morning Luke,<br></div><blockquote><div>All attempts are =

+harmful, no matter the intent, in that they waste<br></div><div>contributor=

+s' time that could be better spent on actual development.<br></div><div><br=

+></div><div>However, I do also see the value in studying and improving the =

+review process<br></div><div>to harden it against such inevitable attacks. =

+The fact that we know the NSA<br></div><div>engages in such things, and hav=

+en't caught one yet should be a red flag.<br></div></blockquote><div><br></=

+div><div>Indeed, I believe we should take the position that "review process=

+ is as much a part of the code as the code itself, and should be tested reg=

+ularly".<br></div><blockquote><div>Therefore, I think any such a scheme nee=

+ds to be at least opt-out, if not<br></div><div>opt-in. Please ensure there=

+'s a simple way for developers with limited time<br></div><div>(or other re=

+asons) to be informed of which PRs to ignore to opt-out of this<br></div><d=

+iv>study. (Ideally it would also prevent maintainers from merging - maybe<b=

+r></div><div>possible since we use a custom merging script, but what it rea=

+lly needs to<br></div><div>limit is the push, not the dry-run.)<br></div></=

+blockquote><div><br></div><div>Assuming developers are normal humans with t=

+ypical human neurology (in particular a laziness circuit), perhaps this wou=

+ld work?<br></div><div><br></div><div>Every commit message is required to h=

+ave a pair of 256-bit hex words.<br></div><div><br></div><div>Public attemp=

+ts at attack / testing of the review process will use the first 256-bit as =

+a salt, and when the salt is prepended to the string "THIS IS AN ATTACK" an=

+d then hashed with e.g. SHA256, should result in the second 256-bit word.<b=

+r></div><div><br></div><div>Non-attacks / normal commits just use random 25=

+6-bit numbers.<br></div><div><br></div><div>Those opting-out to this will r=

+un a script that checks commit messages for whether the first 256-bit hexwo=

+rd concatenated with "THIS IS AN ATTACK", then hashed, is the second 256-bi=

+t hexword.<br></div><div><br></div><div>Those opting-in will not run that s=

+cript and ignore the numbers.<br></div><div><br></div><div>The script can b=

+e run as well at the maintainer.<br></div><div><br></div><div>Hopefully, pe=

+ople who are not deliberately opting out will be too lazy to run the script=

+ (as is neurotypical for humans) and getting "spoilered" on this.<br></div>=

+<div><br></div><div>***HOWEVER***<br></div><div><br></div><div>We should no=

+te that a putative NSA attack would of course not use the above protocol, a=

+nd thus no developer can ever opt out of an NSA attempt at inserting vulner=

+abilities; thus, I think it is better if all developers are forced to opt i=

+n on the "practice rounds", as they cannot opt out of "the real thing" othe=

+r than to stop developing entirely.<br></div><div><br></div><div>Regards,<b=

+r></div><div>ZmnSCPxj<br></div></blockquote><div dir=3D"auto"><br></div> <=

+/body>

+</html>

+

+------=_Part_1230047_2095624064.1637267364859--

+