-
Notifications
You must be signed in to change notification settings - Fork 3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove RBF from user visible settings #8088
Comments
From a usability perspective, what you really want to avoid is:
Maybe introduce the logic change as a simple flag that advanced users can toggle, and the default can be switched to "always return False" after the success rate is high enough (enough of the network adopts the mempoolfullrbf flag) |
I think there is no need to update the current logic for the moment. |
We could add a config key that allows RBF-ing non-signalling txs. |
Counterpoint re: usability issues: the times when users are most likely to need this, mempool congestion, are times when due to txs being dropped full-rbf doesn't need any miner support to be fairly often succesful. In fact, you don't even need to be connected to full-rbf peers as a dropped tx isn't being double-spent from their perspective. |
I do not think it is the right approach to add new stuff every time we want to fix a rare issue. I would prefer if we removed the current RBF checkbox in the UI, and we made all our transactions RBF signalling. The reason why we allow users to disable RBF is because some merchants want non-rbf transactions. |
On December 6, 2022 4:49:05 AM CST, ThomasV ***@***.***> wrote:
> We could add a config key that allows RBF-ing non-signalling txs.
I do not think it is the right approach to add new stuff every time we want to fix a rare issue.
Lets stop trying to please everyone all the time.
I would prefer if we removed the current RBF checkbox in the UI, and we made all our transactions RBF signalling.
That would simplify the UX, instead of making it more complex.
The reason why we allow users to disable RBF is because some merchants want non-rbf transactions.
That is the real issue. In my opinion, we should not let those merchants dictate what we do.
I think that's an good approach. Ironically, one that full-rbf can help. 😂
|
ok, let me reopen this. with full-RBF, the RBF setting does not make sense anymore, it makes sense to remove it from the GUI. |
I think the main merchant that caused problems in the past was BitPay. Are they still rejecting RBF payments today? Are there other payment processors still doing that? edit: actually, I do not think they are rejecting RBF payments. they just don't accept before they are confirmed. |
Bitrefill treats RBF differently, waits for a confirmation, but does not outright reject RBF. Though given what they are writing re: exchange rate risk, they may do so in the future.
When you say that BitPay was rejecting RBF, you mean they would actually cancel an order and give you a refund?
…On December 7, 2022 8:39:13 AM CST, ThomasV ***@***.***> wrote:
I think the main merchant that caused problems in the past was BitPay. Are they still rejecting RBF payments today? Are there other payment processors still doing that?
--
Reply to this email directly or view it on GitHub:
#8088 (comment)
You are receiving this because you commented.
Message ID: ***@***.***>
|
I am referring to this page: https://github.com/bitpay/jsonPaymentProtocol/blob/master/bip70.md |
Sure, that's fine, at this point I think we can do that.
Even if we make sure all of the transactions we create signal RBF, if a user restores a wallet with pre-existing unconfirmed txs created elsewhere, the question is whether we want to allow RBF-ing those. RBF-ing a non-signalling tx is highly probabilistic atm. First and foremost, I am sure many electrum servers are backed by bitcoinds with default (note: power-users can atm RBF non-signalling txs by using the Qt console to call |
All right. I don't know if bumping the fee of transactions imported from non-Electrum wallets is what the OP had in mind, but I consider that as out of scope. If we have an opportunity to simplify the UX, we should take it. Nothing beats the satisfaction of removing a few check boxes from the GUI. Regarding channel funding, we can keep using the RBF flag as a way to prevent an accidental fee bumping from another instance of the same wallet. As you point out, that solution is not going to work with channel v2, so we will need to address that separately. |
preference from the GUI, because the mempoolfullrbf option in Bitcoin 0.24 makes RBF signaling pretty meaningless. Fixes spesmilo#8088. Note: RBF remains disabled for channel funding transactions. In that case, the flag is actually only used as a semaphore between different instances of the same wallet.
Unfortunately, the latest release with the RBF checkbox removed has made it practically unusable with the popular bitrefill merchant during the high mempool times that have been pervasive lately. Instead of processing immediately with a minimum sat/byte rate they provide when RBF is disabled it instead requires one confirmation. Been waiting 40 minutes so far for my transaction to process. The only alternative is to bump the fee up to levels that makes the transaction itself impractical. |
@pscopic Your objection doesn't make sense. Bitrefill doesn't immediately accept unconfirmed transactions without very high fees. Eg at this moment, mempool.space is estimating 50sat/vB is required to get accepted into the next block, while bitrefill requests a tx fee of >70sat/vB for immediate acceptance. Anyway, Electrum supports Lightning. If you want instant confirmations, use it. |
Thanks for your reply, and you're right they do charge a surtax for immediately accepting unconfirmed transactions that can average 40-50% more than the sat/byte to get accepted to the next block listed on mempool.space. Despite that, setting my sat/byte to that premium can still take hours before I receive that first confirmation without the ability to turn rbf off. And while I take your point to use lightning, there doesn't appear to be any decent updated documentation on how to use the android electrum lightning feature despite the recent changes to the UI. If you know otherwise please let me know as the bitcointalk docs for android lightning are terribly antiquated. As it stands it appears to add a level of complexity that runs counter to the intent of removing the rbf checkbox in the interests of simplifying the UI. |
I did some testing recently and at the moment Bitrefill doesn't seem to accept zeroconf at all. How exactly have you been able to get it to work?
…On June 18, 2023 5:34:42 AM EDT, PS Copic ***@***.***> wrote:
> Bitrefill doesn't immediately accept unconfirmed transactions without very high fees.
Thanks for your reply, and you're right they do charge a surtax for immediately accepting unconfirmed transactions that can average 40-50% more than the sat/byte to get accepted to the next block listed on mempool.space. Despite that, setting my sat/byte to that premium can still take hours before I receive that first confirmation without the ability to turn rbf off.
And while I take your point to use lightning, there doesn't appear to be any decent updated documentation on how to use the android electrum lightning feature despite the recent changes to the UI. If you know otherwise please let me know as the bitcointalk docs for android lightning are terribly antiquated. As it stands it appears to add a level of complexity that runs counter to the intent of removing the rbf checkbox in the interests of simplifying the UI.
|
Bitcoin 24.0 adds a new
mempoolfullrbf
option that allows for replace-by-fee even if the original transaction didn't set the RBF flag.Currently, the
get_tx_info
anddscancel
functions only consider a double-spend-cancel viable if the transaction has the RBF flag set (i.e.if not tx.is_final()
).As the linked release notes mention, full RBF will now be a mainstream feature even though many alternate implementations have supported it for a while. Either
is_final()
should always return False or it should depend on if the transaction has been confirmed or not.The text was updated successfully, but these errors were encountered: