Comment by lazaroclapp | Hacker News Reader

Comment by lazaroclapp | Hacker News Reader

Parent Full thread

I mean, in many contexts I would ok to pay in a way that cannot, under any circumstances, be reversed. Specially if the other side of the transaction is equivalently irreversible (that's the whole idea behind smart contracts). For the things where reversing payments is a desired feature, you can build that on top of crypto-currencies (e.g. by using an escrow), so is not like it has to be the wild west. You can get reversible payments or irreversible payments (after confirmation) depending on what the transacting parties need. This flexibility is a good thing.

The problem is that this recent change, allows you to claw back your payments without any third party signing off on it, and without your counterpart being able to appeal the claw back. It is also a "feature" most people don't know about, because it is the consequence of the low level implementation of something designed to solve another problem altogether. This change existing and being unknown will lead to more fraud vs plain old "irreversible" transactions. And it is strictly worse than being able to claw back your transactions by appealing to the credit card processor, even if under Bitcoin the payment becomes "fully irreversible" earlier than under card processor rules.

The argument for why this is not a bug, is that even before this change, a transaction could be reversed via a double spend with a certain probability. However, this change makes unilaterally reversing a transaction trivial and certain for multiple hours after it was originally created.

The recent change is entirely opt in.

"Most people don't know about"

The only people affected are those who accepted 0-conf transactions. If you accept them, either you trust the person, or you accept the risk. In the first case, this change makes no difference. In the second, you should be checking for the flag that says the payment was opted in to RBF.

>However, this change makes unilaterally reversing a transaction trivial and certain for multiple hours after it was originally created.

This is false: it is trivial until accepted into the blockchain. That usually happens for normal transactions far sooner than several hours.

> The recent change is entirely opt in. [...] In the second, you should be checking for the flag that says the payment was opted in to RBF.

Do you know if most common bitcoin wallets and payment processing APIs accept or reject payments which have opted in to RBF? It might be a configuration issue, but how big a deal this is depends entirely on what the default configuration is. Still, thanks for the clarification. From the article I assumed all transactions were RBF capable now, without any way to disable it.

> This is false: it is trivial until accepted into the blockchain. That usually happens for normal transactions far sooner than several hours.

Fair enough. The point is that confirmation might take several hours. If I want to accept 0-conf transactions for say, my Bitcoin-powered public coffee machine (not an actual product, but should be...), then I feel a bit safer if canceling 0-conf payments is hard to do and unreliable, even if I don't have any strong guarantees. Waiting even a few minutes for confirmation before brewing coffee might result in grumpy sleepy customers ;)

>Do you know if most common bitcoin wallets and payment processing APIs accept or reject payments which have opted in to RBF? It might be a configuration issue, but how big a deal this is depends entirely on what the default configuration is.

I don't know. Any serious business (which, unfortunately, doesn't describe many bitcoin ones) should be monitoring them, and frankly, as I said above, if you're accepting 0-confs and not checking for the flag, and sending irreversible products, you're beyond my sympathy. Official guides to accepting bitcoin always say to wait several confirmations, and anyone accepting zero confs has make that decision deliberately.

> If I want to accept 0-conf transactions for say, my Bitcoin-powered public coffee machine (not an actual product, but should be...), then I feel a bit safer if canceling 0-conf payments is hard to do and unreliable, even if I don't have any strong guarantees.

As far as I can see, this is entirely alleviated by the opt-in part. Just reject any transactions that opt in.

I've seen people complain that users will opt in by default and be turned off if they need to wait, but that's a problem with whatever wallet they're using. If I was designing a wallet, I'd make an "enable undo?" button, with a warning that said "if this is checked, you can undo until it posts, which usually takes a few minutes. Be aware that some merchants won't accept such transactions, so if you're buying something instantly then make sure the merchant is ok with it.", and merchants should have signs telling people to turn off the undo feature.

> For the things where reversing payments is a desired feature, you can build that on top of crypto-currencies (e.g. by using an escrow), so is not like it has to be the wild west.

As it stands with credit cards, it's 180 days maximum for a chargeback; meaning that the consumer has six months to make up their mind on any transactions they may not deem acceptable.

How long should it be in escrow if we're to switch to Bitcoin? I don't see how merchants will want to wait six months for them to see any payments and I don't see how consumers will want to see the timespan lessened.

Reply on news.ycombinator.com