哪位同学可以帮忙加速一下我的 bitcoin 转账, 2 天过去了。用的是 bitcoin core 推荐的交易费。谢谢! - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
helloswiftinuk
V2EX    Bitcoin
  •  
  •   helloswiftinuk 2020-12-18 14:34:10 +08:00 1747 次点击
    这是一个创建于 1828 天前的主题,其中的信息可能已经有所发展或是发生改变。
    用的是 bitcoin core 钱包, 附带交易信息:

    状态: 0/未确认,在内存池中, 通过 2 个节点广播

    日期: 2020/12/16 09:32

    到: origional first bought 19ejq3TnLKZ2Rt5kkTUE3AGMyYFkRgtqyZ

    支出: -0.04846835 BTC

    交易费: -0.00003840 BTC

    净额: -0.04850675 BTC

    交易 ID: a859063cbc47ef513072d83aa82e3ad7b91f7c85fc28291fa2213d8527ebe6fe

    交易总大小: 192 bytes

    输出索引: 0
    22 条回复    2021-01-17 14:51:29 +08:00
    acess
        1
    acess  
       2020-12-18 16:56:43 +08:00
    区块空间是有限的,给你加速了,你插队了,别人就靠后了。

    矿池有卖加速器服务,让你能付费插队,比如 btc . com 、pushtx . com,但相对很贵。

    Bitcoin Core 钱包默认应该是启用 RBF 的,如果你这笔交易发出的时候就启用了 RBF,右键菜单里应该有追加手续费的选项。
    acess
        2
    acess  
       2020-12-18 16:58:00 +08:00
    RBF 也是插队,但是它全网公开竞价,一般会比加速器便宜一些。
    acess
        3
    acess  
       2020-12-18 17:00:18 +08:00
    老版本的 Bitcoin Core 也许还没有默认启用 RBF,不知道楼主用的哪个版本。

    还有,这笔交易好像没有广播出去?或者说是卡了太久了,被超时丢弃了?可以重新广播,也可以按照 bitcoin wiki 上 fee bumping 这个条目里的操作说明,双花掉这笔交易。
    memecoin
        4
    memecoin  
       2020-12-18 18:36:35 +08:00 via Android
    @acess
    重新建一次交易,把交易手续费提高即可,就是“双花”,但是最终只有一笔会打包,根本不需要找矿工加速。
    acess
        5
    acess  
       2020-12-18 18:43:59 +08:00
    @weitch RBF 就是这样的,而且可以在钱包里一键完成。不过 RBF 需要发出交易时启用,然后才能进行这种双花替换操作。
    helloswiftinuk
        6
    helloswiftinuk  
    OP
       2020-12-18 18:45:34 +08:00
    @weitch @acess 我尝试一下,现在显示的是仅仅有 2 个广播。我看 bitcoin core 界面推荐的是 6 个广播比较快速。谢谢
    helloswiftinuk
        7
    helloswiftinuk  
    OP
       2020-12-18 18:51:55 +08:00
    @weitch @acess 交易金额设置成 6 美金的话,能多久可以得到确认?
    memecoin
        8
    memecoin  
       2020-12-18 19:05:56 +08:00
    @helloswiftinuk 6 美元的话,应该相当于 130sat/vbyte,现在算应该 2 个包左右吧,运气好的话半个小时吧
    acess
        9
    acess  
       2020-12-18 20:50:15 +08:00
    @helloswiftinuk
    总感觉你好像混淆了一些概念?忍不住想多嗦嗦:
    1.用户用私钥签名交易,然后把交易广播到比特币 P2P 网络,也就是发给比特币 P2P 网络里的其他节点。
    2.其他节点验证交易,确认交易没有违反规则(比如,没有双花,没有凭空造币,数字签名有效,等等),就会把它加入“内存池”,同时把它继续“一传十十传百”给其他节点(所以说不同节点的内存池的内容并不要求一致,并没有全网统一一致的“内存池”概念;但现实中,不同节点的内存池内容大体上都是一致的,所以观察内存池的情况还是有意义的)。
    内存池里的交易都是准备要打包到区块里的,这些待打包的交易还被叫做“零确认”交易。
    3.比特币 P2P 网络里面只有极少数节点(矿池,以及极少数 solo 独立矿工)有算力、可以挖矿出块(也就是在区块链账本上追加内容)。
    矿工挖到新区块时,当然也要把整个区块广播出去(所以实际上每笔交易的数据在网络上被重复传播了一共两次),但是一般用户用不着关心怎么把区块广播出去。
    用户关心的是自己的“零确认”交易有没有被打包到区块里(从而被写入区块链账本),以及,打包自己的那个区块后面又跟了多少个区块(包括打包交易的区块本身,一共 N 个区块,就是 N 个确认)。

    现在的情况,就是内存池里积压的零确认交易太多了,矿工会按照每笔交易的矿工费,除以交易的“虚拟字节数”( vByte,按照规则,隔离见证交易的一部分字节数在统计时要打个折扣优惠,就这样得出比实际字节数少的“虚拟字节数”),算出一个费率( sat/vB,聪 /虚拟字节),费率高的,优先打包进链。

    钱包软件(以及用户自己)可以观察内存池的情况来估算手续费,预计等到全网矿工们再新挖出多少个区块后,自己的零确认交易能“上车”获得第 1 个确认。
    但是很显然,这个估计是不可能准确的,因为每时每刻都仍然有 N 多用户在产生新的零确认交易,没有人能预知未来,所以不可能知道未来有多少人愿意付出比你更高的手续费来“插队”把你“挤到下一班车”。
    acess
        10
    acess  
       2020-12-18 20:59:31 +08:00
    (貌似 Bitcoin Core 并不是直接看内存池里积压零确认交易的情况来估计矿工费的?哎,我觉得这种细节都无所谓,本质问题摆在那里,无论怎么估计都不可能准确的)
    acess
        11
    acess  
       2020-12-18 21:01:47 +08:00
    影响等待时间的其实有两个因素:
    1.上面说过的,内存池积压交易的情况,有多少人会插队到你前面。
    2.矿工挖矿出块的时间本身是随机波动的。换句话说,即便内存池完全没有积压交易,也只是统计上平均等 10 分钟可以等到 1 个确认,实际上当然会有波动。
    acess
        12
    acess  
       2020-12-18 21:10:04 +08:00
    如果楼主要尝试双花的话,要注意不要搞成两笔交易最后都能确认了,这样本来要转出 0.1BTC 的,就搞错变成转出 0.2BTC 了,多转出了一倍。

    只要前后两笔交易互相冲突,花掉的都是相同的 UTXO,最终就只能确认其中的一笔,这样就不会搞成双倍付款。

    如果可以直接右键菜单点“追加手续费”(也就是用 RBF ),这个双花动作就是一键自动完成的了,钱包会妥善处理这个问题。
    acess
        13
    acess  
       2020-12-18 21:13:23 +08:00
    jochen hoenicke 有个内存池监控网站:
    jochen-hoenicke.de/queue/#0,24h
    最下面那张图表“Mempool size in MB”就可以看到你在内存池里排队大概排到哪里了。
    helloswiftinuk
        14
    helloswiftinuk  
    OP
       2020-12-21 12:01:22 +08:00
    @acess @weitch 原来的交易费我查看了 bitcoin core,设置成了交易费: -0.00003840 BTC,这么低的交易费是不是意味着,矿工几乎不可能给确认记账?直接被丢弃掉?
    acess
        15
    acess  
       2020-12-22 11:34:17 +08:00
    @helloswiftinuk 原来的交易现在在 btc . com 区块浏览器里查不到(而且在我跑的一个全节点里也查不到),要么你一开始就没广播出去;要么是已经排队太久,超时了,所以被绝大多数节点从内存池里丢弃了。

    这个手续费放在没有拥堵的时候,是不低的。默认最低的手续费率是 1sat/vB,低于这个,节点默认就不转发、不打包了(但是如果矿工愿意,还是可以打包,并没有禁止这种行为)。

    你可以右键“复制原始交易”,然后随便找个区块浏览器(或者用全节点命令行控制台里的 sendrawtransaction 命令)把交易重新广播出去。交易本身没有过期时间,即便过了默认的过期时间,也可以重新广播出去,其他节点会重新把它加入内存池、等待打包。

    如果你发出这笔交易时就启用了 RBF,右键里应该还可以直接点“追加手续费”,好像不能随意设置要加多少,但是加到了多少还是会明确显示出来的。
    acess
        16
    acess  
       2020-12-22 11:36:54 +08:00
    其实我到现在还不知道你用的哪个版本的 Bitcoin Core,按理说交易详细信息里应该有包括交易虚拟大小的(我看了,在 Bitcoin Core 里还是显示成 xxx bytes 这样,但是这个数据在别的地方一般都写成 vBytes 这个单位,也就是虚拟字节数)。
    acess
        17
    acess  
       2020-12-22 11:51:01 +08:00
    (内存池里积压交易的默认超时过期时间,我印象里也改动过几次,不过这个并不是强制的要求,是每个节点可以自行决定的)
    helloswiftinuk
        18
    helloswiftinuk  
    OP
       2020-12-23 12:50:28 +08:00
    @acess 交易总大小: 192 bytes
    acess
        19
    acess  
       2020-12-23 13:38:33 +08:00
    @helloswiftinuk 矿工费 3840sat,除以交易字节数(你的地址不是隔离见证的,没有折扣,所以虚拟字节数应该是一样的),所以费率是 20sat/B 。
    放在平时不怎么堵的时候,这个矿工费不低。现在看就有点够呛了。

    如果未来市场冷下来了,说不定几个小时过去你就确认进链了;
    如果未来市场又热了,又有一堆人涌进来,发出比你这 20sat/B 更高的交易,插队到你前面,那你又要被卡住挺久了。

    总之,关键是你这笔交易目前好像还是处于没广播出去的状态。要么你就想办法双花追加手续费(能右键点追加手续费,也就是用 RBF,是最好的;如果不能,那就有点麻烦),要么你就直接把这笔交易的原始交易数据(一堆十六进制代码)复制出来,然后找个地方广播出去(全节点的控制台里用 sendrawtransaction 命令,或者找个区块浏览器,不少区块浏览器都提供交易播报功能),等确认。
    helloswiftinuk
        20
    helloswiftinuk  
    OP
       2020-12-24 11:48:05 +08:00
    @acess 请问如何直接把这笔交易的原始交易数据(一堆十六进制代码)复制出来??
    acess
        21
    acess  
       2020-12-24 15:13:45 +08:00
    @helloswiftinuk 右键里就有啊
    mangoDB
        22
    mangoDB  
       2021-01-17 14:51:29 +08:00
    RBF 与 CPFP 均可以通过提高手续费的方法加速交易。
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     2733 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 27ms UTC 07:35 PVG 15:35 LAX 23:35 JFK 02:35
    Do have faith in what you're doing.
    ubao msn snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86