Skip to content

用哈希抽奖,先胡个提案,如果可行就使用这个仓库

Notifications You must be signed in to change notification settings

pkuphysu/HashDraw

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

6 Commits
 
 

Repository files navigation

HashDraw

用哈希抽奖,先胡个提案,如果可行就使用这个仓库

导语

众所周知,抽奖程序一度不会拥有很高的信任度。尤其是当 js 的Math.random()在抽奖过程中的有限次实验中,出现了一些“统计性”偏差时,很显然会遭到质疑。

新方案

使用哈希抽奖,就可以一定程度上避免质疑暗箱操作的情况。

可行性:

  • 作为物院同学,即使不知道哈希的概念,进行节目现场普及,也是很容易就能理解的

难点:

  • 一二三等奖最好要使用不同的算法
    • 而且最好是三二一逐步加强
    • 但这就要求三等奖不能太弱,否则会遭质疑;也不能太强,要给一等奖留有空间,不能过于复杂
  • 如何制造一个惊心动魄的抽奖体验
  • 如何通过随机性、可验证性来使人信服
  • 什么时候公布奖项的算法会收到好的效果

哈希科普

https://softwareengineering.stackexchange.com/a/145633

Hash           Lowercase      Random UUID  Numbers
=============  =============  ===========  ==============
Murmur            145 ns      259 ns          92 ns
                    6 collis    5 collis       0 collis
FNV-1a            152 ns      504 ns          86 ns
                    4 collis    4 collis       0 collis
FNV-1             184 ns      730 ns          92 ns
                    1 collis    5 collis       0 collis▪
DBJ2a             158 ns      443 ns          91 ns
                    5 collis    6 collis       0 collis▪▪▪
DJB2              156 ns      437 ns          93 ns
                    7 collis    6 collis       0 collis▪▪▪
SDBM              148 ns      484 ns          90 ns
                    4 collis    6 collis       0 collis**
SuperFastHash     164 ns      344 ns         118 ns
                   85 collis    4 collis   18742 collis
CRC32             250 ns      946 ns         130 ns
                    2 collis    0 collis       0 collis
LoseLose          338 ns        -             -
               215178 collis

需以例告知改变一点会造成巨大不同

(2020)Boy next door:cbltql!!
(2021)Boy next door:cbltql!!
...
(2119)Boy next door:cbltql!!

c367f7a9253530f65130dc6277b8e97941f68571
3571315f2cd8b9132eed8addd076112478a6c008
...
e172c55ffaab89b11e333f1203af1381adea3058

但是作为抽奖的算法,这样还不够,还需要一定的随机混乱度(见 Issue 1

随机源及身份源的选择

  • 弹幕内容
  • 弹幕发送时间(只能精确到分,否则又会引起争议)
  • 微信头像
  • 微信昵称
  • 晚会进程(抽奖环节开始时间)

UPDATE: hmac, Keyed-Hashing for Message Authentication?

投点的实现方式

在每个人的身份源后,有规律地添加其权重个数,分别求哈希,投入奖池。

关于去重

由于只对一个距离进行排名,所以肯定是使用排名高的那条哈希。

可以使用默默去除同一个人排名低的方式,也可以使用不同颜色标出,并系统增加人数。

各奖项算法的实现方式

不参加投点的奖

比如惊喜奖可以不投点。投了点还叫惊喜吗:smirk:

身份源

微信头像。绑定后不可更改。

随机源

开始抽奖前 666 条弹幕内容,可用\n连接。

当然,开始抽奖的时间的确有人为因素。 可由主持人先渲染弹幕内容对抽奖结果的影响,鼓励发送弹幕, 然后渲染即将开始抽奖,应背对大屏幕发出开始抽奖口令。

此时操作人员点开 PPT 里的超链接,网页向服务器发出请求,服务器做出响应,真正截止。 最好把这一点也说清楚。

呈现方式

  • 展现前 666 条弹幕内容,主持人说两句话,然后展现求好的哈希
  • 大屏幕滚动求每个人的哈希,并滚动显示哈希距离排名
    • 主持人可以提示同 da 学 lao 计算一下自己的哈希值
    • 由于是按人直接求,可以使用默默去重方式
  • 计算结束,开奖

UI 布局

+------+------------------+
|      |    求好的哈希     |
|  排  +------------------+
|  名  |                  |
|  区  | 一开始展示弹幕内容 |
|      |      计算区      |
|      | 然后展示头像和哈希 |
|      |                  |
+------+------------------+

三等奖

身份源

微信昵称加最后一条弹幕内容,可用连接

随机源

晚会开始到现在的所有弹幕内容,可用\n连接

投点的实现方式

晚会主题数字(比如举办时间),依次加一至投点数

呈现方式

想不出来了。。要不如上?:sob:

二等奖

身份源

开场到现在每人第中位数条弹幕的内容加姓名、微信昵称。

投点实现方式

加上该人总发弹幕数的 0, 1, ..., 点数倍

随机源

总人数 * 2 条弹幕内容

一等奖

身份源

姓名加弹幕内容,加时间

投点实现方式

从最后一条弹幕开始,往前取点数加一条。不足者轮回,每次轮回时间 +1min

随机源

令前之游戏第二名者(你是想赢游戏呢,还是左右命运:smirk:)报一个合理的数字,取该数字条弹幕内容加发送时间

... To be continued ...

About

用哈希抽奖,先胡个提案,如果可行就使用这个仓库

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published