V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
V2EX  ›  acess  ›  全部回复第 45 页 / 共 113 页
回复总数  2242
1 ... 41  42  43  44  45  46  47  48  49  50 ... 113  
2020-02-18 13:12:11 +08:00
回复了 permaylau 创建的主题 Bitcoin 比特币钱包的历史地址是什么意思呢?
@brainzhang 这个 schildbach 钱包貌似没有助记词……
2020-02-14 17:55:33 +08:00
回复了 Livid 创建的主题 Android 关于 V2EX 提供的 Android Captive Portal Server 地址的更新
其实可以用 www . google . cn / generate_204
2020-01-27 20:09:37 +08:00
回复了 blueberryman 创建的主题 Bitcoin 比特币的双花攻击问题解决
@memorybox 还有,你在 11 楼说的第一种情况,说实话我没懂。在两个分叉的链一样长的情况下,也就是 n=0,这应该还是属于胶着状态啊,貌似还不能就此断定是谁赢了吧。
2020-01-27 19:41:48 +08:00
回复了 blueberryman 创建的主题 Bitcoin 比特币的双花攻击问题解决
@memorybox 即便不谈 SPV,只谈全节点(它具有独立完整验证区块链账本能力),在这方面也是有一定争议的。当年闹 2X 的时候,2X 那边的 btc1 全节点就改掉了“隶属于 Core 阵营”的几个默认种子节点,因为他们害怕这几个默认的种子节点在分叉发生后会起到类似于日蚀攻击的作用。
2020-01-27 19:36:40 +08:00
回复了 blueberryman 创建的主题 Bitcoin 比特币的双花攻击问题解决
@memorybox 我前面说了白皮书里的“硬盘空间回收”不可行,但我没说 SPV 不可行,我只是说 SPV 会盲目跟随多数算力。
实际上,有一个讽刺的事实,就是虽然“盲目跟随多数算力”看上去对安全性 /稳定性存在威胁,但是,如果 SPV 客户端能够联系得上多数算力、进而能够找到多数算力支持的链、并跟随这条链,这反倒还算是去中心化的体现——否则的话,SPV 可以说就是依赖了某种权威,这样很显然就不是去中心化了。
2020-01-27 19:21:49 +08:00
回复了 blueberryman 创建的主题 Bitcoin 比特币的双花攻击问题解决
@memorybox 有些大区块党貌似很抗拒“全节点拒收非法链”这个概念,不过,我也没说这里的“全节点”非得是用户手里的那种一点点算力都没有的全节点啊,至少矿池还是要跑全节点的对吧,那矿池也要面对一样的问题。
2020-01-27 19:16:08 +08:00
回复了 blueberryman 创建的主题 Bitcoin 比特币的双花攻击问题解决
@memorybox
BCH 分裂为 SV 和 ABC 那件事,我不太了解细节,不过我印象里,那不算是真正的算力战,双方仅仅是在投入更多算力来防守而已;只是很多观众眼中,根据“最长链规则”,是“谁长谁正宗”,所以看上去就像是一场恶战了。

PS:最长链规则,准确地讲应该是“积累挖矿工作量最大规则”而不是最长链规则,否则的话,任何人都可以利用早期的挖矿低难度来轻轻松松爆出超长的攻击链;只不过比特币是每 2015 个区块才调整一次难度,在同一个难度调整周期内,确实是“最长链规则”。

为什么我要这么说呢?因为我前面就说了,不管一个攻击者有多少算力、他的链有多长(积累了多少挖矿工作量),如果这条链违反了现有的规则,那全节点会直接把它拒收(忽视)掉。
所以,如果你要攻击对方,你的攻击链必须得符合对方的规则,这样对方才会被迫吃下你的炮弹,然后这颗炮弹才会爆炸、起到破坏作用——比如,通过双重支付来变相实现偷币,或者是通过拒绝打包任何正常交易来让这个币暂时停摆。

至于“一条链上不断积累的算力可以为这条链的权威性背书”,或者说“掌控算力足够大的一方随时都可以用 51%攻击掐死敌对的另一方”,这都是后话了。要说“权威性”,这是韭菜的主观判断;要说“随时都可以 51%攻击”,那又回到刚刚的结论了——如果你要攻击对方,你的攻击链必须得符合对方的规则。
2020-01-27 16:21:22 +08:00
回复了 blueberryman 创建的主题 Bitcoin 比特币的双花攻击问题解决
@memorybox 我 4 楼的意思其实是说,虽然现在的系统绕开了这个坑,但绕开这个坑也是付出了代价的:全节点只能从创世区块开始,完整下载一遍奔着 300GB 去的区块链账本。
然后,在 6 楼,我就从这个点展开说了一下比特币社区的分歧:大区块党认为,只要把“最终余额”的 hash 也写到区块里,就可以让新节点跳过历史,直接从最近的状态开始;小区块党就不这么认为,他们认为这个“最终余额的 hash”是不能像完整区块链那样自证清白的,这样做就是让矿工掌控了整个系统。
2020-01-27 16:01:44 +08:00
回复了 blueberryman 创建的主题 Bitcoin 比特币的双花攻击问题解决
@memorybox
这个问题本来就不影响现在的系统。这是一个早就已经被绕开的老坑。我也没有说这个问题会影响现有的系统,应该是我的表述让你产生了误解。

“把本来没花掉的币修剪掉”,这个不一定是无害啊,如果一个挖矿出块的全节点为了偷懒跳过了完整历史区块,只下载了这种恶意“断章取义”的修建版历史区块,那别人眼中完全正常的交易,在他眼里就变成“花掉不存在的币”的非法交易了,网络中就要产生不一致了。

至于“已经花掉的币”,它的交易本来就在 Merkle 树里啊。
2020-01-27 15:40:30 +08:00
回复了 blueberryman 创建的主题 Bitcoin 比特币的双花攻击问题解决
币圈外批评“trustless”的角度,大概有这么几个:
1.链上信息如果涉及现实世界,那就无法保证真伪。
2.软件出 bug 几乎无法避免,更不用说可能被插入后门。
3.说到后门的话,从操作系统到 CPU,到编译器,再到各种加密算法,甚至是币圈软件自身的“开源代码”本身,都无法保证绝对没有后门,我们都是信任着这些东西。

币圈内,大区块党,批评“trustless”,貌似就不这么说了,他们只是会强调“中本聪本来就是让矿工掌控比特币的,用户本来就是要信任矿工不作恶的”。
2020-01-27 15:35:55 +08:00
回复了 blueberryman 创建的主题 Bitcoin 比特币的双花攻击问题解决
@memorybox #12
再逐条回复一下:

“1. 验证 Merkle 树的合法性”

SPV 并不需要验证整棵 Merkle 树。

“2. 通过 Merkle Root 验证其所在 block header 的合法性”

反了,先验证 block header 是否合法,然后才能用这个 block header 里的 Merkle root 验证 Merkle proof,再用 Merkle proof 验证一笔交易是否进链、(再结合后面接了几个 block header 即可验证)有了几个确认。

“3. 轻节点通过其自带的 check point HASH 值,以及接收到的其他全节点广播的最近的 block header 验证此 block header 合法性”

理论上,checkpoint 并不是必要的。区块链最大的特色就是能“trustless”(无需信任),或者说,能“自证清白”。一个区块头里的各种信息,无论是前一个区块的 hash,还是是否满足挖矿难度,再有就是时间戳是否符合规则,都是可以独立完成验证的,一个节点或用户不需要询问任何人,自己就可以得出结论。
但是,你还是得能联系得上至少一个诚实的节点,如果你周围所有的节点都是恶意的,也就是日蚀攻击这种情况,那你就面临被蒙蔽 /欺骗 /攻击的风险。
2020-01-27 15:16:17 +08:00
回复了 blueberryman 创建的主题 Bitcoin 比特币的双花攻击问题解决
@memorybox #11 你还提到了“沉浸”在恶意节点中——据我所知,“日蚀攻击”( eclipse attack )就符合你说的这种情况。这一般只是被视为比特币协议的一个弱点(貌似还算是根本性的弱点),和是不是私有链 /中心化无关。

如果你还对我说的“Merkle 树裁剪不可行”有疑惑,那我再说一下:
按照通常的逻辑,“交易历史记录”和“最终余额”,这两个东西,是迥然不同的吧。
但是,中本聪的白皮书里,把“交易”直接定义成了“币”,然后又说“可以利用交易被编织成 Merkle 树这个特点来进行裁剪、回收硬盘空间”。按我的理解,他就是想“交易历史记录”和“最终余额”合为一体。但稍微想一想,就会发现这里有问题。
2020-01-27 15:07:36 +08:00
回复了 blueberryman 创建的主题 Bitcoin 比特币的双花攻击问题解决
@memorybox checkpoint,这个是开发者人为指定的,所以很显然是中心化的。
Bitcoin Core 的 checkpoint 基本上算是被弃用了,上一个检查点还是 2014 年的。
不过,checkpoint 有关的代码并不是完全没用了,一是可以对付低难度垃圾区块头 DoS 攻击,二是用来加速同步的 assumevalid,开发者说过,它和 checkpoint 共享同一套代码。
assumevalid 是指定一个区块 hash,在此之前的脚本(以及数字签名)验证全部都认定为有效,跳过检查验证。这大概就是为什么 Bitcoin Core 全节点在从头同步的时候,大部分时间都只让一个 CPU 核心满载,只有同步到最近的区块时,CPU 才开始满载。
虽然 assumevalid 也是开发者人为指定的,但是它并没有 checkpoint 那种“禁止回滚”的特性,assumevalid 是允许 51%攻击回滚的。而且,用户可以改配置参数来关掉这个功能。
2020-01-27 15:02:03 +08:00
回复了 blueberryman 创建的主题 Bitcoin 比特币的双花攻击问题解决
@memorybox 换一个角度来说,其实原来的 Merkle 树还是那个样子,一点没变,“裁剪”只不过是从中挑选一部分分支而已。
2020-01-27 15:00:25 +08:00
回复了 blueberryman 创建的主题 Bitcoin 比特币的双花攻击问题解决
@memorybox #11
Merkle 树的裁剪是把内容删掉,只留一个 hash。可以只摘掉一个叶子(也就是交易),也可以摘掉一个分支。这样当然不会影响 Merkle root。这是个 feature,不是 bug。
想想全节点发给 SPV 轻钱包的 Merkle proof,不就是把其他分支都摘掉了,只剩下直通这个叶子节点的一个分支么。
2020-01-27 12:04:53 +08:00
回复了 blueberryman 创建的主题 Bitcoin 比特币的双花攻击问题解决
@memorybox 科普算不上,只是心血来潮就打了很多字,把自己的理解尽量说出来,看看是不是有偏差。

维护代码,这个对我来说是个尴尬的问题,因为我并不算是开发者……


还有,我 4 楼提到 Merkle 树不能直接实现裁剪,和我 5 楼提到的欺诈证明,很显然不是一码事,结果好像有点被我混为一谈了。

在 Merkle 树的“剪枝”上做手脚,把已经被花掉的币剪掉,或者把没花掉的币加回去,这其实压根就没有修改原先区块的结构和内容,只是在呈现上做了手脚。如果有新的全节点要同步,那这种手段已经足够欺骗新的全节点了,这不需要任何挖矿算力。

欺诈证明,这个应该是对付已经写到链上的非法数据的。欺诈证明是“无罪推定”,首先假设一条链是合法的,给出有效证据才判为非法。
按照我的理解,如果只是在 Merkle 树的剪枝上做手脚,并没有修改链上的数据,所以还不算是欺诈证明覆盖的范围。只有恶意矿工开始在自己挖出的区块上花掉“已经被花掉的币”或是“从来都没存在过的币”(这两种其实都等于在凭空造币),才算是欺诈证明负责的范围。
2020-01-27 00:37:00 +08:00
回复了 blueberryman 创建的主题 Bitcoin 比特币的双花攻击问题解决
@memorybox @memorybox 我还是逐条杠一下吧。

1. 写入区块链的交易才被承认,双花交易只存在于内存池中,所有的双花交易只能有一笔进入区块链

“内存池”是每一个节点自己维护的,它存放的是待打包的交易。每个节点都有自己的内存池,并不存在一个全网统一的“内存池”概念。
你愿意打包什么数据进区块,完全是你的自由,谁也管不着。你愿意的话,打包进去一笔从 0.01 个币凭空变出 1 亿个币的非法交易都不是不可以。
如果有人尝试双花,那就会产生 N 笔互相抵触的交易(因为这些交易都花掉了同一个币)。
但是,**正常的节点不会允许自己的内存池里出现多笔互相抵触的交易**,只可能保留其中的一笔。
说完了内存池,那区块链呢?
只要有算力,任何人都可以完全可以去挖一条非法链来同时把这 N 笔互相抵触的交易都给打包进去,这样其实凭空造出了币。
如果你不愿意挖这种非法链,那你也可以去挖出多条分叉链,每一条分叉链本身都只打包这 N 笔交易中的一笔,每一条分叉链都完全符合规则。
不过,**正常的节点都是先独立地从头验证一条链是否合法**,中间但凡有发现任何违反规则的数据,都会将其标记为非法,**拒收**这条分叉链自此以后的所有区块;
**如果正常的节点看到了多条合法链,则会跟随其中最长的那条链(严格来说是积累工作量最大,而不是最长)**。

但凡是理性的矿工,也就是脑子里只想着赚钱的矿工,他只要考虑到“其他矿工也会按照规则验证我挖出的区块,非法区块会被拒收”,就不会把非法的交易打包进去;
他只要考虑到“最长链规则”,就只会在最长链的末端进行挖矿,把这条最长链延长;
无论是乱七八糟的分叉链,还是虽然长但是包含非法内容的链,理性的矿工都不会去跟随,因为跟随了,就是浪费自己的算力,让矿机白白烧掉电费而拿不到奖励。

可以看出来,每个节点都只是遵照一个规则来独立进行判断,而不是交给某一个“权威服务器”来进行处理和判断。所以才说,比特币是去中心化的。

2. 更改已经进入区块链的交易,只有发动 50%攻击

51%攻击,这个我在 3 楼说过了。
至于“更改已经进入区块链的交易”,我也在上面几楼说了一下比特币社区的分歧:
目前占主流的一派认为“比特币区块链具有无需信任(可以自证清白)的能力,即使是 50%以上的算力也仍然不能主宰比特币系统,为了达到这个目的,只能劳烦用户去跑笨重的全节点软件,别无他法——这也是我们不应该随便扩大区块容量的众多理由之一”;
相对少数的“大区块党”就不认同这一点,他们认为“按照中本聪的很多发言,矿工本来就主宰着比特币系统,所以区块容量和全节点之类的东西,让矿工们去管理就可以了,一般用户不需要操心去掺和;至于什么‘欺诈证明’都是很边缘的问题,不能拿来作为阻碍扩大区块的借口”。

3. 消费 coinbase 交易需要 100 block 的成熟期,现在不少裁剪节点是以 prune 方式运行的,一般设定 prune=4096,所以说,理论上区块链重组是有可能的,但是 100 个 block,4000 个 block 级别就变成近乎不可能的事情,一般情况下,6 个 block 确认就基本上确保一切; 历史上曾发生过最多 31 个 block 的重组事件,是在 2013 年 3 月份发生的,现在几乎不可能再有这种情况发生了;

coinbase 成熟度和区块修剪,这两个都是发生链重组时(也就是“回滚”,放弃一条分叉链,改为跟随另一条分叉链),可能带来连带损害的地方。就是为了防止出现连带损害,才要设置比较大、比较保守的限制。

coinbase 交易,就是矿工挖出新币+手续费奖励的特殊交易。如果过早允许矿工花掉这种“新挖出的币”,那很显然这些币还可以被接手的人再次花出去,这样就会产生一连串交易。如果发生了链重组,那源头的 coinbase 交易不能放到另一条链上,所以它后面的一大串交易也都会随之被判为非法、被丢弃掉,这很显然很糟糕,所以就需要尽量避免这种情况,就是为了这个才加了 100 个区块的确认的 coinbase 成熟度限制。

不过要注意,这个 100 区块确认的限制是写在全节点软件代码里的共识规则,谁都不能打破,否则就会被拒收。平时说的 6 确认就不是这样,6 确认只是一种典型的参考值,实际上在 0 确认的时候你就已经可以把收到的币发出去。一般说“请等待至少 6 个确认”,或者更多个确认,这个是**收款方为了保护自己而自愿选择去等**。对于交易所充值来说,也是如此,交易所也要保护自己,防止恶意用户利用双重支付来变相实现偷币。

区块修剪,这个很显然也是因为删掉了老区块数据就无法回滚到这个时间点之前,导致整个全节点软件都不能正常运作,所以目前就是至少也得保留 550MiB 的历史区块。
2020-01-26 20:15:02 +08:00
回复了 blueberryman 创建的主题 Bitcoin 比特币的双花攻击问题解决
这里也可以看出“历史区块不可避免地会越攒越大”是一个问题。我记得 Meni Rosenfeld 等很多人都认为这个问题可以用零知识证明来解决,不过我也不清楚具体是怎么解决的。我只知道 MimbleWimble 协议是安全地实现了裁剪。
2020-01-26 20:12:25 +08:00
回复了 blueberryman 创建的主题 Bitcoin 比特币的双花攻击问题解决
为什么说 UTXO commitment 存在争议呢?如果把最近时间点的 UTXO 集合算一个 hash,然后登记到链上,那不就可以跳过历史区块,直接从最近的时间点开始同步了么?而且检验 hash 就可以防止下载到假数据不是么?

争议点在于:这个“UTXO 集合的 hash”不具有“自证清白”的特性。
对于整条区块链数据来说,它是具有“自证清白”的特性的,因为每一个币是不是在比特币规则约束的范围内挖出来的,全节点都可以自己验证。
但是,你在链上看到“UTXO 集合的 hash”,怎么可以知道这个 hash 是不是恶意矿工伪造的呢?你只能是先验证过之前的交易数据,才能知道这个 UTXO 集合数据(以及它的 hash )对不对。

所以,就有开发者认为:如果大家都习惯了用 UTXO commitment 跳过历史区块,那比特币就丢失了“51%的算力也无法任意打破规则”这个良好的特性,变成了任由掌握了多数算力的矿工宰割的体系,这甚至可以说是丢失了去中心化。

大区块党一般都不认同这种观点,他们会强调“让矿工统治整个系统,这是中本聪本来的设计”……
1 ... 41  42  43  44  45  46  47  48  49  50 ... 113  
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   5858 人在线   最高记录 6679   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 28ms · UTC 02:47 · PVG 10:47 · LAX 18:47 · JFK 21:47
Developed with CodeLauncher
♥ Do have faith in what you're doing.