btcpayserver
Include Replace By Fee (RBF) in transaction resources
Bitcoin transactions can be replaced an other transaction spending the same (or subset) UTXOs. This feature is called Replace By Fee and is a useful addition to the semantics of a transaction.
Transactions can explicitly signal they support this feature via the sequence field setting this to less than 0xffffffff - 1. Or do so implicitly when one of their parents explicitly signals RBF.
The risk is that malicious users can pay with an RBF transaction, get the goods/services from the merchant and the broadcast another transaction spending the same UTXOs to a different address. This risk only applies when the merchant doesn't wait for the first confirmation. This happens often (all the time?) when doing face to face transactions.
It would be great if the responses from the API involving transactions would include a field telling the API consumer about RBF signalling. Perhaps a boolean field isRBFSignalling would suffice. This way the API consumer can decide what is best in their scenario.
Obviously Lightning is the better payment solution in such a case as we're dealing with (probably) small values and a face to face transaction.
This should also be include in the IPN notification response, so action can be taken if required by signalling.
This should also be include in the IPN notification response, so action can be taken if required by signalling.
The IPN response should never be trusted. You should only ever grab the invoice ID from the IPN and call get invoice through the API to be sure no one faked an IPN call to you.
Even then, when using BTCPay, integrating against the paid status vs confirmed or completed is wrong.
IMO, the only risk I see here is for physical shops, who just display the checkout and wait for payment. Maybe we can add an opt-in option to display a yellow warning on the checkout UI on RBFed txs
Another simple way is to lookup the txid with blockexplorer API that will return the RBF flag
- Blockstream - Works if tx itself is RBF opt-in (Not sure about inherited RBF)
- Blockonomics - Will return data for both explicit and inherited signalling
Another simple way is to lookup the txid with blockexplorer API that will return the RBF flag
This is what I'm currently doing with Trezor's Blockbook. I was unfamiliar with Blockonomics! I'll dig into that.
@haarts you're original request was related to the API, but there's been some discussion on Telegram about showing this on invoice for retail merchants.
Suggested changes here are related to #1319
There have been some suggestions on changing This invoice is paid to
Your payment is broadcasted but I'm not really sure if we should make changes like that without more feedback.
I think this is good, I would suggest changing the "Payment Broadcasted" -> "Payment pending confirmation" I just do not think "broadcasted" is grokk, my suggestion my be only a little better. i.e. "confirmation" is as bad.... ideas anyway.
That's actually much cleaner solution, good idea, hopefully it does not break the current workflow of shoppers too much.
Perhaps we can make the payment pending text a bit more prominent, I just want to make sure people know they're payment is sent, don't want them hanging in confused on what happened.
yeah that is clean. I think the big tick is the best visual to show all is ok, however there is still education for the merchant here if they are releasing valuable goods. i.e. 0 conf RBF = bad. So a non RBF a green tick ?
Yes, @Kukks's idea was to show yellow tick for RBF only.
I'm torn if we should leave it yellow for all or not.
I've posted screenshot in #1319 where similar issue is being discussed.
I like the different colours,
- green, non RBF
- yellow, RBF signaled Would you consider the "RBF Transaction" to be RED in colour. I guess the little dots beside are clickable with more explanation for merchant ?
@mjlamb Yeah those should be tooltips providing concise text on what's going on. Possibly an external link to a reputable website for further clarification.
If you guys have tooltip text suggestions, fire away. 🔥
ToolTips - Green = Your payment is currently being confirmed, its always a good idea to wait for at least one confirmation. This is especially important if the payment has been flagged with "Warning RBF Transaction"
ToolTips - Yellow = This payment has been flagged with a Replace By Fee (RBF) Transaction flag. It is advised to wait at least 1 confirmation before releasing of any product or services.
Tooltips... could work on those, not sure how much space we have. Regarding the "RBF Transaction" it is a warning. I would visually enhance it as such. i.e. "Warning RFB Transaction" and make it a warning ORANGE colour.
The thing is, this kind of feedback needs to be addressed to the buyer, not the merchant on the front end, we'll need to do a hack of a brainstorm to get this one right or possibly make it neutral.
"RBF means..."
Yeah usually both parties are viewing / seeing the screen however, so natural is good agree.
Surely the RBF Warning is for the merchant in this case, they need to know about that. So this is really in the case of being face to face, would be good and I think you have suggested this that this can be switch on in the merchant settings.
@haarts you're original request was related to the API, but there's been some discussion on Telegram about showing this on invoice for retail merchants.
Ultimately that's our use case too. We're making a PoS app and alerting the merchant that this onchain tx can be reverted is very important.
@haarts How would you solve this UX wise? Would images shown above be good enough or? What kind of warning would you put on the invoices/tooltips?
Consider that it has to be somewhat neutral and that both merchants using this in retail as POS and customers (online or in brick in mortar) need to understand.
I'd think a merchant switch which would make the RBF Transaction more predominate looking. Could be "Warning RBF Transaction Used" and this could be in a warning style orange colour, and if this is not switched on just a "RBF Transaction used" message like you have now. I think it is the merchant that needs the higher level of Warning so they can proceed cautiously.
@haarts How would you solve this UX wise? Would images shown above be good enough or? What kind of warning would you put on the invoices/tooltips?
Consider that it has to be somewhat neutral and that both merchants using this in retail as POS and customers (online or in brick in mortar) need to understand.
To be very honest we're struggling with how to represent this best to the merchant/customer. At the moment we're showing a smallish warning on the 'paid' screen. But this is rather dependent on the situation. If a customer pays a coffee with an RBF tx all is very likely good. But if the customer pays for his lavish 10 course meal with the entire company present, that's an other thing entirely.
In the end I believe on chain payments are not the way forward for PoS apps. We're pushing for LN but this is hard and will probably take months/years. So we need to resolve this in the meanwhile.
IMHO the consumer does not care about the difference between broadcasting and confirming. The merchant should not ship if the invoice is not confirmed, RBF is not relevant to the decision.
For physical retail, they all takes the risk of double spend anyway and accept payment even if the tx is not fully confd.
What would be useful though is a details link showing transaction information that we can see in the invoice details if you are logged in. It does not have to be in the checkout UX though.
@NicolasDorier the use case in retail is that when using point of sale on a counter, the cashier won't log in into back-end to check a transactions, it shows paid and they'll trust it's paid.
We can show a floating pop up just like we do in the crowdfunding maybe.
@pavlenex what a cashier is supposed to do if the customer come and pay with RBF precisely? Ask him to wait in line for the transaction to confirm to get his coffee or just give the coffee and process next customer, accepting the risk of double spend which can occur with any method of payment outside of cash?
Coffee may not be a good example what if I bought 2000$ PC. Would you let me walk away? Unfortunately this is always risk for the on-chain in retail, we should at least indicate somehow.
How about some of the examples I showed? It's on us to indicate it to merchants, up to them what they want to do with it.
@pavlenex I agree, value of the transaction matters. Merchant should be able to see RBF clearly if required, I'm for a switch to turn it on/off in checkout settings.
@mjlamb if that's only relevant for merchant, then it should be in the Invoice details page, not the checkout.
In the case of a physical shop using the Pos app on a phone, they would only have the checkout loaded so that would not work.
On Tue, 17 Mar 2020, 15:38 Nicolas Dorier, [email protected] wrote:
@mjlamb https://github.com/mjlamb if that's only relevant for merchant, then it should be in the Invoice details page, not the checkout.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/btcpayserver/btcpayserver/issues/1330#issuecomment-600107007, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAN357RYLT5MCRKL45V237DRH6DQFANCNFSM4KS4MV2A .
@Kukks so that would mean such physical shop can only process 1 customer at a time every 10 minutes, as you can't see more than 1 window on a phone.
so at the end of the day this feature is for:
- A business accepting max 1 customer per 10 minutes (so no big retails store like Biccamera)
- Selling expensive items
- Physical
- Information only relevant for merchants
This is a niche, so we should not bother the UX for normal customers. For noobs consumers this is more confusing than anything, and would put pressure on wallet to stop using RBF for something that is not even safer.