Timed delay cancel transactions

[ben19850]

Say you wanted to buy a $100 million house with BTC
apart from doing teat transactions to the RECIPIENTS ADDRESS there’s no way of stopping a transaction

I know you can copy paste a wallet address and check over the charters of the ADDRESS but…

Wouldn’t a way to cancel the transaction be safer?? Say 1 hour delay the recipient to see there’s a incoming transaction then the sender allows it to clear(if the recipient dosnt confirm he’s sees it’s going to post the sender cancels it BTC stays in there wallet)

[1714478098]

1714478098

[jackg]

Some wallets do actually already have this. It's possible at least in bitcoin core and electrum to sign a transaction and store it locally before broadcasting it later on (the difference is you don't hit broadcast, and in case of electrum you hit preview to save the transaction in your wallet history).

Once saved, it's also easy to delete those records from wallet history too.

[ben19850]

Some wallets do actually already have this. It's possible at least in bitcoin core and electrum to sign a transaction and store it locally before broadcasting it later on (the difference is you don't hit broadcast, and in case of electrum you hit preview to save the transaction in your wallet history).

Once saved, it's also easy to delete those records from wallet history too.

So it is possible could this be implemented  into a hardware wallet

Also, I would like to see a white the recipient could see there is going to be an incoming amount. Also a time delay. He can also see that as well.

[LoyceMobile]

Say 1 hour delay the recipient to see there’s a incoming transaction then the sender allows it to clear(if the recipient dosnt confirm he’s sees it’s going to post the sender cancels it BTC stays in there wallet)

If you're unsure if the receiver gave the correct address: send a small amount first. Bitcoin transactions shouldn't have a "cancel" button. If you want unreliable transactions, use Paypal.

[HeRetiK]

Some wallets do actually already have this. It's possible at least in bitcoin core and electrum to sign a transaction and store it locally before broadcasting it later on (the difference is you don't hit broadcast, and in case of electrum you hit preview to save the transaction in your wallet history).

Once saved, it's also easy to delete those records from wallet history too.

So it is possible could this be implemented  into a hardware wallet

You can use most hardware wallets (at least Trezor and Ledger, not sure about the others) with Electrum as user interface, so you can already store transactions locally without broadcasting them, even with a hardware wallet.

Also, I would like to see a white the recipient could see there is going to be an incoming amount. Also a time delay. He can also see that as well.

That, you can't. Not in a trustless manner. Though you could, for example, prove that you have the required amount by signing a message with an address that has sufficient coins. Alternatively you could go through an escrow, though that of course requires trusting a third party.

[pooya87]

Practically something like that is not needed since the receiver should see the transaction immediately in their wallet/node as unconfirmed. Additionally "canceling" transactions is not a good option to have although I should mention that any unconfirmed transaction can be "canceled" so to speak (by double spending the inputs).

The closest thing I can think of is for you and the receiver to create a "script" and then make the payment to that script that contains a condition. The only problem is that the receiver has to spend this output to send the coins to their address to prevent you from spending them after the deadline. But it could be useful in some cases like a purchase where you want the purchase to become final but have a deadline after which you can cancel it. It also solves the problem regarding the need for proof of funds.

Code:

OP_IF
  <receiver's public key> 
OP_ELSE
  <1 hour>OP_CHECKLOCKTIMEVERIFY OP_DROP <your public key>
OP_ENDIF
OP_CHECKSIG

[jackg]

So it is possible could this be implemented  into a hardware wallet

Also, I would like to see a white the recipient could see there is going to be an incoming amount. Also a time delay. He can also see that as well.

What purpose would this have? You could send them a copy of the transaction once it's signed, that'd be safe and secure (if it's timelocked then they won't be able to broadcast it until that time has passed)..

As said above, trezor and ledger so work with electrum, it's likely other hardware wallets are able to do similar too - it's not a very advanced feature.

[ben19850]

So it is possible could this be implemented  into a hardware wallet

Also, I would like to see a white the recipient could see there is going to be an incoming amount. Also a time delay. He can also see that as well.

What purpose would this have? You could send them a copy of the transaction once it's signed, that'd be safe and secure (if it's timelocked then they won't be able to broadcast it until that time has passed)..

As said above, trezor and ledger so work with electrum, it's likely other hardware wallets are able to do similar too - it's not a very advanced feature.

Yes, obviously I would do several test transactions first, but it comes to sending the $100 million chunk the transaction is still an  individual transaction.Therefore there is always the chance of human error. Once the bitcoin is sent. It is gone if there was a time delay more so away to cancel the transaction. Would mean if there was human error, the funds will not be lost in limbo.

[jackg]

Yes, obviously I would do several test transactions first, but it comes to sending the $100 million chunk the transaction is still an  individual transaction.Therefore there is always the chance of human error. Once the bitcoin is sent. It is gone if there was a time delay more so away to cancel the transaction. Would mean if there was human error, the funds will not be lost in limbo.

No you don't need to do test transactions in this case you could just edit the time your transaction can confirm, sign it and then send the signed transaction to the other person/wallet and get it imported there so they can verify the funds credit that wallet before they're sent - either of you can broadcast that unsigned transaction too once the time it was signed for has passed.

[garlonicon]

Just use "locktime" field in your transaction. Sign it, and send to your recipient. Then, if everything is correct, the recipient could broadcast it later, when this locktime will pass. And if you notice that something is wrong, you can write a double spend without any locktime, and get it confirmed in the next block, just by using a higher fee.

[BlackHatCoiner]

Wouldn’t a way to cancel the transaction be safer?

Yes, for you, but less safe for the other guy. I wouldn't make a $100 million dollars worth of transaction peer-to-peer, unless I had billions. But that's what bitcoin is. Peer-to-peer cash. If it doesn't fit your need, either don't use it, or use it with the presence of a third-party.

Just use "locktime" field in your transaction. Sign it, and send to your recipient. Then, if everything is correct, the recipient could broadcast it later, when this locktime will pass. And if you notice that something is wrong, you can write a double spend without any locktime, and get it confirmed in the next block, just by using a higher fee.

The bribe can be good enough to even convince him reverse a block, though. The sender must be cautious when setting the locktime.

[garlonicon]

The bribe can be good enough to even convince him reverse a block, though. The sender must be cautious when setting the locktime.

For that reason, it is needed to wait for more than one confirmation. Imagine a pizza transaction for 10k BTC, when the block reward was 50 BTC. This case is similar, just amounts are different, and hashrate changed, but still, the math behind it is the same: you can accept a transaction, when the cost of reorg is higher than the amount of coins sent.

[Lida93]

Say you wanted to buy a $100 million house with BTC
apart from doing teat transactions to the RECIPIENTS ADDRESS there’s no way of stopping a transaction

I know you can copy paste a wallet address and check over the charters of the ADDRESS but…

Wouldn’t a way to cancel the transaction be safer?? Say 1 hour delay the recipient to see there’s a incoming transaction then the sender allows it to clear(if the recipient dosnt confirm he’s sees it’s going to post the sender cancels it BTC stays in there wallet)

If I were you just to save myself from some stress I'll do well to give a trial with the address sending  a very insignificant amount that wouldn't mean a thing to me, just to test if it's the correct address instead of going through those steps you're employing. It's just a thing of common sense.

[o_e_l_e_o]

A test transaction only confirms that the seller has sent you the correct address (provided they confirm they received your test transaction). It does not confirm that your main transaction is correct. It is entirely possible to make a test transaction to the correct address, and then still copy the wrong address for your main transaction, or send the wrong amount of coins, or have clipboard malware change the address, or whatever.

A better solution would be a transaction which is timelocked far enough in the future, say a couple of days at least. Send that to the other party and have them confirm that their receiving address is correct. If it is, great - broadcast it in a few days. If it isn't, you can invalidate it and have your invalidation transaction several hundred blocks deep before the timelock expires.

Even better - include a small input of a few thousand sats in your original transaction, so you can invalidate it simply be moving this small input while leaving your input of tens of thousands of bitcoin alone.