Re: [情報] 「手遊虛擬轉蛋」糾紛多　綠委籲修法已回收

看板C_Chat作者 (桜花)時間6年前 (2017/07/18 16:12), 編輯推噓16(16推 0噓 135→)
留言151則, 7人參與, 最新討論串11/11 (看更多)
感覺再說下去會越來越與C洽無關，不過推文這麼多我再稍微延伸一下。 上一篇文的比喻雖然比較好懂(?)，但就像推文說的， 每次都要產生一對加解密用的金鑰而且用完就丟非常不經濟。 因此實際上遊戲有在用的密文驗證(不一定是轉蛋)是公鑰驗證。 流程差別如下 私鑰驗證： 加密：私鑰／解密：私鑰 加密→傳送密文→玩家選擇→傳送解密私鑰→玩家解密密文驗證 公鑰驗證： 加密：公鑰／解密：不需要，通常是無解 約定公鑰→加密→傳送密文→玩家選擇→傳送明文→玩家加密明文驗證密文＝明文＋公鑰 -- オーカの意味は……「繋げる者」 オークはリューン語で繋がりを意味している｡ その変形語がオーカだ｡ 桜花｡ 願わくば､ 人とリューンを繋げる者となるように｡ -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 140.92.30.205 ※ 文章網址: https://www.ptt.cc/bbs/C_Chat/M.1500365553.A.4EB.html
推
07/18 16:21, , 1F
推. 就密碼學的角度, 真的要做到機率公開是可以的.
07/18 16:21, 1F
→
07/18 16:21, , 2F
但不曉得是不是因為大人的因素, 或根本不被重視,
07/18 16:21, 2F
→
07/18 16:22, , 3F
一直沒有實現.
07/18 16:22, 3F
→
07/18 16:42, , 4F
不完全對 資訊安全的基本是你必須要相信某些東西才能繼續
07/18 16:42, 4F
→
07/18 16:42, , 5F
當伺服器不相信客端 玩家不相信遊戲商 這什麼加密都沒有用
07/18 16:42, 5F
→
07/18 16:43, , 6F
除非中間再引入公正第三方的驗證程序
07/18 16:43, 6F
→
07/18 16:44, , 7F
應該說，遊戲中一定會使用訊息加密，只是時機點和資料量差異
07/18 16:44, 7F
→
07/18 16:44, , 8F
有部分的系統就是拿來處理這種不信任的問題, 能夠
07/18 16:44, 8F
→
07/18 16:45, , 9F
很大程度地確保廠商無法作弊.
07/18 16:45, 9F
→
07/18 16:45, , 10F
但抽獎這牽扯到人性的部分，技術只需要保證"玩家無法手動更
07/18 16:45, 10F
→
07/18 16:46, , 11F
換資料內容"即可
07/18 16:46, 11F
→
07/18 16:47, , 12F
多做玩家不見得信任，也有的是"不願意信任"，更何況玩家中也
07/18 16:47, 12F
→
07/18 16:48, , 13F
存在非常態玩家，具抽獎或者競技類的遊戲在設計時多半是基於
07/18 16:48, 13F
→
07/18 16:48, , 14F
"任何玩家都有可能使用作弊工具"的前提去設計
07/18 16:48, 14F
→
07/18 16:49, , 15F
並不需要公正第三方.
07/18 16:49, 15F
→
07/18 16:49, , 16F
在適當加密之下, 手動更變資料內容是沒有意義的.
07/18 16:49, 16F
→
07/18 16:50, , 17F
與其說是"大人的理由"，不如說是營運、時程、開發等要素考量
07/18 16:50, 17F
→
07/18 16:50, , 18F
下，選擇在某些地方轉移處理成本以加快開發時程
07/18 16:50, 18F
推
07/18 16:52, , 19F
那就是不被重視的意思XD
07/18 16:52, 19F
→
07/18 16:53, , 20F
不，這個問題是雙方的，當你把系統設計成廠商無法作弊時
07/18 16:53, 20F
→
07/18 16:53, , 21F
應該說，在這個領域內受重視的部分和程度不會是在抽抽上
07/18 16:53, 21F
→
07/18 16:53, , 22F
幾乎同樣也就表示玩家有辦法偷看答案了(在只有2tier的狀況)
07/18 16:53, 22F
→
07/18 16:55, , 23F
這感覺就像是你跟籃球選手說曲棍球裝的護具能有效減少傷害
07/18 16:55, 23F
→
07/18 16:55, , 24F
你們籃球員怎麼不試試看
07/18 16:55, 24F
→
07/18 16:56, , 25F
通常就是被擺個黑人問號吧
07/18 16:56, 25F
推
07/18 16:57, , 26F
並不能偷看答案, 有個類似的概念是 zero knowledge
07/18 16:57, 26F
→
07/18 16:57, , 27F
proof, 或是找一下用密碼學猜拳, 猜拳基本上就跟
07/18 16:57, 27F
→
07/18 16:58, , 28F
轉蛋是一樣的, 雙方都不信任對方, 但還是能做到公平.
07/18 16:58, 28F
推
07/18 17:04, , 29F
所以關鍵是"非常难找到两个x, y 满足f(x) = f(y)"
07/18 17:04, 29F
→
07/18 17:04, , 30F
可以理解
07/18 17:04, 30F
→
07/18 17:06, , 31F
因為上一篇時就是在想準備多重密鑰來作弊成任意解
07/18 17:06, 31F
推
07/18 17:07, , 32F
沒錯, 所有公鑰系統的延伸幾乎都是建立在這種單向函數
07/18 17:07, 32F
→
07/18 17:08, , 33F
上面, 當然無法完全保證「不能作弊」, 但難度非常高.
07/18 17:08, 33F
→
07/18 17:21, , 34F
你前一篇看來是可行的。但大概只適用機率選項較少的情況
07/18 17:21, 34F
→
07/18 17:22, , 35F
比方最低是1%，須準備100個選項。當機率0.1%、0.01%時，
07/18 17:22, 35F
→
07/18 17:22, , 36F
選項會多到實務界面上設計困難，以及使用者感受不佳
07/18 17:22, 36F
→
07/18 17:26, , 37F
然後還有個問題是，玩家有辦法額外用程式去抓取比對加密
07/18 17:26, 37F
→
07/18 17:27, , 38F
情況，還是得相信官方的遊戲程式比對？
07/18 17:27, 38F
推
07/18 17:37, , 39F
其實這部分都不會有問題哦. 完全可以依照以前轉蛋的
07/18 17:37, 39F
還有 72 則推文
→
07/18 20:32, , 112F
沒公開又會有人來吵說會不會在這裡藏後門, 跟公開機率
07/18 20:32, 112F
→
07/18 20:32, , 113F
這個終極目標相違背.
07/18 20:32, 113F
推
07/18 20:33, , 114F
不是喔，我那段不是糾結在公鑰的問題，而是mikapauli到底是
07/18 20:33, 114F
→
07/18 20:34, , 115F
在說哪個部分，不同領域的某些慣用用詞總會造成誤差
07/18 20:34, 115F
→
07/18 20:34, , 116F
更後面的回文則是針對mikapauli強調open source這部分覺得很
07/18 20:34, 116F
→
07/18 20:34, , 117F
無厘頭
07/18 20:34, 117F
→
07/18 20:35, , 118F
^想問mikapauli
07/18 20:35, 118F
→
07/18 20:35, , 119F
我只是那句太長source打不下去只打了open而已XD
07/18 20:35, 119F
→
07/18 20:37, , 120F
這也是為啥我後面回文都在針對open source這點，在製作商業
07/18 20:37, 120F
推
07/18 20:37, , 121F
如果廠商願意採用這套系統, 那代表他們想要宣示
07/18 20:37, 121F
→
07/18 20:37, , 122F
導向的遊戲，提到遊戲本體open source是很詭異的概念(笑
07/18 20:37, 122F
→
07/18 20:38, , 123F
他們的機率是完全公正的, 在這個前提下, 把 client 端
07/18 20:38, 123F
→
07/18 20:38, , 124F
隨機抽取的部分公開是有利無弊
07/18 20:38, 124F
→
07/18 20:39, , 125F
不需要是本體, 可以做個接口連到這個小程式就好.
07/18 20:39, 125F
→
07/18 20:39, , 126F
我也是覺得不需要open source
07/18 20:39, 126F
→
07/18 20:39, , 127F
就做個100x100格子讓玩家點還更有趣(?
07/18 20:39, 127F
→
07/18 20:39, , 128F
只需要這個小程式結構是公開的, 遊戲本體你怎麼加密
07/18 20:39, 128F
→
07/18 20:40, , 129F
都不成問題.
07/18 20:40, 129F
推
07/18 20:40, , 130F
那不就還要證明玩家執行的遊戲本體跟open source出來的co
07/18 20:40, 130F
→
07/18 20:40, , 131F
de是同一套...
07/18 20:40, 131F
→
07/18 20:41, , 132F
不用, 玩家自己改也沒差.
07/18 20:41, 132F
→
07/18 20:41, , 133F
理論上就是你這個小程式怎麼改, 公正性都沒影響.
07/18 20:41, 133F
→
07/18 20:42, , 134F
就很像你不知道答案分布的情況下, 不管用什麼策略
07/18 20:42, 134F
→
07/18 20:42, , 135F
去回答選擇題, 答對機率都是一樣的.
07/18 20:42, 135F
→
07/18 20:44, , 136F
這個小程式就是讓電腦幫你選100x100的格子XD
07/18 20:44, 136F
→
07/18 20:44, , 137F
就我所知實體博弈機台的機率與CODE是會給第三方機構審查的
07/18 20:44, 137F
→
07/18 20:44, , 138F
這是要讓遊戲體驗不變的情形下需要的小程式, 當然
07/18 20:44, 138F
→
07/18 20:45, , 139F
如果像 mikapauli 說的想改遊戲體驗, 就是另一回事了
07/18 20:45, 139F
→
07/18 20:45, , 140F
sokayha你可以自己編譯然後替換調現有的bin
07/18 20:45, 140F
→
07/18 20:45, , 141F
這是因為機台不是你的電腦XD 你的電腦你可以自己掌控
07/18 20:45, 141F
→
07/18 20:45, , 142F
其實arthurduh1後面的概念與說法讓我釐清不少wwww，一開始混
07/18 20:45, 142F
→
07/18 20:46, , 143F
太多概念在一起讓我覺得"這根本是自己在想爽的吧"wwww
07/18 20:46, 143F
→
07/18 20:46, , 144F
概念有傳達到很高興 :)
07/18 20:46, 144F
→
07/18 20:47, , 145F
mikapauli混太多觀念
07/18 20:47, 145F
→
07/18 20:51, , 146F
題外話，七騎士某個常駐的SP抽抽執行介面就類似mikapauli提
07/18 20:51, 146F
→
07/18 20:52, , 147F
我一開始只是想用整盒食玩來比喻機率確證的可行性
07/18 20:52, 147F
→
07/18 20:52, , 148F
到的樣子，而地城戰旗應該也是符合
07/18 20:52, 148F
→
07/18 20:53, , 149F
提到實際上的運作感覺會偏離板旨XD
07/18 20:53, 149F
推
07/18 20:54, , 150F
這些介面就是我說的遊戲體驗, 隨機性的底層部分
07/18 20:54, 150F
→
07/18 20:54, , 151F
只要做好了, 你介面怎麼設計都沒關係
07/18 20:54, 151F
‣ 更多 mikapauli 的文章
文章代碼(AID): #1PRSBnJh (C_Chat)
討論串 (同標題文章)
完整討論串 (本文為第 11 之 11 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共11篇)
‣ 更多 mikapauli 的文章
文章代碼(AID): #1PRSBnJh (C_Chat)