比特幣:被放棄的那條 block chain 上面的交易該怎麼辦

一篇俄羅斯人分析比特幣寫的論文

https://dl.dropboxusercontent.com/u/3658181/PiotrPiasecki-BitcoinMasterThesis.pdf

個人最想了解的問題:出現分歧之後「被放棄的那條 block chain 上面的交易該怎麼辦」

這個問題還沒有解法

目前的答案應該是「被放棄的 block chain上面的交易被視為無效」

所以目前比特幣交易至少要等十分鐘之後才算完成(https://bitcoin.org/zh_TW/faq#why-do-i-have-to-wait-10-minutes)

也就是十分鐘之後交易才開始有被至少一個 Node 驗證

並且建議等待60分鐘,也就是產生了 6 個 block 之後才算保證安全

根據本論文紀錄 ,2012 年已知最長的被取消的區塊鍊長度為 4

 

有另一個資訊也非常有趣

論文第38頁

Reaching the current transaction volume of Visa (2000 transactions per second) would require a creation and propagation of 1.14GB Block each 10 minutes

也就是說如果要達到目前VISA的交易次數,每秒兩千次,每十分鐘生成的 block 會佔用1.14GB的空間,就網路傳輸來看,可以說跟本不可能達到比特幣設計初衷的將這個 block 散佈到所有 Node

The current implementation of the Bitcoin Protocol does not support such scalability. As a standard Transaction on average is at least 0.23kB in size and the maximum Block size is 1MB, the entire Block would be filled at most with 4348 Transactions. As each Block should be generated every 10 minutes, the Protocol can handle about 8 Transactions per second. The current peak usage of Bitcoin was about 14,000 Transactions in a day [124], averaging to about 0.16 Transactions per second

目前每一筆交易大約佔用 0.23KB 的空間,一個 block 大小為 1MB,平均一個 block 可以存放 4348 筆交易

並且每十分鐘才能產生一個 block ,也就是平均每秒可以處理至多 8 筆交易

目前平均一天有約 14,000 幣比特幣交易,平均每秒 0.16 筆

第44頁

Up to this date the longest Block Chain fork was 4 Blocks long

本篇論文撰寫的時候,最長的分歧也才4 個 block

也就是過去 40 分鐘內的交易失效了,我認為這時間並不短,而且交易失效非常嚴重

 

我是從http://bitcoin.stackexchange.com/a/4976/33824 這個連結發現這篇俄羅斯論文的

總結來說,目前針對 bitcoin 的缺陷能夠解決的辦法就是「等待」

「等待」一個 block 被算出來,或者更安全些,「等待」六個 block 被算出來

這個等待的時間遠遠長於一般日常的小額交易,例如你去超市買個咖啡交易只要三秒鐘,但等待要十分鐘

這個等待的時間遠遠短於跨國匯款的大額交易,例如你從台灣匯款到美國至少需要一天經過本地銀行+中轉行+收款行入帳,但是等待只要六十分鐘就算安全

又想到另一個問題,當初Satoshi Nakamoto 是怎麼想到 sha hash 開頭可能都是 0 ?能想到這點真是太天才了,一般常識認知 Hash 之後就是個亂數,沒想到竟然有機會找到開頭都是 0 ,這真的太神奇了!

 

2016/04/24更新

讀完了mastering-bitcoin中文版

整本沒有提出 fork chain 之後被放棄的鍊上面的交易該怎麼辦

http://zhibimo.com/read/wang-miao/mastering-bitcoin/mastering-bitcoin.pdf

Android build system flow

  1. source build/envsetup.sh
    1. unset LUNCH_MENU_CHOICES
    2. test -d device && find -L device -maxdepth 4 -name ‘vendorsetup.sh’ 2> /dev/null | sort
    3. test -d device && find -L device -maxdepth 4 -name ‘vendorsetup.sh’ 2> /dev/null | sort
    4. . vendorsetup.sh(which comes from 1.2, 1.3)
      1. add_lunch_combo
  2. lunch aosp_mips64-eng
    1. local product=$(echo -n $selection | sed -e “s/-.*$//"),減號前面的字串會作為product
    2. check_product $product

 

  1.  build/core/main.mk
    1. build/core/config.mk
      1. build/core/envsetup.mk
        1. build/core/product_config.mk
          1. all_product_configs := $(get-all-product-makefiles)
          2. current_product_makefile := device/google/xxxx/aosp_xxxx.mk
          3. TARGET_DEVICE := xxxx
          4. build/core/product.mk
            1. shell test -d device && find -L device -maxdepth 6 -name AndroidProducts.mk
    2.  build/core/definitions.mk
      1. -include $(TOPDIR)vendor/*/build/core/definitions.mk
    3. $(call stash-product-vars, __STASHED)
    4. shell build/tools/findleaves.py $(FIND_LEAVES_EXCLUDES) $(subdirs) Android.mk
    5. $(call assert-product-vars, __STASHED)
    6. build/core/Makefile