š
Original date posted:2021-10-02
š Original message: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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211002/2ff6411c/attachment.html>;
Prayank [ARCHIVE] /
npub1xwā¦c2lxh
2023-06-07 22:59:45
in reply to nevent1qā¦55s7
Author Public Key
npub1xwdym5sne88xldc5809azwrgasp60ze27easgew8e7p3vj7qr7ssjc2lxhSeen on
wss://relay.noswhere.comPublished at
2023-06-07 22:59:45Event JSON
{
"id": "65812720a018f81d09a56bf0bfc7e0177f2e9b3a8932d7e21629b9b2c1354fba",
"pubkey": "339a4dd213c9ce6fb7143bcbd13868ec03a78b2af67b0465c7cf83164bc01fa1",
"created_at": 1686178785,
"kind": 1,
"tags": [
[
"e",
"739a040d0d2bf0c2af283f4c1b43b23cd92d356b601102d566ddc7f107759b95",
"",
"root"
],
[
"e",
"492d509508e6c6d20268bcdcd92d7e4d1bb15ea00a64dbf568b047ebff6fb252",
"",
"reply"
],
[
"p",
"2f55bf03677afdb15d004a39383afba6220aa6c059cafa7b8827b87934d3c254"
]
],
"content": "š
Original date posted:2021-10-02\nš Original message:This looks interesting although I don't understand few things:\n\n\u003e The scheme should include public precommitments collected at ceremonial intervals.\n\nHow would this work? Can you explain with an example please.\n\n\u003e Upon assignment, the dev would have community approval to opportunistically insert a security flaw\n\nWho is doing the assignment?\n\n-- \nPrayank\n\nA3B1 E430 2298 178F\n\n\n\nOct 2, 2021, 01:45 by bitcoin-dev at rgrant.org:\n\n\u003e Due to the uneven reputation factor of various devs, and uneven review\n\u003e attention for new pull requests, this exercise would work best as a\n\u003e secret sortition.\n\u003e\n\u003e Sortition would encourage everyone to always be on their toes rather\n\u003e than only when dealing with new github accounts or declared Red Team\n\u003e devs. The ceremonial aspects would encourage more devs to participate\n\u003e without harming their reputation.\n\u003e\n\u003e https://en.wikipedia.org/wiki/Sortition\n\u003e https://en.wikipedia.org/wiki/Red_team\n\u003e\n\u003e The scheme should include public precommitments collected at\n\u003e ceremonial intervals.\n\u003e\n\u003e where:\n\u003e hash1 /* sortition ticket */ = double-sha256(secret)\n\u003e hash2 /* public precommitment */ = double-sha256(hash1)\n\u003e\n\u003e The random oracle could be block hashes. They could be matched to\n\u003e hash1, the sortition ticket. A red-team-concurrency difficulty\n\u003e parameter could control how many least-significant bits must match to\n\u003e be secretly selected. The difficulty parameter could be a matter of\n\u003e group consensus at the ceremonial intervals, based on a group decision\n\u003e on how much positive effect the Red Team exercise is providing.\n\u003e\n\u003e Upon assignment, the dev would have community approval to\n\u003e opportunistically insert a security flaw; which, when either caught,\n\u003e merged, or on timeout, they would reveal along with the sortition\n\u003e ticket that hashes to their public precommitment.\n\u003e\n\u003e Sortition Precommitment Day might be once or twice a year.\n\u003e\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211002/2ff6411c/attachment.html\u003e",
"sig": "62a63a13ebc53ee5df9daa8ca205cab541fc82b85eb0adbde540ada88b624f025859373774cb736427cb6df3a35ed18df8afad1539c4d357de959a348e1f1d3c"
}