前情提要：tieba.baidu.com/p/8616342054
经过了 70+ 次的游玩上传，我得到了这个结论：“推分保护”是存在的。
验证过程最简单的描述如图所示：

在 id727 之前主要为了完成 “清理R30、充填R30” 等一系列实验所需的操作，所以该 R30 队列是与远程同步的。
此时R30的尾部是这样的：

“蓝字”部分用于证明本地 R30 队列是与远程是同步的。相关截图如下：




在此之后，R-29和R-30都被挤出 R30 队列了。
红字部分表示：三次推分后上传成绩都发生了本地 PTT 与远程 PTT 不同步。下面是三次提交推分成绩的 PTT 变化截图：
id729:



id730:



id731:




(id731截图的时候没有把本地变化截上，所以这里补一张通知的正文)
“紫字” 部分表示：不触发保护机制时，PTT变化等价于重放了 “红字” 的PTT变化，“红字”部分 原本应该扣的 PTT 被推迟到 “紫字”部分 才扣，说明 "红字"部分 触发了保护机制，R30 演算选择置换整个队列最低的成绩，而不是把尾部直接挤出队列来演算 R30。
以下是上传后PTT变化截图：



我认为这些数据和截图可以证明 “推分保护” 的存在，毕竟实验结果是我预想中的。
不过我还是不敢过于绝对，8u萌看看能不能找一下这个验证过程存在的漏洞。
好累......