zoukankan      html  css  js  c++  java
  • 比特币1个确认和6个确认的区别在哪里?什么是双花问题?

    比特币1个确认和6个确认的区别在哪里?什么是双花问题?

    一个问题:比特币或者ETH充提币的时候只有1个确认就给用户确认到账,可以申请提币有什么安全性问题吗?(网上默认的安全确认数是6和12,问了钱包的同事说只要有1个确认这笔交易就肯定到链上了,即使在分叉上也会最终合并进去的只是交易所往前扫链确认的时候可能扫不到,但币最终会到。但eth转账不是有很多种情况会导致最终失败吗?1个确认后确定不会再失败了?失败的话就连一个确认都没有吗?1个确认和6个确认的区别在哪里?)

    会不会导致币最终没充到交易所地址上?
    实际币没充成功,却给用户确认成功在数据库里增加币的数据可以交易或者提币了呢?

    区块链是可以往前追溯的,6个确认就说明连续6个区块都包含了这个交易ID,要攻击的话得在6个区块之前进行挖矿并成为主链。算力要大于6个区块才行。

    可以重新发送交易,不同节点同时发,就是双花问题

    比如这个区块链是10分钟确认一次,全网51%的算力每10分钟的成本是10万元。你卖的钻石价值100万元。那么你至少要10个确认以上才能交付钻石。最好是20个以上确认。
    总之,预防双花攻击,一个基本的原理就是,让攻击者赔钱的概率远远高于你被双花的概率。

    区块链应用也类似,整个区块链技术的核心就是保障账本的安全,记了账就不能被双花。但安全不是绝对的,即使记了账,仍然有可能被双花。因为,区块链应用不是依靠中央银行这样的机构的权威来保障账本安全的,而是依靠分布世界各地的节点都保存统一份的账本,并且由全世界的矿工用算力来竞争记账,产生完全一致的新账页的。

    当有人掌握了全网51%以上的算力时,就能够将刚刚记过的账页作废,把里面的一笔花费恢复成没被花掉的状态。这就是记账后的双花了,这种攻击方法叫“51%攻击”。这种双花相对于记账前的双花比较难实现,因为掌握51%算力需要很多钱。但如果双花的收益足够大,攻击仍然是有可能的。

    所谓双花问题,顾名思义,就是一笔钱被重复花了两次。比如,我们微信钱包里有100块钱,我们先去饭店吃了顿饭,结果微信出了bug,这一笔钱并没有被银行同步,还留在钱包里,于是我们又能拿着同样的100块钱去看场电影,这就属于双花问题。
    一般来说,双花问题分为两种情况:一种是记账前双花,比如同一笔钱,因为银行同步延迟的问题,被多次使用,像我们刚才举的例子就是这种情况;另一种是记账后的双花,一笔钱花出去,银行已经记账,但如果你攻击银行,从银行账本上删除了这笔花费,就可以再花一次了,即双花。

    怎么办呢?
    解决的办法是,等待更多确认。51%的算力要作废最新账页,其成功概率是51%,但作废连续两个新账页的概率就是51%*51%=26%,作废3个的概率是13.3%,作废6个的概率只有0.46%了。如果攻击者没有掌握51%的算力,只掌握20%的算力,那么攻击成功的概率就只有0.0064%了。

    这样,问题就简单了。商户可以根据交易金额的大小来决定如何防范双花。

    如果交易金额很小,比如卖支铅笔,完全可以接受零确认,对用户既省时又贴心。万一双花也不在乎。如果交易金额大一些,比如卖件衣服,那建议等待一个确认就可以了。不会有黑客为了你一套衣服动用51%的算力发起攻击的。如果交易金额很大,比如买钻石,那就要小心了。要根据全网算力的成本估算一下需要多少个确认,金额越大,需要的确认数就越多。

    确认数要做成用户可以根据情况配置的才合理

    交易所1个确认就到账我感觉还是有很大的风险的,个人钱包1个确认显示到账就无所谓,个人钱包没有到账是转不出去的。
    交易所提币不是从用户子钱包转账的,是交易所的热钱包转账给外部地址的。
    交易所确认后数据库记账完他就可以到币币交易里面交易了,可以申请提币了,可能把交易所热钱包里的币提走的。

    就要看交易所有没有做异常预警机制了
    结合实际情况,最好是可以让用户根据情况配置确认数

    你们说的这些我们都知道,这个要考虑实际应用场景
    omni一个充值,6个确认,赶上高峰期,两个小时到不了都很正常
    不要急着把事情想到最后的场景

    比如说多花问题,黑客充币到交易平台,他需要充值多少?什么样的条件才能让他有动力去碰着个51%
    碰了这个51%,交易所会不会发现,会不会让他走
    现在btc用1的原因就是大部分情况下满足业务要求,考虑总体性价比
    肯定是有地方的原因让我们做出了取舍

    让用户自己取舍配置交易确认数我觉得会更完美

    充币容易,提币难,不然要审核员干啥,当然有提示
    我之前的做法是,如果交易有变化,数据库做相应更新

    这只是理想状态下的情况,黑客有很多方法可以搞的,比如不用自己的账号提币,通过币币交易让很多其他账号买到币再去提币。或者提前在另外交易所做空某个币种,然后集中砸一个币让他暴跌等实现套利

     安全无小事,更多需要综合考虑问题才能找到最优解决方案。

  • 相关阅读:
    【转】memcached分布式部署
    【转】分布式与集群的区别
    [转]memcached+magent实现memcached集群
    [转]Memcache的原理和命中率的总结
    [转]PHP SOCKET编程
    [转]Hive安装及使用攻略
    [转]Linux的SOCKET编程详解
    Git介绍
    [转]wget 下载整个网站,或者特定目录
    [转]五种常见的 PHP 设计模式
  • 原文地址:https://www.cnblogs.com/zdz8207/p/qkl-btc-shuanghua.html
Copyright © 2011-2022 走看看