You can do multiple RBF. The only anti-theft solution will be implementing covenants. So in the tx construction could be enforced the rule to be sent to the same destination address.
Thanks for your reply!
I'm curious, why is it not possible to cancel unconfirmed transactions? Is it to prevent spam attacks on the mempool?
reply
In my limited understanding, a cancellation wouldn't be guaranteed to propagate to all nodes.
A feature of distributed networks. Kind of like it's not possible to delete Nostr notes - some relays would receive the deletion, some wouldn't, so there is no surefire way to delete it. A note only needs to be broadcasted to some relays, whereas a deletion would have to be broadcast to all, which is a much harder distributed computing problem.
With RBF you can effectively achieve a cancellation by sending it back to an address you control, but it makes the protocol more robust than a deletion would (because the double spend prevention with the longest chain heuristic, which is already in place, gives you the reliability needed without having to handle a special 'cancellation' case) and it costs a fee, which also helps prevent spam.
reply
Great response
reply
once is broadcast and all mempools knows about it the only way to "cancel" it is RBF or CPFP. If the fee is too low, then you could just wait and after 2-3 weeks is purged.
reply
I don't think it's possible to cancel a transaction with CPFP, no?
reply
You never cancel... you just replace it.
reply
Darth is right. The original transaction is a valid transaction. Once you broadcast it, you have no way of knowing who has a copy of it.
When you broadcast a new one, like a RBF or just a simple double spend, you are hoping that your new transaction will get mined before the old one does.
But you don't have any way of reaching into other nodes' mempools and deleting the old transaction. So you can never truly cancel it until the new transaction is mined and it makes the old one invalid.
reply
Not to hijack the thread, but curious if you, @darthcoin, support OP_CTV proposal soft fork.
reply
I am more inclined to LNHANCE
reply
I will read that BIP. Cheers
reply