Author

Topic: Bitcoin 要能夠容納更大的交易量 (Read 1888 times)

full member
Activity: 198
Merit: 100
December 19, 2017, 04:52:21 AM
#21
比特币明显已经不可能再用于日常支付了, 当年几分钱手续费, 现在几百几千。 只能用于大额清算了。另外楼主数据是否有误, 支付宝和VISA明显不止“支付寶的 1000tps 及 VISA 的 4000tps”
member
Activity: 112
Merit: 10
December 18, 2017, 10:15:42 PM
#20
扩大容量就等于分叉了。这些老币刚出来的时候,没有那么多好技术,现在要改就困难了。
member
Activity: 153
Merit: 10
December 18, 2017, 03:53:11 AM
#19
http://www.8btc.com/blocksize-20-mb
LZ不用做这些重复的工作了,这里有很完整的翻译。还有讨论

这个链接好像更完整,谢谢分享。
如果早点发现这几个论坛,估计早就自由了。。。
newbie
Activity: 29
Merit: 0
December 18, 2017, 03:49:34 AM
#18
比特币确实需要扩容啊,不然现在速度太慢了
hero member
Activity: 810
Merit: 1000
Your professional profile on the blockchain
December 18, 2017, 01:41:06 AM
#17
遗憾的是至今也没有解决
newbie
Activity: 20
Merit: 0
http://www.8btc.com/blocksize-20-mb
LZ不用做这些重复的工作了,这里有很完整的翻译。还有讨论
legendary
Activity: 1193
Merit: 1001
Chinese translator
7tps处理能力缺陷, 51%风险, 可分叉性, 易被Hacked性 等,这些都是比特币的缺陷,最重要的是,这个圈充满骗子和不要脸的流氓。
legendary
Activity: 1792
Merit: 1111
以下文章翻譯自 http://gavinandresen.ninja/block-size-and-miner-fees-again . 為了令中文讀者及非技術人員能容易理解, 在不破壞原意下翻譯可能會有改動.

原作者: Gavin Andresen
中文翻譯: XBT.HK
版權: Public Domain 公有領域

-----------------------------------------------------

我經常看到這個要保留 1MB 區塊容量限制的論點:

Quote
保留 1MB 區塊容量限制會增加交易之間的競爭, 令礦工得到更多交易費, 因此令網絡更安全

為此我曾撰寫區塊容量的經濟學 https://blog.bitcoinfoundation.org/blocksize-economics/ 一文, 更邀請了真正的經濟學家評審. 但在此我會以另一角度討論.

礦工的 Bitcoin 收入可以表達為:

Code:
區塊獎勵 + (交易數量 x 平均交易費)

其中區塊獎勵由最初每區塊50BTC, 約每4年減半一次. 現在是每區塊25BTC, 於2016年中會下降為12.5BTC. 而平均交易費, 則是進行交易時用戶決定向礦工付出的交易費.

然而現在更多礦工關心的是以法幣 (不論是美元, 歐元, 或人民幣) 計算的收入, 所以應表達如下:

Code:
(區塊獎勵 + 交易數量 x 平均交易費) x 兌換率

如果隨著區塊獎勵下降, 而交易數量或平均交易費的增長又不足以彌補, 那恐怕礦工就會退出, 令網絡變得不安全, 也令攻擊網絡的成本下降.

但我們不應只著眼於平均交易費, 其實交易數量同樣重要. 如果我們的目標是要把方程中 (交易數量 x 平均交易費) 這部份最大化, 我們需要先知道交易的需求價格彈性, 才能計算出令礦工賺取最大收入的區塊容量上限.

而事實上在可見的將來, 兌換率是更重要的一項. 因此如果我們希望在未來10至15年保證網絡的安全, 就應集中做可以令兌換率上升的事情. 而增加區塊容量可以令更多人使用 Bitcoin, 容許更多更安全的多重簽名交易, 容納更多對區塊鏈的創新應用, 這些正是可以令 Bitcoin 的價格上升的因素.

----------------------------
以上文章同步發佈在 http://blog.xbt.hk/
hero member
Activity: 714
Merit: 500
我发现网上对块容量增大的最大质疑声音是来自矿工群体。不过也很正常,如果块容量比较紧张,大家可能就会尝试付出较多的矿工费来争取较快得到确认,受益的自然是矿工。当前比特币价格虽然不怎么大跌的,但也不死不活的,矿工也活得很累吧,现在提出加大块容量就很容易刺激他们脆弱的神经...
sr. member
Activity: 288
Merit: 250
计算机(手机)CPU、内存、硬盘等的发展,还是遵循摩尔定律的。

总是越来越快,越来越便宜! 20mb 区块的上限是小Case,处理根本不成问题。
坚决支持增加区块链的上限到20MB!

legendary
Activity: 1792
Merit: 1111
为什么改到20MB而不是一开始的32MB,有什么依据吗?

"我們有很多其它方法可以提升 Bitcoin 的交易量, 例如 Lightning Network / Sidechains / ChainDB / Treechains / Factom, 因此我們無需要上調區塊容量"
"如果我們今天可以增加區塊容量, 為什麼將來不會增加 Bitcoin 的總發行量?"

最关心这两个问题。既然有替代的办法为什么要做“改善”,今天改善下区块大小,明天改善下确认速度。。。这样合适吗?

20MB是 Gavin 經過測試後, 認為是一個安全的數值. 有機會我會再解釋.

而你關心的其它替代方案的問題, 我已翻譯了 Gavin 的答案
legendary
Activity: 1792
Merit: 1111
以下文章翻譯自 http://gavinandresen.ninja/it-must-be-done-but-is-not-a-panacea . 為了令中文讀者及非技術人員能容易理解, 在不破壞原意下翻譯可能會有改動.

原作者: Gavin Andresen
中文翻譯: XBT.HK
版權: Public Domain 公有領域
-------------------------------

以下有兩個反對提昇區塊容量的論點:

  • 我們有其它方法解決交易量的問題, 例如 Lightning Network / Sidechains / Impulse / Factom, 所以無需要提昇區塊容量
  • 如果我們提昇了區塊容量, 人們就不會再費神去發展其它解決方法

要回應第一點並不困難: 如果真的有一個解決方案, 已經過測試, 實際在網絡上運行, 而且已得到各種不同的錢包軟件支持, 那的確沒有逼切性要提昇區塊容量.

但不幸地, 現在並沒有一種方案可以做到以上的要求, 詳請可以參閱 Mike Hearn 的文章 (https://medium.com/@octskyward/the-capacity-cliff-586d1bf7715e). 再要經過多年的發展, 我們才有信心可以建立一個高交易量而低成本的即時微支付系統. 這不能解決眼前的交易量問題.

要回應第二點也不困難. 現時 Bitcoin 交易需時平均 10 分鐘才能得到確認, 因此難以達到即時交易, 微支付, 以及高頻交易等要求. 因此無論是否提昇區塊容量, 我們也絕對需要在 Bitcoin 區塊鏈以上建立第二層交易系統, 以提供更多元的支付服務.

提昇區塊容量是一個短期而可以快速實行的方案, 讓我們有更多時間繼續發展其它解決方案. 雖然並不理想, 但卻是必須的.

----------------------------
以上文章同步發佈在 http://blog.xbt.hk/
legendary
Activity: 1792
Merit: 1111
以下文章翻譯自 http://gavinandresen.ninja/why-increasing-the-max-block-size-is-urgent . 為了令中文讀者及非技術人員能容易理解, 在不破壞原意下翻譯可能會有改動.

原作者: Gavin Andresen
中文翻譯: XBT.HK
版權: Public Domain 公有領域

--------------------------------
在反對提昇區塊容量的意見中, 我最常聽到的也許就是 “區塊還沒有滿, 我們(還)不需要作任何改動".

事實上, 我們的確還沒有到達那個 1MB 的上限. 平均來說, 區塊空間現在只用了 30-40%. 但如果使用量接近 100% 時, 又會怎樣?

David Hudson 有一篇很好的文章 (http://hashingit.com/analysis/34-bitcoin-traffic-bulletin), 分析當區塊空間的使用量接近 100% 時會發生什麼事情,  如果要知道詳情你需要看他的原文. 基本上, 他指出人們進行交易的時間與礦工生產區塊的時間會有錯配的情況; 當 1MB 的區塊空間接近被填滿時, 這種錯配就會導致非常不良的後果.

人們進行 Bitcoin 交易的頻率, 基本上是穩定的. 雖然會有每天及每星期的周期性波動, 但在短期內應該是平穩的. 從現在算起 10 分鐘的交易數量, 應該和剛過去 10 分鐘的數量接近.

然而區塊的產生卻是一個隨機的泊松過程 (Poisson process), 意思就是我們雖然知道平均每 10 分鐘會有一個區塊, 卻是完全不知道下一個區塊在什麼時候出現: 可以是下一秒, 也可以是超過一小時. 因此會出現一小時內有大量區塊產生, 也會出現一小時內完全沒有區塊產生的情況. 而事實上這種情況並不罕見, 也是在預計之內.

當平穩的交易頻率遇上隨機的區塊頻率, 就會出現錯配. 這錯配意味著區塊不可能一直是 100% 被使用. 當礦工幸運地連續找到多個區塊, 積壓的交易就會被完全處理, 甚至會出現一些只有極少量交易的區塊.

但如果情況倒過來, 便會有很壞的後果. 當礦工不幸地長時間沒有找到區塊, 交易就會開始積壓成一個隊伍, 令所有 Bitcoin 全節點 (Full node, 也就是所有運行 Bitcoin Core 的電腦) 的記憶體用量持續上升. 有些全節點可能會把隊伍上部份未確認交易棄掉 (新版本的 Bitcoin Core 可能會這樣做), 令交易的確認便變得不可靠.

而當用戶的錢包發現自己的交易在幾個新區塊出現後都不被確認, 就會嘗試重新發出交易 (這是 Bitcoin Core 錢包的預設功能). 當大量交易被積壓, 就會令所有錢包在短時間內重發交易, 令網絡帶寬的壓力突然大增.

如果積壓的交易數量上升到一個程度, 就會令整個網絡完全飽和, 但只是大家把交易不停重發, 而不是進行任何有用的工作. 其實我並不認為會發生這情況: 因為交易確認將會愈來愈不可靠, 結果人們會乾脆不再使用 Bitcoin.

------------------
以上文章同時刊登在 http://blog.xbt.hk/?p=232
hero member
Activity: 714
Merit: 500
我不是特别清楚目前比特币一个块的大小是固定1M还是上限是1M。
如果固定是1M,为什么不能采用弹性区块大小?
如果上限是1M,也就是说是采用弹性区块大小。那么为什么不将上限提高更多些?

是上限,因此每個塊可以包含的確認交易數量是受這個儲存上限所限制。每一個交易都有大小之分,一般礦工都喜歡盡量把更多的交易打包去將要挖出的塊,就是為了得到更多地礦工費。因此一個比較大的交易(byte數大)最好多付礦工費的原因就是它比一般交易佔用了更大塊容量。
sr. member
Activity: 322
Merit: 250
我不是特别清楚目前比特币一个块的大小是固定1M还是上限是1M。
如果固定是1M,为什么不能采用弹性区块大小?
如果上限是1M,也就是说是采用弹性区块大小。那么为什么不将上限提高更多些?
hero member
Activity: 714
Merit: 500
隨著on chain交易量上升,加大區塊大小是勢在必行,何必在此爭論原本就必須要做的事情。最多也就是討論加大多少而已…

關於區塊增大會導致比特幣會越來越中心化的憂慮其實是過度悲觀。隨著比特幣的普及,會有越來越多的商業機構介入比特幣業務,這些機構不可能運行輕量版的錢包吧,大部分肯定會是運行全節點。有這些商業機構存在,個人用戶全節點減少也不是什麼大問題。
hero member
Activity: 810
Merit: 1000
Your professional profile on the blockchain
为什么改到20MB而不是一开始的32MB,有什么依据吗?

"我們有很多其它方法可以提升 Bitcoin 的交易量, 例如 Lightning Network / Sidechains / ChainDB / Treechains / Factom, 因此我們無需要上調區塊容量"
"如果我們今天可以增加區塊容量, 為什麼將來不會增加 Bitcoin 的總發行量?"

最关心这两个问题。既然有替代的办法为什么要做“改善”,今天改善下区块大小,明天改善下确认速度。。。这样合适吗?
legendary
Activity: 1792
Merit: 1111
提高区块大小,肯定会使更多的人不愿意运行全节点,这也意味着去中心化程度会被削弱。这是肯定的。但是不提高区块链大小也是不现实的,因为如果需要比特币处理越来越多的交易,这是唯一可行的。

"更多"人不愿意运行全节点是肯定的, 但這個"更多"究竟是多少? 引用經濟學的概念, 這涉及"彈性"的問題, 不能說運行的成本高了一倍, 運行的人就只餘一半. 20MB是否比1MB"難受"20倍? 我看未必. Gavin也有解答這個問題, 我需要點時間翻譯
sr. member
Activity: 322
Merit: 250
提高区块大小,肯定会使更多的人不愿意运行全节点,这也意味着去中心化程度会被削弱。这是肯定的。但是不提高区块链大小也是不现实的,因为如果需要比特币处理越来越多的交易,这是唯一可行的。
legendary
Activity: 1792
Merit: 1111
以下文章翻譯自 http://gavinandresen.ninja/time-to-roll-out-bigger-blocks . 為了令中文讀者及非技術人員能容易理解, 在不破壞原意下翻譯可能會有改動.

背景資料: Bitcoin 要能夠容納更大的交易量 http://blog.xbt.hk/?p=224
原作者: Gavin Andresen
中文翻譯: XBT.HK
版權: Public Domain 公有領域


在比特幣的標準客戶端軟件 Bitcoin Core 最新的 0.11 版本中, 我將會提出一個變動, 以容許礦工生產大於 1MB 的區塊, 以容納更多交易. 而這變動將會在一年以內生效.

為此我會撰寫一系列的文章, 以回應反對上調區塊容量的意見. 以下是我打算會回應的題目:

  • 現在每個區塊平均只有 0.4MB, 我們沒有需要現在就把 1MB 的區塊容量提升
  • 我們有很多其它方法可以提升 Bitcoin 的交易量, 例如 Lightning Network / Sidechains / ChainDB / Treechains / Factom, 因此我們無需要上調區塊容量
  • 使用 1MB 的區塊可以令系統更安全, 因為有限的交易數量會促進競爭, 令人們付出更多交易費用給礦工
  • 提昇區塊容量會帶來更多交易, 因此需要更多網絡帶寬, CPU 運算, 及資料儲存成本. 這會令一些人難以負擔, 結果系統會被操控在較少人手上, 導致中心化
  • 在人民被政府嚴密監控的地方, 交易量上升會令他們更難繼續秘密地運作 Bitcoin
  • 對於提升區塊容量, 我們沒有足夠測試 / 沒有對其經濟學影響充分地研究 / 沒有對其風險與利益作充分的評估
  • 任何放寬 Bitcoin 規則的"硬分叉"都會破壞人們對 Bitcoin 穩定性的信心. 如果我們今天可以增加區塊容量, 為什麼將來不會增加 Bitcoin 的總發行量?
  • 我同意增加區塊容量, 但為什麼不這樣做?

如果你認為我們不應在未來數年內上調區塊容量, 而以上的題目並不能準確反映你的意見, 請電郵至 [email protected] 告訴我. (按: 中文讀者可以在此反映意見, 我會把適當的意見轉達至 Gavin)

---------------------
以上文章在 http://blog.xbt.hk/ 同步刊登
legendary
Activity: 1792
Merit: 1111
當 Bitcoin 在 2009 最初出現時, 其每個 10 分鐘的區塊最高可以有 32MB 容量, 換算約為每秒 200 項交易 (200tps, transactions per second). 但不久以後, Bitcoin 的發明人 Satoshi Nakamoto 為了防止系統被攻擊, 把限制降為 1MB, 自此 Bitcoin 系統最多只能處理 7tps. 相比支付寶的 1000tps 及 VISA 的 4000tps, 可謂微不足道.

Satoshi 原來的計劃是當系統變得更成熟後, 就會把這個限制放寬, 但他並未有做到這一點就消失了.

Bitcoin 的規則改動可以分為 “硬分叉" 和 “軟分叉" 兩大類, 前者涉及放寬規則, 後者則是收緊規則. Satoshi 當初把限制收緊為 1MB, 因此是軟分叉. 但如果現在要提升, 那就是硬分叉. 軟分叉只要大部份礦工支持就足夠, 但硬分叉則除了礦工外, 還要得到大部份用戶和商戶支持方能成功. 由於於寬容量涉及技術及經濟風險, 有關的爭論已經困擾社群多年, 一直沒有平息, 事情也沒有進展, Bitcoin 的交易量卻愈來愈接近每 10 分鐘 1MB 的上限.

最近, 比特幣基金會的首席科學家 Gavin Andresen 提出要在不久將來擴展 Bitcoin 處理交易的能力. 為此他會撰寫一系列文章, 以解釋為何我們有必要這樣做, 也要對反對者的意見提出反駁. 因為硬分叉需要大部份礦工, 用戶和商戶支持, 而眾所周知中國人正控制著相量份量的挖礦算力及交易量, 因此本人和 Gavin 溝通後, 會把相關的文章翻譯為中文, 讓更多人明白為何我們必需要增加 Bitcoin 的交易容量.

---------------------
該系列文章會在 http://blog.xbt.hk/ 同步刊登, 該網站收錄了大量由本人原創的技術及評論文章.

本主題會由本人直接管理, 灌水回應會直接刪除.
Jump to: