mirror of
https://github.com/seigler/dash-docs
synced 2025-07-27 09:46:12 +00:00
Further proof read
This commit is contained in:
parent
151a9b8b26
commit
704ed96890
1 changed files with 6 additions and 6 deletions
|
@ -36,13 +36,13 @@ breadcrumbs:
|
|||
|
||||
- **OP\_CHECKSEQUENCEVERIFY:** 让双向[支付通道][payment channel efficiency]可以无限期使用,提升效率达25倍。
|
||||
|
||||
- **VersionBits:** 允许1至29个软分叉同时实施,让系统升级的过程更快,更去中心化。
|
||||
- **VersionBits:** 允许1至29个软分叉同时实施,让系统升级的过程更快,更去中心化。
|
||||
|
||||
- **隔离见证:** 允许交易容量上升到1.75至4倍,解决第三方延展性让智能合约更安全,双向支付通道效率提升66%,提供欺诈证明让轻量节点也可以执行系统规则,更容易对脚本系统升级以允许更强大的合约功能。
|
||||
|
||||
- **IBLT及弱区块:** 只需要把[总带宽增加少许][increase in total bandwidth],就可以把区块传播所必须的带宽减低90%以上,让矿工可以以最短时间把区块传播出去,把[比特币广播网络][Bitcoin Relay Network]的好处带给所有全节点。IBLT及弱区块可以把全节点所需的带宽变得更平均,让将来可以更安全地增加区块容量。
|
||||
|
||||
## 我听过不同讲法,说隔离见证可以把区块增大至4MB,2MB,或1.75MB,那究竟是多少? {#segwit-size}
|
||||
## 隔离见证软分叉究竟相当于多少的区块大小增加?我听过不同讲法,如4MB、2MB、1.75MB。 {#segwit-size}
|
||||
|
||||
[现在的方案][current proposal]是以软分叉来实现隔离见证,并把每字节的见证内容算为0.25字节,因此最大的区块体积会是稍低于4MB。
|
||||
|
||||
|
@ -101,7 +101,7 @@ breadcrumbs:
|
|||
|
||||
- 隔离见证允许将来更容易以软分叉改变比特币的脚本语言,例如从签名提取公钥,或使用Schnorr联合签名算法,从而减少交易的平均大小。
|
||||
|
||||
- 实行隔离见证后,当无效区块出现时就可以产生很简洁的欺诈证明,这会进行简单交易验证 (SPV) 的轻量节点的安全性更接近全节点,可以让整个网络在较少的全节点下仍能运作。
|
||||
- 实行隔离见证后,当无效区块出现时就可以产生很简洁的欺诈证明,这会让进行简单交易验证 (SPV) 的轻量节点的安全性更接近全节点,可以让整个网络在较少的全节点下仍能运作。
|
||||
|
||||
这些技术的实际效果仍然未知,但实行一个具广泛共识的软分叉可让我们立即得益并且测试和评估中期的可能性,以及用这些数据作长期的规划。
|
||||
|
||||
|
@ -109,9 +109,9 @@ breadcrumbs:
|
|||
|
||||
现在支持 P2SH 的钱包可以分两阶段转移至完整的隔离见证:
|
||||
|
||||
- 第一阶段:脚本需要经过两次哈希运算,首先是变成256位字节,然后再变成160位字节。这个160位字节的哈希和现有的P2SH地址兼容,因此已升级的钱包和现有的钱包之间可以互相收付款项。
|
||||
- 第一阶段:脚本需要经过两次哈希运算,首先是变成256字节,然后再变成160字节。这个160字节的哈希和现有的P2SH地址兼容,因此已升级的钱包和现有的钱包之间可以互相收付款项。
|
||||
|
||||
- 第二阶段:脚本只需一次哈希运算变为256位字节。这格式和现有钱包不相容,但允许更有效率地使用区块空间,及提供更强的防碰撞攻击性能。
|
||||
- 第二阶段:脚本只需一次哈希运算变为256字节。这格式和现有钱包不相容,但允许更有效率地使用区块空间,及提供更强的防碰撞攻击性能。
|
||||
|
||||
## 如果没有人被逼升级,为何会有人升级?听说P2SH用了差不多两年时间才得到广泛应用。 {#why-upgrade}
|
||||
|
||||
|
@ -132,7 +132,7 @@ David Harding 提供了下表以[估计][estimated savings]在不同费用和交
|
|||
|
||||
## 听说你们会让零确认不能再用,这是路线图内哪一项技术? {#rbf}
|
||||
|
||||
是也不是。作为现在 Bitcoin Core 版本的默认设置,在收到一个未确认交易后,就不会再接受其它有相同输入的交易。有些人认为这表示他们首个见到的交易就是安全的,但其实不是;如果真的是这样,我们根本不需要区块链。
|
||||
这并不是路线图的一部分。作为现在 Bitcoin Core 版本的默认设置,在收到一个未确认交易后,就不会再接受其它有相同输入的交易。有些人认为这表示他们首个见到的交易就是安全的,但其实不是;如果真的是这样,我们根本不需要区块链。
|
||||
|
||||
在现时的默认设置下,人们并不能更新他们未确认的交易。在最初的 Bitcoin 版本,其实是有方法让使用者表明他希望交易可被更新,但为了防止拒绝服务攻击,中本聪在2010年关闭了这功能。
|
||||
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue