→ ts1993: 0.3%中獎 你要扯多少才能去抗議對方胡扯 07/18 13:04
針對這點解釋。機率確證可以用實體抽獎類比，其實這類說明也被提過幾次了。
我先給你1000盒封住(加密)的獎品，讓你自己從中挑一盒。
當你決定好之後，再讓你打開盒子(給你密鑰)看你抽到什麼。
你也可以把剩下999盒都打開，確定1000盒裡真的有3盒大獎，沒抽到的話是自己手氣差。
從程式的觀點來看，因為伺服器只是提供加密資訊、接收選擇、提供密鑰，
包括抽選在內的部分都是在客戶端進行，因此隨時可以驗證機率正確與否。
當然現在遊戲有沒有實作這類模式那是另一回事了。

就程式設計的角度而言，我會跟你說這樣就非常好破解...

實作上client只負責表演，獎項都是server提供的

如果抽選是在客戶端進行的話你就會發現各種破解外掛了

電腦能動手腳的部分太多了，搞這麼麻煩也會有人不信

目前加密算沒辦法破解吧，不然勒索病毒賺什麼

和遊戲內容與營收相關的隨機參數放在client端是很不智的

尤其是誰跟你說每個箱機率相等的

我不用破加密 我改內容就好

如果是PC上還行，手機上的話還要考慮運算效能的影響

都是在server端算啦 不適合在client

橘子就玩過這個了，四個箱子讓你抽，開完一箱之後亮出

那可以選後系統才產生密鑰給你

其他三箱的內容，通常有一箱會是大獎，然後你可以付錢

那是程式的bug吧XD，當然多這些工對廠商也是徒增問題

嚴格說廠商可以給一個假的機率表，除非差距極大，不然玩

橘子那個說白了就是告訴你箱子會出甚麼而不是那個箱子有甚麼

在三箱裡面再抽兩次。

而且這邊還有另一個程式功力不夠又要增加防破解機制的遊戲

你花錢抽得瞬間就決定你抽到甚麼了 那個箱子只是給你玩的

挖太佛了吧，結果大獎永遠都在抽不到的最後一箱

其實隨機的部分還是伺服端在運作

要做到真的可被檢驗的公正，可能要第三方公正機構介入

沒錯，電腦的東西機率還是掌握在官方手上，完全沒辦法

紅心辣椒以前也有出過類似的活動 我就做過測試了

我隨便選一個 再去查配送名單 獎品早就出來了

mikapauli 所以你也導向抽取結果在server製作的部分了，那從

告訴你四箱，沒告訴你機率是四分之一

現在重點不在裝置負擔吧，只是描述一個能確證機率又不會被破解的方法而已

廠商真要搞，程式碼沒公開誰知道公式怎麼跑的？

所有的隨機都是在伺服器阿,隨機的資訊內容,隨機的加密

有心要騙你，抽獎這種東西就沒有所謂的確證

只有"選擇"這個人為隨機在客戶端

這個方法也可以在server端做驗證，"實作"的問題就是這個方法"最佳選擇"是放在server端

樂透這種至少會在開獎機器實物上公開跟規格認證真要真的公正公開，我能想到的只有第三方介入

加解密你可以自己寫程式攔截封包做阿,不用client的code當然這個封包不能再加密就是

http://i.imgur.com/yFxXUe9.jpg要確保機率沒騙人這種機制最好哦

你把選擇放在server消費者就不能隨時驗證了阿

池裡共100樣固定物 抽一次剩99樣 抽100次必定全池的東西都拿到

你這種就像轉蛋機，只有保底而已

廠商也可以SSR是到80抽後才能抽的到也說不定

sokayha大的例子是只有在只需一張就能用的卡上才合適，如

果要兩張以上，那即使第一次就抽到了，但還是要把卡持全抽光才能換下個卡池

若真得這樣做，卡池可以reset

s大那個我只要把機率拉到後面就好了，讓你第一次根本不

所以你果然不懂嘛...就說把運算端放在客戶端非常容易被破

前面提到每箱機率不相等，那也是自己的問題

最裡面XD 會怕這種那沒完了 我認輸

@tonyxfg 它有重置鍵 你抽到目標物可以重置再抽新的100樣

要避免被修改，重要資料、計算得伺服端處理。但這樣對客

擺server消費者不信 放client會被修改

那就算程式bug了阿，你伺服器自己不記得自己發送過什麼

戶端就是一種黑箱。理論上要公正得伺服端公開，但就算法

mikapauli 那你知道只要攻擊中間負責加密的部分的機器就很容

律明寫要公開，要鑽的廠商也會公開假的。那麼就得保證公

你提出的概念是"可以考慮實現"的，但不是"各方考慮下實作的

像樂透就是透過律師跟物理性質，把機率獨立於廠商之外

伺服端加密，客戶端解密，你是指那部分被攻擊?當然沒人會去實作阿，這種對廠商幾乎沒幫助的事情XD

"加解密你可以自己寫程式攔截封包做阿,不用client的code"

回傳結果到伺服器端的時候改吧 實作上

你知道你這段就是在說"由server處理抽取參數"嗎?

前面提到修改內容的，伺服器其實不需要你告訴他抽到什

結果你自己也提到沒人會這樣實作，那大家也是討論心酸了wwww

伺服端可以一次產生N組密鑰，再看你選擇給你解到較差獎品的密鑰吧？

麼，他只要知道你的選擇。把加密訊息和密鑰給你只是讓驗證而已

加密方式我自己寫，給你抽一百個鑰匙開一扇門都可以

騙倫，抽獎機率放在伺服器上比較多，很少放在客戶端。

linzero你這樣已經算是破解加密方法了(根據任意明文和

我加密100組金鑰，最爛的都是第1組，然後玩家開啟必定開第一也不用啥破解，server送上來的都幫你排好了，client也幫你選只會先開第一個

密文產生對應金鑰)。使用錯誤金鑰解密只會得到一堆亂碼

那100組今要的產品真的是用自然機率算出來的，但我排序是人為的，打包再一起送出去，很容易就達成linzero說的情況client和server金鑰肯定是match的，但我在加密前就排好了所以client就是接收到由自然機率產生但排序人為的獎勵

所以才說就算client沒open source，相關封包也要能讓人

不太理解 這篇原po說的方法 不是避不掉標準的老千手法嗎 說給1000組讓玩家選 但玩家怎麼確認他選之前和選的當下內容沒被調換？ 選的是ssr那組但翻牌時給你r

讀取。不然通通加密起來對消費者一樣都是黑箱

你這論點就是其他人的結論啊，拿個新概念討論半天結果繞回來

抽選甚麼地都塞在client的有個例子 初版麥當勞app

sokayha所以才要把所有獎項在你做出選擇前都給你讓你能驗證

server只判斷你今天有沒有抽過 不過這資料也攔的下來

這是很常見的密文驗證阿，當然不是我想的XD

總之如果是不信任官方的話 除非有個第三方隨時可透明瀏覽數據 不然懷疑論是沒有彌平的可能的事前都給你讓你驗證 就不構成抽卡了？已經知道1000組的各自內容了啊？

全部內容是廠商聲明的，各自內容是事後驗證，只是先給你來保證不會更改

沒用啊 聲明的結果事後改掉就好啊 反正你也不知有沒改

各自內容都先給你了，只是先封起來，等你挑完才能看看了發現與聲明不合就是廠商有問題了

封起來你就不能保證莊家不會偷換底牌你事先也看不到聲明內容 怎麼知道聲明內容沒被改？

大概懂你的意思了。也就是同時提供明文跟密文，但順序沒

你這應該算linzero偷換解鑰的想法

抓到了 FEH轉蛋就是你寫的

聲明內容就是中獎率0.3%，要驗證的只有這個而已

五張 你選了第三張 然後這時全翻開五張是 sr sr r sr sr，我官方再宣稱一開始我就是給你sr sr r sr sr，你根本沒得確認官方有沒騙人一樣是80%中獎 你永遠不會中

linzero類似你的說法，只是其實是全部連在一起只有一組密文和密鑰，因為產生密鑰是最需要計算的地方

講正經的啦 那這個1000盒的內容要怎麼決定

沒有第三方公證抽前抽後 數據/解答/密鑰 沒更動 就沒搞頭

所有出現物的機率取最大整數倍數那一定是個很龐大的數字你又要怎麼去選一個至於寶箱被掉包之類 我只覺得叫警察去搬伺服器比較快

我覺得還是之前我po圖的那種保底手法相對可信 怕獎被放到最後的話 第一官方無法準確認知玩家目前最想要的是哪個第二玩家彼此之間的抽數對照就能統計出有沒有合理畢竟總抽數上限被固定在例如100，同一目標物的所需抽數在統計上應該常態分佈

玩家抽取數算是最站不住立場的證據(嘆，只要穿差幾個"特例"甚至於官方表明"這些玩家都只是剛好在偏差，我們數據中還有XXX玩家有在此機率之上，且分佈都與這些玩家不同(ry"就像原PO的密鑰想法，都有方法可以"製作"出有利於廠商的手法

以前可能是 現在抽抽實況那麼流行 太明顯做假會被抓到吧 記得之前猴女就是事例？玩家們抽數總和起來足夠大數是會有質疑力道的

猴女那次其實真正違反景品的是新角色的優良誤認只是玩家風像都只燒向猴女，而非優良誤認的角色變成營運方就順水推舟兩個打包一起解決而且猴女最後我記得是有抽到，但花了70萬日幣

是啦 但我意思是那是玩家用統計結果去質疑官方的事別XD

而且那時候GBF有內建公告別人抽獎的機制

加上有一次開機時被人發現營運商的帳號在測試抽抽池

Romulus的確有這個太長的資訊不適合頻繁傳輸的問題

但現在大部分轉蛋遊戲機率都是萬分之一的倍數，因此這問題還好

你這還有高負載load balance的問題啊(茶

大部份萬分之一 你這個誇張了XD cgss非當期0.022%，高了兩倍有餘！(x

如果萬分之一機率，那表示要給玩家的選項得達10000個？

"理念不錯，但欠缺實用"大概就是這樣的結論吧

這真的是這樣，頻繁的變換加密很操伺服器

load balance就轉出去給另一台server，還好吧

"技術"不是問題，"營運概念"才是問題，上頭就不給你多的機器玩家感受到的是甚麼? 就是你SERVER爛工程師偷懶啊QQ

畫面上出現10000個讓你點是不太實際就是了XD讓玩家用輸入數字的方式選也很沒fu

課長：我一次課幾百幾千個，你要我一個個選？

文組文

在client抽很容易炸，流程一不小心沒弄好就會被洗1. client一直重複抽抽到中才把資料送server2. client重複送中大獎的封包給server還有很多族繁不及備載不用改code就可以洗爆你的方法

送之前不會知道中獎與否, 樓上那是私鑰系統才有的問題也不太能說是私鑰系統, 應該說只要加入公鑰系統中單向函數的概念, 樓上這些顧慮都會不復存在