快讯:
美国商品期货交易委员会(CFTC)委员Brian Quintenz周一在GITEX技术周会议上的演讲中探索了如何最好地将加密货币,特别是智能合约纳入CFTC的监管框架。他问道,当一份智能合约违反CFTC的规定时,谁应该承担责任?他认为,如果去中心化应用(dapp)出现非法活动,那么这些dapp的个体智能合约开发人员应该被起诉——只要CFTC可以证明,开发人员可以“合理预见,当时他们创建的合约代码时,使用它的美国人会违反CFTC的规定。”
以色列区块链协会已经发布了最新的以色列区块链初创公司数量,目前已超过200家。大多数以色列区块链初创公司都集中在Fintech(57家公司)和Protocols / Core Infrastructure(37家公司)领域。不过自今年年初以来,已有20家区块链创业公司停止运营。
美国政府执法辩护律师Jake Chervinsky发推特称,Coinbase上线ZRX的决定意味着相信代币不是证券。出售未注册证券的后果可能非常严重。如果没有充分的理由认为ZRX不受证券监管机构和民事诉讼的影响,Coinbase是不会冒这样的风险。并在随后的推文中补充到,Coinbase的立场是值得注意的, 但它并不能为ZRX、XRP或任何其他代币解决任何问题。
美国商品期货交易委员会(CFTC)委员Brian Quintenz周一在GITEX技术周会议上的演讲中探索了如何最好地将加密货币,特别是智能合约纳入CFTC的监管框架。他问道,当一份智能合约违反CFTC的规定时,谁应该承担责任?他认为,如果去中心化应用(dapp)出现非法活动,那么这些dapp的个体智能合约开发人员应该被起诉——只要CFTC可以证明,开发人员可以“合理预见,当时他们创建的合约代码时,使用它的美国人会违反CFTC的规定。”
以色列区块链协会已经发布了最新的以色列区块链初创公司数量,目前已超过200家。大多数以色列区块链初创公司都集中在Fintech(57家公司)和Protocols / Core Infrastructure(37家公司)领域。不过自今年年初以来,已有20家区块链创业公司停止运营。
美国政府执法辩护律师Jake Chervinsky发推特称,Coinbase上线ZRX的决定意味着相信代币不是证券。出售未注册证券的后果可能非常严重。如果没有充分的理由认为ZRX不受证券监管机构和民事诉讼的影响,Coinbase是不会冒这样的风险。并在随后的推文中补充到,Coinbase的立场是值得注意的, 但它并不能为ZRX、XRP或任何其他代币解决任何问题。
美国商品期货交易委员会(CFTC)委员Brian Quintenz周一在GITEX技术周会议上的演讲中探索了如何最好地将加密货币,特别是智能合约纳入CFTC的监管框架。他问道,当一份智能合约违反CFTC的规定时,谁应该承担责任?他认为,如果去中心化应用(dapp)出现非法活动,那么这些dapp的个体智能合约开发人员应该被起诉——只要CFTC可以证明,开发人员可以“合理预见,当时他们创建的合约代码时,使用它的美国人会违反CFTC的规定。”
以色列区块链协会已经发布了最新的以色列区块链初创公司数量,目前已超过200家。大多数以色列区块链初创公司都集中在Fintech(57家公司)和Protocols / Core Infrastructure(37家公司)领域。不过自今年年初以来,已有20家区块链创业公司停止运营。
美国政府执法辩护律师Jake Chervinsky发推特称,Coinbase上线ZRX的决定意味着相信代币不是证券。出售未注册证券的后果可能非常严重。如果没有充分的理由认为ZRX不受证券监管机构和民事诉讼的影响,Coinbase是不会冒这样的风险。并在随后的推文中补充到,Coinbase的立场是值得注意的, 但它并不能为ZRX、XRP或任何其他代币解决任何问题。

比特币钱包GreenAddress:隔离见证的部署并不复杂

隔夜的粥 2016-01-27 11:21 发布在 比特币 10413

lawrence-nahum-bitcoin-wallet-greenaddress-already-integrating-segregated-witness

比特币区块扩容之争最近成为了关注的焦点,其中最受关注的发展便是隔离见证方案( Segregated Witness),其公共测试网络(testnet)已于上周时候推出。这一创新是由Blockstream联合创始人Pieter Wuille博士提出的,它也被设为了Bitcoin Core发展路线图的核心。

然而,依托于隔离见证的扩容方式,最近遭到了Bitcoin Classic一方的反对。相比于一个隔离见证软分叉,Bitcoin Classic所选择的是部署一次“干净”的硬分叉,将比特币区块大小扩容至2MB。

关于隔离见证的问题,莱比特矿池创始人江卓尔在最近的《支持2MB,反对低于90%算力共识的分叉》一文中提到:

“Core开发试图用隔离见证(segwit)来间接达成扩容效果,但这存在很大问题和安全隐患。

首先,隔离见证在单签名交易100%使用的情况下,最多也只能达到1.6MB的扩容效果,隔离见证的复杂性和巨大开发工作量,使得其他应用难以及时更新,甚至不愿更新。假设有50%交易使用,那相当于在6-12个月之后才达到1.3MB的扩容效果,这并没有什么意义。

第二,隔离见证对比特币底层逻辑进行了大量改动,开发工作量巨大且危险程度高,在社区扩容的压力下,Core开发必然存在赶工情况,比特大陆 CEO 吴忌寒在昨天聚会上也证实了“Core开发存在每天工作十几小时赶工的情况”。比特币用户不少人都是技术出身,各位都很清楚赶工出来的代码是什么质量。”

Bitcoin Magazine则采访了GreenAddress钱包的开发者Lawrence Nahum,目前他正在将隔离见证方案实施到GreenAddress钱包当中。
“GreenAddress已经在隔离见证测试网上实现了一些基本支持工作,” Nahum说,“我们开始这个实验,是因为我们认为隔离见证是一个伟大的推动者,它修复了无意识的可塑性问题,从而让无需受信的智能合约成为可能,能让广泛使用多重签名的用户享受到更低的费用,这真是令人兴奋的。”
关于隔离见证遭到的批评,Nahum表示:
“隔离见证测试网络的支持工作是比较容易建立的,阅读其技术细节只花了我几个小时,部署工作则需要花费一天的时间。这包括钱包端在用户设备上的运行,以及服务器端的运行。前者是基于我们所使用的钱包库 bitcoinjs,后者我们写了另一个库( library)PyCoin。这不是什么大问题。”

软分叉 vs 硬分叉

Bitcoin Core和Bitcoin Classic之间所选择的扩容方式,其最大的差别就是,前者选择通过隔离见证的软分叉扩容方案,根据Bitcoin Core开发者的说明,隔离见证仅需矿工提供支持就可以实现,Core开发者认为这样的方案是更安全的方案。然而,Bitcoin Classic开发团队则认为,硬分叉的风险被夸大了,这种最简单的方案才是更可取的。

对此,Nahum选择了前者。

“隔离见证的改动并没有太多的工作,相比于一个有争议的硬分叉而言,它是无脑的,”他说,“这真的是一个双赢的局面。而硬分叉会有巨大的风险,尤其是在时间紧迫的情况下。Bitcoin Classic似乎并没有技术竞争优势,更多的是一种政治。这感觉就像是一个不同的,更核心化的管理模式。在我看来,这让我感到不舒服。”
他还补充说:“作为一名企业家,一名投资者,一名开发者,比特币这项技术的支持者,我想要的是长期的稳定性和共识,而不是短期或下意识的反应。这个行业的未来依赖于创新,只有拥有冷静的头脑和长远的眼光,我们才能看到成功的未来。”

你怎么看?

原文:https://bitcoinmagazine.com/articles/lawrence-nahum-bitcoin-wallet-greenaddress-already-integrating-segregated-witness-1453824522 作者:Aaron van Wirdum 编译:隔夜的粥 稿源(译):巴比特资讯( http://www.8btc.com/greenaddress-s…egated-witness )

评论(7)
登录 账号发表你的看法,还没有账号?立即免费 注册
  • 巴比特资讯 2016-01-27
    【比特币钱包GreenAddress:隔离见证的部署并不复杂】依托于隔离见证的扩容方式,最近遭到了Bitcoin Classic一方的反对。相比于一个隔离见证软分叉,Bitcoin Classic所选择的是部署一次“干净”的硬分叉,将比特币区块大小扩容至2MB。对此,GreenAddress的开发者是怎么看的呢?http://t.cn/Rbmevsl
  • bitcoinfans 2016-01-27
    隔离见证真的在赶工么?
  • 狗狗币之神 2016-01-27
    那些说麻烦的,真的测试过了么[疑问]
  • 曲振刚 2016-01-27
    隔离验证编程 指南(作者:danielsocials) 有2种实现隔离验证的方式: 原生的隔离验证脚本 原生的隔离验证脚本定义为一个scriptPubKey,格式为1字节的push指令(OP_0, OP_1, ..., OP_16)后面跟着2到32字节数据. 嵌套在P2SH中 隔离验证脚本嵌套在P2SH中是用一个redeemScript存放隔离验证脚本,也是一个scriptPubKey,格式为1字节的push指令(OP_0, OP_1, ..., OP_16)后面跟着2到32字节数据. 交易序列化 如果一个交易不包含隔离验证数据,那么序列化格式使用以前的格式. 如果一个交易包含隔离验证数据,一个新的序列化格式必须被使用: [nVersion][marker][flag][txins][txouts][witness][nLockTime] 这几个字段包括nVersion, txins, txouts, and nLockTime 和以前的定义是一致的. marker 字段必须是 0x00. flag 必须是1字节的非0值. 当前必须是0x01. witness 是一个交易的所有有witness数据的序列化.每个txin关联到一个witness字段.witness字段以var_int开始,var_int的值表示txin需要占用栈的数量,紧跟着栈的成员值,每个栈成员都以var_int开头.witness数据不是脚本也没有520字节的压栈限制. 一个非witness的txin必须关联一个空的witness字段,表示为0x00.如果所有的txin都没有witness程序,那么交易必须使用旧的格式序列化(例外:coinbase交易). Transaction ID 交易ID 每个交易有2个ID txid含义没有改变,还是交易序列化数据的2次SHA256哈希运算值 一个新的 wtxid 定义为: 包含新的witness数据的序列化数据的2次SHA256哈希运算值. 如果一个交易没有任何witness数据, 那么 wtxid 等于 txid. txid仍然表示交易的id,特别是也用来在txin中指向前一个交易的输出。 Standard script types 标准脚本类型 Pay-to-Public-Key-Hash (P2PKH) P2PKH是最常用的模板 scriptPubKey 被中本聪定义,允许简单的支付给一个单一的公钥.格式为: scriptPubKey (25 bytes): OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG 花费P2PKH的输出,scriptSig格式为 scriptSig: RIPEMD160(SHA256(pubkey)) 等于scriptPubKey 中的 20-byte-pubkey-hash. Pay-to-Script-Hash (P2SH) P2SH定义在BIP16.它允许付款到任意复杂的脚本用一个修改长度的scriptPubKey. 格式为: scriptPubKey (23 bytes): OP_HASH160 OP_EQUAL 花费P2SH的输出,scriptSig格式为 scriptSig: RIPEMD160(SHA256(redeemScript)) 等于在scriptPubKey中的 20-byte-script-hash. redeemScript是反序列化并且当作剩下的数据在scriptSig中. Pay-to-Witness-Public-Key-Hash (P2WPKH) P2WPKH是BIP141新定义的. 类似P2PKH, 它允许简单支付到一个公钥, 格式为: scriptPubKey (22 bytes): OP_0 花费P2WPKH的输出,scriptSig必须是空的,并且witness为 witness: RIPEMD160(SHA256(pubkey)) 等于scriptPubKey 中的 20-byte-pubkey-hash. P2WPKH in P2SH (P2SH-P2WPKH) P2SH-P2WPKH 是一个使用P2WPKH 脚本作为 redeemScript 的 P2SH. P2SH-P2WPKH的 scriptPubKey 看起来和通常的P2SH是相同的: scriptPubKey (23 bytes): OP_HASH160 OP_EQUAL 花费P2SH-P2WPKH 的输出,scriptSig必须只包含一个 redeemScript, 并且witness 是和P2WPKH相同的: scriptSig (23 bytes): < OP_0 > witness: RIPEMD160(SHA256(pubkey)) 等于 20-byte-pubkey-hash, 并且RIPEMD160(0x0014{20-byte-pubkey-hash}) 等于 20-byte-script-hash. Pay-to-Witness-Script-Hash (P2WSH) P2SH-P2WPKH 是BIP141定义的另一个新的脚本格式, 类似P2SH. 它允许付款到任意复杂的脚本. 格式为: scriptPubKey (34 bytes): OP_0 花费P2WSH的输出,scriptSig必须是空的,并且witness为 witness: RIPEMD160(SHA256(witnessScript)) 等于scriptPubkey中的 32-byte-script-hash, witnessScript是反序列化并且当作剩下的数据在witness中. P2WSH in P2SH (P2SH-P2WSH) P2SH-P2WPKH 是使用一个P2WSH脚本作为P2SH的 redeemScript. P2SH-P2WPKH 的 scriptPubKey 看起来和P2SH是一样的: scriptPubKey (23 bytes): OP_HASH160 OP_EQUAL 花费P2SH-P2WPKH的输出, scriptSig必须只包含一个 redeemScript, 并且witness 是和P2WSH是相同的: scriptSig (35 bytes): < OP_0 > \ witness: SHA256(witnessScript) 等于 32-byte-script-hash, 并且 RIPEMD160(0x0020{32-byte-pubkey-hash}) 等于 20-byte-script-hash. 新的签名算法 花费一个witness程序的输出,当产生ECDSA签名时一个新的签名算法必须被使用, 一个详细的例子能在BIP143中找到. 新的支付地址 2个新的支付地址类型被定义了. 完整的规范可以在BIP142中找到.
  • 搬砖工91 2016-01-27
    看完同意"Classic是无脑的"这样一观点//@007龙少:
  • bluestar 2016-01-27
    这篇文章来的很及时
  • xzfkiller 2016-03-22
    支持有自己思考的人,不要简单认为扩容就是好方案,当然赶工是不好的.