引用位址
實際上位元幣的賬戶是用位址來表示，賬本上不顯示個人資訊，轉賬是把位元幣從乙個位址轉移到另乙個位址。
一次轉賬記錄
接下來問題就變為了 誰有權用某個位址進行付款。
位元幣的解決方案是，誰擁有某個位址的私鑰，誰就能用這個位址進行支付。（所以私鑰一定保管好，如果私鑰洩漏，位元幣就可能丟失）
位元幣位址和私鑰是乙個非對稱的關係，私鑰經過一系列運算（其中有兩次hash）之後，可以得到位址, 但是無法從位址反推得到私鑰。
hash(hash(fun(sdghsdninihdsgakihkgnakgaihnkhiskdgal))) -> 2a39cba2390fde
還是上面交易的例子：
這個時候問題就變為了，如何證明你擁有某個位址的私鑰（在不洩漏私鑰的情況下）。只有擁有位址2a39cba2390fde的私鑰才能進行支付。
對交易資訊進行簽名
實際在簽名之前，會先對交易資訊進行hash運算得到摘要資訊，然後對摘要資訊進行簽名。過程大概是這樣：
1.對交易進行hash， 得到乙個摘要資訊（hash值）
hash(』2.用私鑰對交易摘要進行簽名（付款方在安全的環境下進行，以避免私鑰洩密）, 用**表示大概是這樣。』) -> 8adb23cdea6
引數1為交易摘要在簽名運算之後，付款節點就開始在全網進行廣播：我支付了0.2btc到aac9cba239afcc,簽名資訊是3cdferdadgadg，你們來確認一下吧。引數2為私鑰
返回簽名資訊
sign(「8adb23cdea6」, 「j78sknjhidhliqdngalket」) -> 「3cdferdadgadg」
廣播過程實際上是發資訊到相連的其它節點，其它節點在驗證通過後再**到與之相連的節點，這樣的擴散過程。
廣播的資訊包含了交易原始資訊和簽名資訊
其它節點在收到廣播資訊之後，會驗證簽名資訊是不是付款方用私鑰對交易原始資訊簽名產生的，如果驗證通過說明確實是付款方本人發出的交易，說明交易有效，才會記錄到賬本中去。
（實際還會驗證付款賬號有沒有足夠的餘額，我們暫時忽略這點）
驗證過程實際是簽名過程的逆運算，用**表示大概過程是這樣的：
引數1為簽名資訊如果驗證輸出的資訊和原始交易資訊的hash一致，則驗證通過，記錄賬本，用**表示大概是這樣：引數2為付款方位址
返回交易摘要
verify(「3cdferdadgadg」, 「2a39cba2390fde」) -> 「8adb23cdea6」
if(verify(「3cdferdadgadg」, 「2a39cba2390fde」)補充說明== hash(『』)) :
# 寫入賬本
# 廣播
else:
# donothing
上面為了更好的理解，我對一些資訊進行了簡化。
位元幣系統使用了橢圓曲線簽名演算法，演算法的私鑰由32個位元組隨機數組成，通過私鑰可以計算出公鑰，公鑰經過一串行雜湊演算法和編碼演算法得到位元幣位址，位址也可以理解為公鑰的摘要。
位元幣所有權及隱私問題 非對稱加密應用
我們先來回顧下現實的銀行系統 首先我們需要把我們的個人資訊 如身份證 給銀行，銀行給我們開立相對應的賬戶，銀行在開戶的時候確立了對賬戶的所有權。進行支付的時候，銀行對交易雙方完成轉賬 銀行在開戶的時候已經知道我們對應的賬戶 同時銀行會對賬戶資訊進行保密 這點其實不能保證 那麼位元幣如何在沒有第三方銀...
賬戶所有權問題
誰能用 2a38cba2390fde 位址支付，誰就擁有這個賬戶的所有權 私鑰 sdhgkdnhgggsdjuufjlkkhsuhfggdngbf hash hash fun sdhgkdnhgggsdjuufjlkkhsuhfggdngbf 2a38cba2390fde 位元幣中乙個位址對應乙個私...
關於UGC的資料隱私和所有權
ug程式設計客棧c user generated content 所謂使用者產生內容，這也是很多網際網路巨頭成功的基礎。這不算熱點新聞了，大概幾周前的一則新聞，很有趣，在國內這個事情談論的人不多，今天才想起來，其程式設計客棧實值得分享一下。美國一家初創企業，叫做hiq labs，是一家從事獵頭相關的...