哪位同学可以帮忙加速一下我的 bitcoin 转账， 2 天过去了。用的是 bitcoin core 推荐的交易费。谢谢！

[helloswiftinuk]

用的是 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

[acess]

区块空间是有限的，给你加速了，你插队了，别人就靠后了。

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

Bitcoin Core 钱包默认应该是启用 RBF 的，如果你这笔交易发出的时候就启用了 RBF，右键菜单里应该有追加手续费的选项。

[acess]

RBF 也是插队，但是它全网公开竞价，一般会比加速器便宜一些。

[acess]

老版本的 Bitcoin Core 也许还没有默认启用 RBF，不知道楼主用的哪个版本。

还有，这笔交易好像没有广播出去？或者说是卡了太久了，被超时丢弃了？可以重新广播，也可以按照 bitcoin wiki 上 fee bumping 这个条目里的操作说明，双花掉这笔交易。

[weitch]

@acess
重新建一次交易，把交易手续费提高即可，就是“双花”，但是最终只有一笔会打包，根本不需要找矿工加速。

[acess]

@weitch RBF 就是这样的，而且可以在钱包里一键完成。不过 RBF 需要发出交易时启用，然后才能进行这种双花替换操作。

[helloswiftinuk]

@weitch @acess 我尝试一下，现在显示的是仅仅有 2 个广播。我看 bitcoin core 界面推荐的是 6 个广播比较快速。谢谢

[helloswiftinuk]

@weitch @acess 交易金额设置成 6 美金的话，能多久可以得到确认？

[weitch]

@helloswiftinuk 6 美元的话，应该相当于 130sat/vbyte，现在算应该 2 个包左右吧，运气好的话半个小时吧

[acess]

@helloswiftinuk
总感觉你好像混淆了一些概念？忍不住想多啰嗦啰嗦：
1.用户用私钥签名交易，然后把交易广播到比特币 P2P 网络，也就是发给比特币 P2P 网络里的其他节点。
2.其他节点验证交易，确认交易没有违反规则（比如，没有双花，没有凭空造币，数字签名有效，等等），就会把它加入“内存池”，同时把它继续“一传十十传百”给其他节点（所以说不同节点的内存池的内容并不要求一致，并没有全网统一一致的“内存池”概念；但现实中，不同节点的内存池内容大体上都是一致的，所以观察内存池的情况还是有意义的）。
内存池里的交易都是准备要打包到区块里的，这些待打包的交易还被叫做“零确认”交易。
3.比特币 P2P 网络里面只有极少数节点（矿池，以及极少数 solo 独立矿工）有算力、可以挖矿出块（也就是在区·块·链账本上追加内容）。
矿工挖到新区块时，当然也要把整个区块广播出去（所以实际上每笔交易的数据在网络上被重复传播了一共两次），但是一般用户用不着关心怎么把区块广播出去。
用户关心的是自己的“零确认”交易有没有被打包到区块里（从而被写入区·块·链账本），以及，打包自己的那个区块后面又跟了多少个区块（包括打包交易的区块本身，一共 N 个区块，就是 N 个确认）。

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

钱包软件（以及用户自己）可以观察内存池的情况来估算手续费，预计等到全网矿工们再新挖出多少个区块后，自己的零确认交易能“上车”获得第 1 个确认。
但是很显然，这个估计是不可能准确的，因为每时每刻都仍然有 N 多用户在产生新的零确认交易，没有人能预知未来，所以不可能知道未来有多少人愿意付出比你更高的手续费来“插队”把你“挤到下一班车”。

[acess]

（貌似 Bitcoin Core 并不是直接看内存池里积压零确认交易的情况来估计矿工费的？哎，我觉得这种细节都无所谓，本质问题摆在那里，无论怎么估计都不可能准确的）

[acess]

影响等待时间的其实有两个因素：
1.上面说过的，内存池积压交易的情况，有多少人会插队到你前面。
2.矿工挖矿出块的时间本身是随机波动的。换句话说，即便内存池完全没有积压交易，也只是统计上平均等 10 分钟可以等到 1 个确认，实际上当然会有波动。

[acess]

如果楼主要尝试双花的话，要注意不要搞成两笔交易最后都能确认了，这样本来要转出 0.1BTC 的，就搞错变成转出 0.2BTC 了，多转出了一倍。

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

如果可以直接右键菜单点“追加手续费”（也就是用 RBF ），这个双花动作就是一键自动完成的了，钱包会妥善处理这个问题。

[acess]

jochen hoenicke 有个内存池监控网站：
jochen-hoenicke.de/queue/#0,24h
最下面那张图表“Mempool size in MB”就可以看到你在内存池里排队大概排到哪里了。

[helloswiftinuk]

@acess @weitch 原来的交易费我查看了 bitcoin core，设置成了交易费: -0.00003840 BTC，这么低的交易费是不是意味着，矿工几乎不可能给确认记账？直接被丢弃掉？

[acess]

@helloswiftinuk 原来的交易现在在 btc . com 区块浏览器里查不到（而且在我跑的一个全节点里也查不到），要么你一开始就没广播出去；要么是已经排队太久，超时了，所以被绝大多数节点从内存池里丢弃了。

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

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

如果你发出这笔交易时就启用了 RBF，右键里应该还可以直接点“追加手续费”，好像不能随意设置要加多少，但是加到了多少还是会明确显示出来的。

[acess]

其实我到现在还不知道你用的哪个版本的 Bitcoin Core，按理说交易详细信息里应该有包括交易虚拟大小的（我看了，在 Bitcoin Core 里还是显示成 xxx bytes 这样，但是这个数据在别的地方一般都写成 vBytes 这个单位，也就是虚拟字节数）。

[acess]

（内存池里积压交易的默认超时过期时间，我印象里也改动过几次，不过这个并不是强制的要求，是每个节点可以自行决定的）

[helloswiftinuk]

@acess 交易总大小: 192 bytes

[acess]

@helloswiftinuk 矿工费 3840sat，除以交易字节数（你的地址不是隔离见证的，没有折扣，所以虚拟字节数应该是一样的），所以费率是 20sat/B 。
放在平时不怎么堵的时候，这个矿工费不低。现在看就有点够呛了。

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

总之，关键是你这笔交易目前好像还是处于没广播出去的状态。要么你就想办法双花追加手续费（能右键点追加手续费，也就是用 RBF，是最好的；如果不能，那就有点麻烦），要么你就直接把这笔交易的原始交易数据（一堆十六进制代码）复制出来，然后找个地方广播出去（全节点的控制台里用 sendrawtransaction 命令，或者找个区块浏览器，不少区块浏览器都提供交易播报功能），等确认。

[helloswiftinuk]

@acess 请问如何直接把这笔交易的原始交易数据（一堆十六进制代码）复制出来？？

[acess]

@helloswiftinuk 右键里就有啊

[mangoDB]

RBF 与 CPFP 均可以通过提高手续费的方法加速交易。