Topic: Do you think that .... (Read 283 times)

This demand is good, if the newly issued coin, you can consider adding this feature.

It is handy but imposibble for now. To implement this feature, there should be many many changes in the code base.

Why do you want this to be applicable? This will be like reversing a transaction and that will probably harm the grace of Bitcoins that once sent, it cannot be recovered.


You should not send it to wrong address only at the first place.
There might occur scenarios where, after gaining some trust between parties, one of them might make wrong use of the feature you are asking about.
Every transaction gets recorded in the blockchain and in order to removed that transaction, you will need to tamper that block for which work is already in process by the miners.

No.  (And if you ask a yes-or-no question...)


It’s not technically feasible, and it would be bad if it were.

Nodes “broadcast” transactions; and that word is used for a reason.  After the transaction has been passed along to other nodes, you have no way of knowing at any particular moment how many nodes have received it, or which.  You also have no way of knowing whether a miner is working it into a block.  All the same would apply as for a hypothetical “cancel” command.  Thus some nodes might get the transaction, some might get the cancellation, some might get neither, some might get both.  Over time, the situation would approach that last—but you have no way of knowing when.

Similar applies for RBF, but not the same:  Miners have an incentive to accept the replacement, due to the higher fee.  Nodes which never get the original but get the RBF have more or less simply received a transaction.  But RBF is not guaranteed; a miner could work the original into a block, and then the replacement would be rejected as a double-spend.

And all this is this way, because...


There is no such thing as the mempool.  Each node has its own mempool; there can be and often are significant differences between them.  (You probably know this; but most people don’t, and it’s easy to forget.)

How do you reliably give the cancellation to all the nodes who received the transaction?

And why would a miner accept a cancellation, and throw away the fee?  Unless the cancellation is itself a transaction which pays a fee; if RBF rules were different, an RBF replacement with zero outputs other than coinbase (fees) would de facto operate this way.

OP:  When a transaction is sent to the network, from this standpoint (if not others), it should be considered already irrevocable.

Zero conf has pretty much been impossible for a while, with RBF and double spending. I think lightning network will be the new way to make instant Bitcoin payments.
I think something like this could be as simple as broadcasting a request to remove a transaction from the mempool.
I don't think there would be a second transaction to cancel the first, as that would take space in the blocks, so it would take fees, so it wouldn't be that helpful. Like I said to your second point, I think a request to remove a transaction from the mempool would be a much better solution.

Yes! I guess this is a good suggestion.

Hey everyone in the Bitcoin forum,
Do you think that allowing users who sent out transaction which is unconfirmed is able to cancel that transaction is a good thing?
i personally think that bitcoin should implement this Feature, like if you sent out an transaction to the wrong address you can quickly cancel it before it gets confirmed which will save lots of trouble for some.
Let me know what do you guys think about this feature?