Rescind a Transaction?

[fatigue]

So i do understand the basic principle of seeing that a transaction has been confirmed in the blockchain, however there is definitely a stigma against unconfirmed transactions. My question is, is it even possible for someone to 'take back' an unconfirmed transaction? At the point that it has left your wallet, is it not technically in the recieving wallet until confirmed (just floating around waiting for a confirmation)?

An example is that a transaction to satoshidice can be sent and reward recieved without any confirmations, thats a mindfuck to me.

[phathash]

Electronic information cannot self-destruct. It can also be easily be duplicated. If the tx has been broadcast with an appropriate fee, and subsequently heard, it is inevitable it will reach the blockchain. The Bitcoin client is quite aggressive at re-broadcasting to other peers. The cat is out of the bag.

If the recipient is well-connected to the network, they might with some degree of confidence accept a 0-confirmed tx if they have heard no double-spends.

If 'thin' clients started to heavily rely a few exit nodes, and peer numbers dwindled, it might be possible to conspire with large pools to somehow repeal a tx before it was broadcast. However, we'd have bigger problems if this were the case.

Irrevocable transactions is alien to to some people. As is the concept of complete and total responsibility for the storage of one's own store of value (wallet). This is probably the price of a distributed crypto-currency. There is no one to point the finger at.

[fatigue]

Electronic information cannot self-destruct. It can also be easily be duplicated. If the tx has been broadcast with an appropriate fee, and subsequently heard, it is inevitable it will reach the blockchain. The Bitcoin client is quite aggressive at re-broadcasting to other peers. The cat is out of the bag.

If the recipient is well-connected to the network, they might with some degree of confidence accept a 0-confirmed tx if they have heard no double-spends.

If 'thin' clients started to heavily rely a few exit nodes, and peer numbers dwindled, it might be possible to conspire with large pools to somehow repeal a tx before it was broadcast. However, we'd have bigger problems if this were the case.

Irrevocable transactions is alien to to some people. As is the concept of complete and total responsibility for the storage of one's own store of value (wallet). This is probably the price of a distributed crypto-currency. There is no one to point the finger at.

Just the answer i was looking for. Essentially a 51% is needed for both double sending and repealing in the same. All is good,  the world makes sense once again.

[Stephen Gornick]

Just the answer i was looking for. Essentially a 51% is needed for both double sending and repealing in the same. All is good,  the world makes sense once again.

I think there is some mis-communication there.

Here's an article describing various double spending methods:
 - http://en.bitcoin.it/wiki/Double-spending

One thing that isn't always clear immediately is that there really is no such thing as bitcoins being received by your wallet.  Bitcoins are broadcast to nodes.  Your wallet is really only used for spending, not receiving.  The bitcoin client was built to emulate the real-world concept of receiving money but underneath that's not how it works.

So the concept of "rescinding" that you mentioned doesn't exist. 

[Foxpup]

51% is not needed to do a double-spend. All you have to do is send one transaction, then send another transaction to a different address using the same inputs (the standard client does not allow you to do this, but it is possible with a modified client). Only one of the two transactions can possibly be accepted as valid, and once one of those transactions is confirmed, the other one is invalid and will never be confirmed, and anyone who was counting on that transaction being valid is out of luck. This is why you should always wait for transactions to be confirmed before assuming the money is yours. A 51% attack is only required to take back transactions which have actually been confirmed.

Satoshi Dice uses a neat trick to avoid the problem of double-spending: it sends back the coins you originally sent as part of the payout. Since it is not possible to invalidate only part of a transaction, if your original bet is later invalidated due to it being a double-spend, your whole payout is also invalidated.

[fatigue]

So the concept of "rescinding" that you mentioned doesn't exist. 

You were right, there was some misunderstanding, but that clears it right up.
 

51% is not needed to do a double-spend. All you have to do is send one transaction, then send another transaction to a different address using the same inputs (the standard client does not allow you to do this, but it is possible with a modified client). Only one of the two transactions can possibly be accepted as valid, and once one of those transactions is confirmed, the other one is invalid and will never be confirmed, and anyone who was counting on that transaction being valid is out of luck. This is why you should always wait for transactions to be confirmed before assuming the money is yours. A 51% attack is only required to take back transactions which have actually been confirmed.

Satoshi Dice uses a neat trick to avoid the problem of double-spending: it sends back the coins you originally sent as part of the payout. Since it is not possible to invalidate only part of a transaction, if your original bet is later invalidated due to it being a double-spend, your whole payout is also invalidated.

Very helpful information, but it brings another question to mind. Would it be possible for the 'cheater' (for lack of a better term) to choose which transaction got confirmed after the result of satoshidice was shown? I'm sure its either impossible or already figured in somehow, but it would create major issues if not.

[Berlu]

Would it be possible for the 'cheater' (for lack of a better term) to choose which transaction got confirmed after the result of satoshidice was shown?

Yes. Normally Satoshi Dice sends back its results a few seconds after you placed your bet. If it was a loss just try to get your double-spent transaction confirmed before your bet becomes confirmed.

[aq]

Would it be possible for the 'cheater' (for lack of a better term) to choose which transaction got confirmed after the result of satoshidice was shown?

Yes. Normally Satoshi Dice sends back its results a few seconds after you placed your bet. If it was a loss just try to get your double-spent transaction confirmed before your bet becomes confirmed.

Just use no tx fee on the bet, and some huge fee when you double spend the coins to yourself.
To reinforce this scheme, tell the miners they can make hundreds of BTC from this - I am sure some will prefer your huge fee txs over the free once ;-)

[Stephen Gornick]

Very helpful information, but it brings another question to mind. Would it be possible for the 'cheater' (for lack of a better term) to choose which transaction got confirmed after the result of satoshidice was shown? I'm sure its either impossible or already figured in somehow, but it would create major issues if not.

When your node sends out a transaction it broadcasts it to nodes it is connected to, and they broadcast it to nodes they are connected to, etc.  The nodes take the first valid transaction in which a coin was used and ignore any others.  Miners will, within seconds, have the first transaction and that will eventually make it into a block.

So yes, if you happen to be mining you can broadcast to the network one transaction and then include in your own mining block a double spend to yourself for each of other transactions in that same block that you wish to see vaporized.  

[fatigue]

Very helpful information, but it brings another question to mind. Would it be possible for the 'cheater' (for lack of a better term) to choose which transaction got confirmed after the result of satoshidice was shown? I'm sure its either impossible or already figured in somehow, but it would create major issues if not.

When your node sends out a transaction it broadcasts it to nodes it is connected to, and they broadcast it to nodes they are connected to, etc.  The nodes take the first valid transaction in which a coin was used and ignore any others.  Miners will, within seconds, have the first transaction and that will eventually make it into a block.

So yes, if you happen to be mining you can broadcast to the network one transaction and then include in your own mining block a double spend to yourself for each of other transactions in that same block that you wish to see vaporized.  

So... How is this preventable? It seems to me like quite the large issue...

[theymos]

The network gradually forgets about 0-confirmation transactions if no one is rebroadcasting them, so it's possible to cancel a 0-confirmation transaction if it doesn't make it into a block for several days. The client doesn't support this yet, though -- it rebroadcasts forever.

So... How is this preventable? It seems to me like quite the large issue...

Wait for a few confirmations.

[fatigue]

The network gradually forgets about 0-confirmation transactions if no one is rebroadcasting them, so it's possible to cancel a 0-confirmation transaction if it doesn't make it into a block for several days. The client doesn't support this yet, though -- it rebroadcasts forever.

So... How is this preventable? It seems to me like quite the large issue...

Wait for a few confirmations.

I see. This still doesn't solve the issue of someone choosing which bet to confirm on a gambling site such as satoshidice. The only issue I can see is that it would potentially take solving a block or two before being able to do anything.