Protocol-Design
是否有關於在數字貨幣場景中使用盲目中介的嚴肅討論?
像Lucre ( OpenTransaction ) 這樣的數字貨幣系統通過鑄幣廠對雜湊函式的輸出進行盲簽名來創建硬幣,然後付款人將其解盲並與 has 函式的輸入配對。
這樣,硬幣本身就不能用來辨識付款人;但是,收款人和鑄幣廠可以通過諸如IP地址的旁道資訊自由地關聯他們關於付款人身份的資訊,並重建付款人的身份。這個問題有兩個正交的部分解決方案:
- 付款人可能會減少旁道資訊,例如通過使用 Tor,不給一方真實姓名等。這可能提供良好的安全性,但給付款人帶來很大的負擔。
- 相反,協議和付款人可能會堅持在收款人和鑄幣廠之間建立一個中介,即付款人使用其中介的日常公鑰對硬幣進行盲化,收款人使用鑄幣廠的密鑰對硬幣進行盲化,而中介在將硬幣傳遞給之前將其揭盲。薄荷。這可以防止鑄幣廠重新確定付款人持有該特定硬幣。
我可以想像#2 的一些用途,但我沒有看到太多關於它的討論。有趣嗎?
這可能是一個有趣的探索途徑。我已經閱讀了數字現金文獻的精彩片段,但我對它的了解還不夠,無法知道這些問題得到了怎樣的解決。
#2需要考慮的一些事項:
- 在快速閱讀 Lucre 時,收款人似乎在將硬幣傳遞到造幣廠之前沒有進行驗證。看來,如果鑄幣廠有一個已知的公鑰,那麼如果收款人可以在詢問鑄幣廠是否被雙花之前進行一些基本的驗證(它實際上是否已簽名?),那麼該過程可能會得到改進。您的解決方案 #2 會使任何收款人驗證變得困難,因為它使用的是盲值。
- 據我了解,收款人送出代幣進行驗證,但直到他們從鑄幣廠收到代幣有效的回復後才認為交易完成。因此,驗證必須是實時的。這會產生一個定時攻擊問題(與包括 Tor 在內的所有代理系統中都存在相同的基本問題),其中腐敗的收款人會及時發送硬幣 $ t_0 $ 腐敗的鑄幣廠在 $ t_0 + \Delta t $ . 如果 $ \Delta t $ 很小且視窗內發生的交易不多,造幣廠和收款人仍然可以通過中介追踪硬幣。特別是,如果這有助於攻擊,收款人可以在他們發送硬幣時進行調整。Tor 和混合網路文獻對此有應對措施。
- 如果有多個中間人並且使用者選擇他們信任的任何一個,那麼#2 攻擊將變得最糟糕。收款人知道盲幣被發送到哪個中介,而鑄幣廠知道它從哪個中介收到了硬幣,因此該資訊減少了給定硬幣可能來源的匿名集。它現在是每個中間人在一個小視窗內發送的一組硬幣,這更有可能是一個單組。也許有一種替代架構,使用者將硬幣發送給中介而不是收款人,但請注意下一個考慮因素。
- 由於鑄幣廠和收款人不再直接相互通信,因此它們無法相互驗證。造幣廠如何確定收款人是誰?鑄幣廠必須將金額記入收款人。似乎使用者必須簽署一項交易以將代幣記入收款人,並且只有使用者才能這樣做,因為這個已簽名的交易本身也必須是盲目的(與代幣一起)。在這種情況下,收款人似乎可以從協議的第一部分中刪除。使用者通過中介將硬幣和交易發送到鑄幣廠,鑄幣廠驗證一切,然後貸記收款人,然後鑄幣廠將已貸記的金額告知收款人,收款人將購買的商品發放給使用者。
無論如何,使用中介可能存在一些挑戰這一事實實際上使問題更有趣,而不是更有趣。它不再是一個簡單明了的解決方案;它需要一些思考,如果你能解決所有問題,它會做出更好的貢獻。