Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects
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 ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects
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. 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.) Luke On Sunday 03 October 2021 09:11:53 Manuel Costa via bitcoin-dev wrote: > 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 escreveu no > > dia sábado, 2/10/2021 à(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-...@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. > > > > > > ___ > > bitcoin-dev mailing list > >
[bitcoin-dev] Wednesday’s second BIP process meeting
Wednesday’s second BIP process meeting was announced previously here [0]. A conversation log of the meeting is available here [1]. A summary of the first BIP process meeting is here [2]. The following is a summary of what was discussed. 1) The limits or possible downsides of pursuing maximal decentralization. Understandably there is a desire for greater decentralization as a central repo introduces bottlenecks and the need for maintainers or editors in the case of BIPs (prayank). However, zero filters creates a Ethereum style bewildering number of BIPs of varying quality that all need to be stored and maintained. The option of being able to store a BIP in any repo doesn’t appear to offer material upside (michaelfolkson). It still needs to get a BIP number from the BIP editors and if the alternative repo is deleted or the BIP champion becomes unresponsive there is the problem of changing the location of where the BIP is stored. It is much easier to monitor a single repo rather than an infinite number of repos that contain BIPs. 2) Past motivations for introducing alternative parallel processes to the BIPs (e.g. BOLTs, SLIPs). Anyone is free to set up a repo, add documentation to that repo or even set up a parallel process to the BIPs. However, if as a community we’d like to prevent unnecessary splintering it is good to understand why certain documents that should be BIPed aren’t being BIPed. Obviously not every document needs or should be BIPed. There are many docs that aren’t BIPs that are hugely valuable. One historical concern that was raised (ChristopherA) was regarding why BIP 48 didn’t happen and whether it was because it was coming from the wallet community and not a Bitcoin Core proposal. luke-jr said after the meeting that from recollection the reason it didn’t happen was merely that it was never written [3]. It was also discussed afterwards whether there was/is a rationale for Lightning BOLTs not being BIPs and whether they should be BIPs in future. 3) Kalle Alm’s proposal for BIP extensions [4] was discussed. Participants seemed to be in favor of the proposal though further clarity on when they would and wouldn’t be used was requested. A BIP extension for the bech32m update (BIP 350) to bech32 (BIP 173) seems like it would have been a good use case though further discussion is probably needed on whether they should be used for soft fork activation parameters. It was suggested that using dates and/or short extension names would be superior to extension numbers as numbers suggest an ordering (ChristopherA). The extension 2 may also be perceived as somehow replacing extension 1. Thanks to the participants of both BIP process meetings. Further discussion is welcome on the #bitcoin-dev Libera IRC channel and hopefully we will see progress in the coming weeks and months on a proposed BIP 3 [5] update. [0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019412.html [1]: https://gist.github.com/michaelfolkson/84000ee3fe45c034ac12a7a54ff5fcdd [2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019469.html [3]: https://github.com/bitcoin/bips/pull/253 [4]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-September/019457.html [5]: https://github.com/bitcoin/bips/pull/1015 -- Michael Folkson Email: michaelfolkson at protonmail.com Keybase: michaelfolkson PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Interrogating a BIP157 server, BIP158 change proposal
Jim Posen, A few years ago you mentioned roastbeef’s proposal of a P2P message to retrieve all prev-outputs for a given block: 1) Introduce a new P2P message to retrieve all prev-outputs for a given > block (essentially the undo data in Core), and verify the scripts against > the block by executing them. While this permits some forms of input script > malleability (and thus cannot discriminate between all valid and invalid > filters), it restricts what an attacker can do. This was proposed by Laolu > AFAIK, and I believe this is how btcd is proceeding. > I’m trying to find the follow up on this. Was there discussion about it under another name (thread, PR, bip etc)? Apologies if I’m being obtuse and it’s easily found but for the life of me I can’t find any references. Bip157 seems to not make any mention of it. Thanks! Dustin > If anyone has other ideas, I'd love to hear them. > > -jimpo > > [1] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016057.html > > > > On Mon, Feb 4, 2019 at 10:53 AM Tamas Blummer via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> TLDR: a change to BIP158 would allow decision on which filter chain is >> correct at lower bandwith use >> >> Assume there is a BIP157 client that learned a filter header chain >> earlier and is now offered an alternate reality by a newly connected BIP157 >> server. >> >> The client notices the alternate reality by routinely asking for filter >> chain checkpoints after connecting to a new BIP157 server. A divergence at >> a checkpoint means that the server disagrees the client's history at or >> before the first diverging checkpoint. The client would then request the >> filter headers between the last matching and first divergent checkpoint, >> and quickly figure which block’s filter is the first that does not match >> previous assumption, and request that filter from the server. >> >> The client downloads the corresponding block, checks that its header fits >> the PoW secured best header chain, re-calculates merkle root of its >> transaction list to know that it is complete and queries the filter to see >> if every output script of every transaction is contained in there, if not >> the server is lying, the case is closed, the server disconnected. >> >> Having all output scripts in the filter does not however guarantee that >> the filter is correct since it might omit input scripts. Inputs scripts are >> not part of the downloaded block, but are in some blocks before that. >> Checking those are out of reach for lightweight client with tools given by >> the current BIP. >> >> A remedy here would be an other filter chain on created and spent >> outpoints as is implemented currently by Murmel. The outpoint filter chain >> must offer a match for every spent output of the block with the divergent >> filter, otherwise the interrogated server is lying since a PoW secured >> block can not spend coins out of nowhere. Doing this check would already >> force the client to download the outpoint filter history up-to the point of >> divergence. Then the client would have to download and PoW check every >> block that shows a match in outpoints until it figures that one of the >> spent outputs has a script that was not in the server’s filter, in which >> case the server is lying. If everything checks out then the previous >> assumption on filter history was incorrect and should be replaced by the >> history offered by the interrogated server. >> >> As you see the interrogation works with this added filter but is highly >> ineffective. A really light client should not be forced to download lots of >> blocks just to uncover a lying filter server. This would actually be an >> easy DoS on light BIP157 clients. >> >> A better solution is a change to BIP158 such that the only filter >> contains created scripts and spent outpoints. It appears to me that this >> would serve well both wallets and interrogation of filter servers well: >> >> Wallets would recognize payments to their addresses by the filter as >> output scripts are included, spends from the wallet would be recognized as >> a wallet already knows outpoints of its previously received coins, so it >> can query the filters for them. >> >> Interrogation of a filter server also simplifies, since the filter of the >> block can be checked entirely against the contents of the same block. The >> decision on filter correctness does not require more bandwith then download >> of a block at the mismatching checkpoint. The client could only be forced >> at max. to download 1/1000 th of the blockchain in addition to the filter >> header history. >> >> Therefore I suggest to change BIP158 to have a base filter, defined as: >> >> A basic filter MUST contain exactly the following items for each >> transaction in a block: >> • Spent outpoints >> • The scriptPubKey of each output, aside from all OP_RETURN >> output scripts. >> >> Tamas Blummer >>
Re: [bitcoin-dev] Mock introducing vulnerability in important Bitcoin projects
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 escreveu no dia sábado, 2/10/2021 à(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-...@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. > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
