Topic: The Undo Transaction (Read 617 times)

I think you should read a bit about the possibilities for contracts provided by Bitcoin Script and Tapscript (see this wiki page for example). Lightning Network and many other technologies are built on quite similar contracts with timelocks and hashlocks (where you have to provide a secret string to unlock a transaction).

As @stwenhao pointed out already and it would be a P2(W)SH or P2TR transaction so it would not be possible to send coins using this method to standard deposit addresses of exchanges. Instead, it would be sent to a special address, which could be compared to the "contract addresses" in Ethereum for example. You wouldn't be able to deposit this way, as of early 2025, on most or all existing exchanges. Of course this kind of contract would be also publicly visible so it would be very difficult to scam somebody this way, but that's of course not the idea, see below.

This is correct, you could describe this as a "drawback" due to the fees. A transaction to transfer the funds from this "contract" to another address can be "posted" by the sender (since it was sent) and by the receiver (since the "undo block", e.g. 6 or 10000 blocks after confirmation).

Exactly this would be the purpose of this kind of transaction. I could imagine it to make sense in some cases. However, the merchants always have to support it.

I don't really understand how this is related with the "undo transaction" protocol. What you describe would not even need a Bitcoin Script contract. It is also not possible to allow, via Bitcoin Script, to create a transaction only until a certain block. All you can do is setting a start block from which a transaction or output becomes available (methods are: CLTV, CSV and the standard Locktime), but you can't set an "end block". In the case of the "undo transaction protocol" I proposed, the transaction can be reversed also after more than 6 blocks, but then the other side (the receiver) would also be able to transfer the coins.

No. If you change the output Script, then it changes the recipient's address. Which means, that the recipient has to explicitly accept it.

However, if you use transaction locktime, then you can fool some block explorers, which don't check locktime properly. But of course, most exchanges won't fall into that, because they usually wait for at least one confirmation.

In that case, Bitcoin can have the best rules you can imagine, but you won't be protected in any way, if you deposited your coins to some centralized exchange, and they are handling your coins for you.

What D5000 is describing sounds like a vunerability in bitcoin

So are you "saying" that it's possible to send bitcoins to an exchange like for example MEXC and then "fool" them by having the script delay the "ownership" by say 10000 blocks... and then if MEXC falls for it and credits the attempt with on exchange credit then later the owner of btc can reverse the transaction (Reversing the transaction in this case, would mean posting another transaction, before the 6th block... so before the script activates... at least that's what I believe how this might work, as you wrote the owner is still in control during these 5 blocks... or in my proposed "attack case" 10000 blocks...)

Also this idea is not to scam people, it's kinda the opposite of this... people could force other people to make rushed decisions, for example exchange seizes to exists... and people make plenty of typoes... just imagine software without an undo function, photoshop, paint, notepad, wordpad, word, office, excel, programming/editors, etc...

(LOL: Imagine Binance says: we're shutting down in 5 minutes ! if not withdrawn by then, all funds losts/seized by us, bye bye ! =D If you have only bitcoin, maybe... if you have multiple coins, oops, no time to check nothing... gogogogogogoggo)

Yes, because the recipient can transfer the coins only after the 6 blocks. So in these 6 block times, the sender would have complete control over the transferred funds. The implications would be exactly like in the OP's idea.

Of course if the scammers are using psychologic tactics as you describe, they could be successful in preventing a revert. The "time window" for the reversal could however also be made longer by the sender -- as long as they please, so if a merchant seems to be particularly fishy and you aren't in a hurry you could make the transaction reversible for 100 blocks or more.

The process of course could be implemented in an automated or semi-automated way (e.g. as a "temporarily reversible transaction") in the popular Bitcoin wallets.

Of course the scammers could then clarify in their websites or messages that they wouldn't accept this transaction type. This could, in this case, be a red flag (and be communicated as such in anti-scam campaigns).

I have thought a bit about the idea and it seems to me now less stupid than I thought before. Basically the main drawback is still the fee (and also the space the original transaction would take on-chain) which would be about 20-30% higher in the case of a simple transaction with 1 input and 2 outputs. But the workflow at the merchant's side would be similar to regular transactions, because merchants anyway will often collect the coins from the deposit addresses where their customers send the coins, and consolidate them into larger hot wallets and finally into cold wallets.

The merchant would only have to make sure that the items they sell only will get sent after the funds are consolidated into their own wallet addresses where they have full control of.

Will this help in the situation of an attempted Scam which I presume is one of the reasons OP came up with this idea?  Though I would argue if somebody knows how to do a Locktime, they will possess enough knowledge to avoid stupid Scams.

Anyway, even in this situation it would be useless to implement the option to reverse a Transaction.  It would only make Scammers change their ways and asking the elderly victims to simply wait for the 'Confirmation' as in 50 minutes or however it takes for the final Block to be Mined before it is considered irreversible.  If the elderly have enough time and are silly enough to gather their monetary resources, go to a public ATM and deposit their Money to the Address of the Scammer, they will be silly enough to impatiently wait for the Bitcoin to finally be 'processed' by the Scammer.

Just if someone is interested in a similar solution: What the OP suggests is already possible with good old Bitcoin Script

@gmaxwell has mentioned Locktime, which is a good solution for those with devices which are always online, the only problem is that you would need to stay online during these 6 blocks because the other Bitcoin clients would reject to add it to the mempool.

To make it work almost exactly like described in the OP you would simply need an CheckSequenceVerify output going to the recipient's (e.g. merchant's) address, set to 6 blocks after the tx's confirmation, and an alternative output going to an own address. After 6 blocks, the recipient can transfer the coins to another address, but before that block, the sender has the full control over the funds and can simply undo the transaction.

However in my opinion this doesn't make much sense. What's the point of signing the utxos (and thus expose data to the merchant) if you don't know if you will spend them? The only advantage I see is that a merchant is anyway likely to only accept a transaction after 6 confirmations, and thus you would have similar reaction times compared to a "standard" transaction. The downside is a higher fee.

I'm not sure what you mean by "evolved", the unconfirmed transactions in the mempool has never been safe or final. And RBF affects those not the confirmed ones that are included in a block which are as irreversible as they've ever been.

Irreversibility is one of the Bitcoin’s most important and core features. Irreversibility and decentralization are actually concepts really close to each other. You will need a third party to implement irreversibility. This is all explained in Satoshi’s whitepaper.

Bitcoin should stay irreversable just like cash, to be acted on like digital cash; and actually should improve to be more untraceable, just like monero.

This is my 2 cents, anyways.

Interesting point, however it seems:

1. Bitcoin has evolved beyond this point (see replace by fee feature)
2. Eventually the transaction will be permanent.

You can already do that if the shop accepts RBF Transactions.  There is no need for a new protocol to undo a mistake.  Not to mention that Bitcoin is not a system that should allow human mistakes anyway.  It would be cool if there was a way to cancel every single mistake and ONLY mistakes, but that is impossible.  The safest method is to not allow them at all and ignore every mistake that happens by not even being able to distinguish between a mistake and not.  The main idea is very basic.  You either take your time to do things right or you blindly do it.  If you blindly do it, expect nothing good.

Not just that.  I can undo the undo that I undid before undoing my undone Transaction.  That is six Transactions in a row and the most distant time span it can happen in is approximately 300 minutes or 5 hours.  This can become really tiring for the Bitcoin Blockchain and could clog it up almost immediately if enough people do it often enough.

Imagine the bots who sweep vulnerable and publicly known Bitcoin Addresses people still end up sending Bitcoin to.  Bot 1 sweeps it, bot 2 undoes the Transaction.  Bot 1 undoes the undone.  And so on, until either one of them gives up or the Miners take most of that amount and the change of a few Satoshis stay in the Address until another Transaction is received only to be fought for by the same bots.

Stupid idea.

This idea sounds alot crazy.
Just wait until I go down to a shop, make payments for a goods, and undo the transaction on my way back home.
And besides, this idea will give miners more work to do than they already have today. So, let's just stick to the rules.


RBF is a perfect alternative for the OP's idea, but my respect to those who uses this feature frequently.

I actually tried this feature twice, and I was like : "Okay, I'm done".
Paying double fees on two different occasions actually hurts. My patience will do more good than harm.

Can we please stop responding to the anti-bitcon FUD spreading troll?
Take a good look at all the topics the OP has started and save some time and ignore him.

https://bitcointalk.org/index.php?action=profile;threads;u=46551;sa=showPosts


Or keep arguing with the troll. Up to you.

-Dave

Good luck with that.

Right. If your best example is the completely unrealistic scenario in which I keep lots of money on an exchange, there's no point discussing this. I like my Bitcoin transactions to be immutable.

They don't call me Switzerland because you can "press my buttons".

Sure. Your house is on fire and you need to pay the private fire brigade with Bitcoin. Now you have to wait for 5 confirmations before they know you can't replace it anymore, and another 6 confirmations so they're sure no miner would Fork away 6 blocks on top of that. Your house is gone now.

OP, please follow this forum rules.

---

Yes, it only applies to transaction 0 confirmation. That's why i bold text "unconfirmed".


Even if a transaction doesn't have replaceable or RBF flag,  you still can use full RBF to replace it.


Most node would simply drop the TX either after 2 weeks or if their mempool is full.

---

You missed my point. My point is people who accept Bitcoin would require more confirmation in order to make sure the TX can't be reversed or undo-ed.

First paragraph of the first section (introduction) on the first page!

This is a pretty cool idea, however there are some problems with it, the user might only notice the problem, once the error transaction is processed and accepted by the blockchain, for example it is seen by block explorers and/or the user notices it's not showing up as it should...


You're thinking process is not as safe as you think it is, it can be attacked, by for example making you panick somehow, interesting isn't it !

For example:

An exchange just announced it's closing up shop soon, and you have lots of different coins on it, including bitcoin, now you must decide what to do, you worry that if you too late you will not get a good exchange price, and you must think, do I sell ? or do I extract and pay withdraw fees, the time is ticking, plus your sister just called and told you she is quite pissed that Trump won ! LOL and wants you to make some kind of report immediately ! LOL, you hear the distress in her voice, she didn't literally tell you she is pissed about Trump, but the emotion gets to you !

Just one little example of how somebody could "press your buttons".

Maybe you can think of something that makes you panick, recent panicks might be the recent fires in L.A. where people lost their homes, perhaps sleep deprived from all the stress, fleeing for their lives, not sure if their brains would still function properly after all of that, and they try and buy something with bitcoin...


Funny assumptions, being made. 1. How do you know what bitcoin was ment for ? Are you Satoshi Nakamoto ? 2. Do you mean bitcoin was ment for robots/AI ? 3. What you wrote about replace by fee could be an admission that bitcoin needs to be a bit more forgiving, so perhaps a trend.

I have not heard of a technical reason yet, why it could not be implemented. Basically "it's a state" thing and state can be modified by anything... however one has to known when the "state" is truely considered "stable"... in that sense my proposal does fit within the "6 confirmations" and the state should be stable mantra.

Anyway consider the following:

1. Either get used to 6 confirmation times + undo possibility

or the alternative

2. Loose funds when making a typo.

Depending on the typo and situation, it could be small, medium, a lot or all of your funds...

It's trivial to do so. Just get a miner to include your desired transaction in their block. Even if its not tagged as RBF, a transaction that is included in a block first is generally final.

The usual advice is to wait 1 confirmation before a Bitcoin transaction can be confirmed. Inclusion of a transaction into a block is generally considered finality and if this is implemented, services who are currently adopting 1-conf transactions will also have to wait for 6 confirmations.

Your advice is trying to solve an issue that has never existed. We cannot expect to babysit people for their carelessness and incompetence. Sent it wrongly? Suck it up. Besides, you've got plenty of great ideas over here; delaying a transactions locally for an hour for you to reflect on it sounds great to me.  

NO, You can immediately undo the transaction, that is the entire idea, the faster the better, you have until the 6th confirmation comes in, if the undo transaction was not issued/seen by the network by that time/block, the undo transaction is no longer valid/accepted and the transaction is permanent.

So the idea is you must submit the undo transaction before the usual/guidance/advise of waiting 6 confirmations before a bitcoin transaction can be considered valid/safe.

Consider the "impossibility"... well some mention a feature which can be used to replace "in flight" transactions, this new idea is to enable "stored/commited transactions" to be "undo"/marked as invalid/undone.

So this would be a change/addition/modification to the bitcoin protocol and source code to *make it possible* =D


I think this is nonsense, the original transaction will simply be ignored/overruled by the undo transaction which will be recorded in block 1,2,3,4,5 after the original transaction.

As far as I know private keys are never revealed in bitcoin... it's only used to "sign" a transaction, and therefore there is no problem, and an undo transaction can also be signed by original user, whoever it was transferred to is not the new owner, as it was rolled back/undone...

I do see one potential problem with this idea: a merchant must keep up with the blocks to see the undo transaction, if the merchant's bitcoin system would go offline it might not see the undo transaction...



Which parts of the paper you believe has this intention ?


Strange conception you have. Bitcoin general advise is to wait 6 confirmations, this is not unnecessary, it's the way bitcoin works internally, it's possible for their to be multi-chain/multi-end points, basically a race condition, where multiple chains are the longest, only after some time will one grow faster than the other.


Why is the exchange included in the transaction, that part of your comment/reply I do not understand ? Maybe to convert dollars into bitcoin and then pay at the coffee shop with bitcoin ?


While bitcoin is the gold standard of cryptocoins, it is indeed slow, the idea is that other faster blockchains/dagchains will overtake/also incorporate this feature so that faster blockchains can also support it, but maybe with more "grace" blocks, otherwise the undo time would be quite limited.

Concerning the scammers It's good practice for people to wait a certain number of transactions for confirmations =D This could also be build into software to make sure transactions weren't undone.


I think the opposite logic could also be used, it gives people the chance to recover from malicious events, like people realize they got scammed, by for example sending small amounts of bitcoins to rich bitcoin people and these addresses end up in their wallets and they send to the wrong address because it was a smaller address, for example:

ert45345...3453453
ert45345...3453453
^
A known attack where some wallets don't display all digits and the ... contain the scammers address.

I don't think the bitcoin paper every mention irreversibility, it just uses hashes to provide security and solve a race condition primarily, that is something else.

I guess this is only applicable when the transaction has gotten 0 confirmations.  This too should have a  big risk of  getting a stuck transaction usually when there is no  transaction with higher fee to replace it and what if the the transaction wasn't marked as replaceable in RBF I guess Reversal will be impossible.

for full-RBF irrespective of been marked as replaceable once there is 0 confirmation i guess it can re replaced with a transaction with higher fee. But what if there are no such transactions for a long time how long will the network congestion last?

Bitcoin is not for human errors, there was no place for it when it was created but later some things changed and at some point, it's forgiving to human errors. For example, there was no Replace By Fee and now, with Replace By Fee option, you can increase the transaction fee in case it doesn't get confirmed and you can also reverse the transaction before it gets confirmed in the next block. i.e. if you aren't unlucky and your transaction doesn't get confirmed immediately, you have some time to reverse transaction by paying a little higher fee.

What you describe is the problem that Bitcoin tried to solve (double spend). So, that can't be implemented in Bitcoin. It doesn't work like that, it doesn't count minutes, it counts confirmation and also by following your idea, it will take lots of time to get Bitcoin transactions confirmed but majority of people want to get it confirmed ASAP, so many businesses that offer instant deposit, won't be able to show you deposit for at least 50 minutes.