What happens to transactions in invalid blocks?

[aral]

If I make a transaction, could it end up in an invalid block?  If that happens presumably the balance on the sending address would stay the same.  I see some invalid blocks occasionally on the mining pool stats.. just wondering how it works and how often this happens.  Has it happened to you? Sorry if this is a dumb noob question but I searched and couldn't find any discussion about it.  It would be pretty annoying if your transaction just failed through no fault of your own after a few hours and you had to resend.  If you were designing some an automated system for a merchant this would have to be taken into account, correct?

[Garrett Burgwardt]

Transactions in invalid blocks are simply unconfirmed again. If the block that contained them was reversed, then they are unconfirmed completely.

They get included eventually. Don't worry.

[bcearl]

They get included eventually. Don't worry.

"Eventually" would mean a security flaw. If it is not included, the money sender can never be sure whether someday somebody will use the transaction he signed to take money.

[willphase]

A transaction will only ever appear in one valid block so it will only ever happen once. This is exactly what the sender wanted when he made the transaction. It's like writing a check but the recipient doesn't cash it out immediately. This is not a security flaw in the check system as long as the recipient can only cash it out once.

I've never seen a transaction take more than a day to verify, even when I've put a 0 fee on it.

Will

[bcearl]

A transaction will only ever appear in one valid block so it will only ever happen once. This is exactly what the sender wanted when he made the transaction. It's like writing a check but the recipient doesn't cash it out immediately. This is not a security flaw in the check system as long as the recipient can only cash it out once.

I've never seen a transaction take more than a day to verify, even when I've put a 0 fee on it.

Will

But consider the following attack:

1. A draws a transaction X to B, this means there is a transaction signed with A's private key.
2. The transaction does not get included for a long time.
3. A draws a new transaction Y to B, which gets included.
4. Now, B can use X to steal money from A.

[willphase]

Alice sends cash to Bob and the letter gets delayed in the mail and doesn't arrive at Bob's.

Alice writes another letter to Bob with more cash and Bob takes it. First letter then arrives (the mailman finds it in his van) and Bob takes it to.

Bitcoins are like cash. In this case Alice should have probably never sent the second letter, our Bob could send the second lot of cash back. This is not an issue with the cash system.

Will

[bcearl]

Alice sends cash to Bob and the letter gets delayed in the mail and doesn't arrive at Bob's.

Alice writes another letter to Bob with more cash and Bob takes it. First letter then arrives (the mailman finds it in his van) and Bob takes it to.

Bitcoins are like cash. In this case Alice should have probably never sent the second letter, our Bob could send the second lot of cash back. This is not an issue with the cash system.

Will

Yes, you should never send cash via mail. But that doesn't happen with the usual use of cash: face to face.

[drknark]

But if, hypothetically, for whatever reason a transaction never gets included in a block? What happens? Since the transaction is never confirmed, doesn't the sender still own the money? Or is it lost forever?

Possible case for this to happen would be an unofficial client allowing users to send large transactions without fees, that the official client requires fees for?

[willphase]

But if, hypothetically, for whatever reason a transaction never gets included in a block? What happens? Since the transaction is never confirmed, doesn't the sender still own the money? Or is it lost forever?

Possible case for this to happen would be an unofficial client allowing users to send large transactions without fees, that the official client requires fees for?

The transaction would remain unconfirmed/0 on the sender's client, but the money is not still owned by the sender since it might still be included in a block some time in the future. In theory you could patch your client to reclaim these transactions by simply assuming it never happened.

An easy way to do this now would be to export all your keys (using bitcointools) and then import them into a new wallet then start bitcoin with the -rescan option. This would reclaim the bitcoins but if the transaction ever got included later on them they would just disappear, so if you e.g. transfer your entire balance to a new account then the old transaction would never be included as it would be seen as a double spend...

This is why you need to wait for confirmations before accepting bitcoins

Will

[drknark]

Ok, thank you for the clarification!

[Desu]

Similar noobish question; I've noticed after like 6 confirmations, it doesn't say unconfirmed anymore, Is it always going to be that way?

[imperi]

Similar noobish question; I've noticed after like 6 confirmations, it doesn't say unconfirmed anymore, Is it always going to be that way?

....................

[willphase]

Similar noobish question; I've noticed after like 6 confirmations, it doesn't say unconfirmed anymore, Is it always going to be that way?

....................

QFT

[Desu]

Similar noobish question; I've noticed after like 6 confirmations, it doesn't say unconfirmed anymore, Is it always going to be that way?

....................

QFT

I didn't deny noob-ish-ness. I'm very new to bitcoin, chill, okay?

[willphase]

Similar noobish question; I've noticed after like 6 confirmations, it doesn't say unconfirmed anymore, Is it always going to be that way?

are you asking whether the client will always use 6 as the threshold at which it tells the user that the transaction is confirmed, or asking whether a confirmed transaction can ever become unconfirmed?

Will

[Desu]

Similar noobish question; I've noticed after like 6 confirmations, it doesn't say unconfirmed anymore, Is it always going to be that way?

are you asking whether the client will always use 6 as the threshold at which it tells the user that the transaction is confirmed, or asking whether a confirmed transaction can ever become unconfirmed?

Will

Asking if Six is the set number...

[willphase]

Read section 11 of the bitcoin paper. Basically as number of blocks chained to the block containing your transaction increases, the chances if an attacker who is able to control a set portion of the bitcoin network being able to double spend the transaction reduces exponentially. Assuming an attacker e.g. a large pool, controls 30% of the network, it takes 24 confirmations to ensure less than a 0.1% chance of a successful attack. The exact numbers are in the paper.

6 seems like a reasonable number. Some merchants accept fewer e.g. 3 for small transactions. If you were buying a car with bitcoins, I would probably like to see at least 30.

If one pool ends up controlling a large part of the mining for the bitcoin network in the future, I wouldn't be surprised if the default number in the client is raised to reflect the additional risk.

Will

[Desu]

Read section 11 of the bitcoin paper. Basically as number of blocks chained to the block containing your transaction increases, the chances if an attacker who is able to control a set portion of the bitcoin network being able to double spend the transaction reduces exponentially. Assuming an attacker e.g. a large pool, controls 30% of the network, it takes 24 confirmations to ensure less than a 0.1% chance of a successful attack. The exact numbers are in the paper.

6 seems like a reasonable number. Some merchants accept fewer e.g. 3 for small transactions. If you were buying a car with bitcoins, I would probably like to see at least 30.

If one pool ends up controlling a large part of the mining for the bitcoin network in the future, I wouldn't be surprised if the default number in the client is raised to reflect the additional risk.

Will

Thank you for explaining that to me