Author: Manuel Costa 2021-10-03 09:11:53
Published on: 2021-10-03T09:11:53+00:00
The discussion revolves around creating a standardized process for introducing vulnerabilities in Bitcoin's codebase. Two schemes were proposed - a simple scheme and a more complex scheme. The ideal process would involve one person initiating the attempt and randomly choosing a team of insiders to back up their claim. The initial person would then gather signatures for a similar message as described by ZmnSCPxj before going ahead with the attempt. This ensures that the attempt is done in good faith, and other randomly chosen people are in on it, making it difficult to collude with a specific group of people. Additionally, depending on the size of the team to be insiders, there may be a chance of depleting the relevant pool of outsiders.One suggestion for this process was to include public precommitments collected at ceremonial intervals, where a hash1 (sortition ticket) is created using double-sha256(secret) and hash2 (public precommitment) is created using double-sha256(hash1). The random oracle could be block hashes matched to hash1, and the red-team-concurrency difficulty parameter could control how many least-significant bits must match to be secretly selected. Upon assignment, the dev would have community approval to opportunistically insert a security flaw, which they would reveal along with the sortition ticket that hashes to their public precommitment when either caught, merged, or on timeout. Finally, Sortition Precommitment Day might be once or twice a year.
Updated on: 2023-06-15T02:26:32.347948+00:00