Topic: Question about double spend? (Read 1056 times)

Thanks, great answer as always Danny.

We really see that the people who invented and engineered bitcoin were geniuses, they thought about all possibilities and vulnerabilities.

I`ll just unsub from this and leave this thread open for others to see so that everyone with concerns in the future can find the answers here!

Not exactly.

It is impossible to know exactly how much mining power is behind any chain or block.  All we can know is what difficulty the protocol tells us to expect from the next block, and which block we first hear about that accomplished the proof-of-work at that difficulty.

So the "longest" chain is the chain that has the highest total expected difficulty.  Under normal operation, this will always be the chain with the most blocks, since the entire network is all using the same protocol and seeing the same blockchain.

However, it could theoretically be possible from someone with a significant amount of hash power to go back and recreate a significant portion of the blockchain. By carefully choosing when and how to add or remove hash power they might be able to create a chain that has more blocks but required less proof-of-work (less total difficulty).  Their chain would be rejected by everyone on the network even though it has more blocks, because the total difficulty of all the blocks is less.

If this attacker has more hash power than the combined rest of the entire world, then he could work on blocks that have the same difficulty as the current "real" blockchain.  His increased hash power would allow him on average to solve more blocks in any given time at the same difficulty as the rest of the network.  His chain would then be longer (have more blocks) and when the difficulty adjustment happens, his chain would also have a higher difficulty.  As such, if he were to broadcast this longer chain (with higher total difficulty), his chain would replace the current chain and his chain would become the new "real" chain.

Note that the network doesn't know how much hash power he has.  It only knows what the difficulty of the proof-of-work was, and how many blocks there are.  The concept of "proof-of-work" simply assumes that more blocks at a given (or higher) difficulty implies more hash power.  It's also possible to simply get lucky and solve a few blocks faster than your hash power on average should. As long as your hash meets the proof-of-work difficulty, the other nodes on the network don't really care how you got there.


Nope.  The assumption is that the fork that is most likely to find the next block will be the one that has the most hash power behind it, but that isn't guaranteed.  The nodes on the network will accept any valid block that meets the current difficulty and adds to the total difficulty of the blockchain regardless of how much hash power was used to solve that block.

As an example... If I give you 15 six-sided dice to roll once every second, and I just roll 2 dice once every second.  Who is most likely to roll 2 ones in the same roll, you or I?  It should be pretty easy to see that with the added dice-power (hashpower) you are far more likely to succeed first.  However, I could get 2 ones on my first roll, and it could take you a few rolls before you succeed.  So, either of us could "win", but you are far more likely to "win".  That's how the blockchain mining works.  The largest portion of the global hashpower is the most likely to solve the next block, but anyone with any amount of hash power still could.


That depends on how well coordinated those 90% are and whether they are willing to force TX2 out after it has confirmed.

Lets start by assuming that when you say 90% of the miners, what you really mean is 90% of the global hash power.

In normal operation, the 90% of the hashpower has a 90% chance of finding the next block, and the 10% of the hashpower only has a 10% chance of finding the next block.  If the 10% gets very lucky and finds their next valid block before the 90%, then the 90% will switch over to the same blockchain as the 10% were previously on, and now 100% of the network will be working on continuing to extend the blockchain that has TX2 in it.  TX1 will be rejected as invalid.

If the 90% all decided that they didn't want TX2 to happen, and if they could coordinate well enough without anyone secretly switching sides, then they could changing their programming to just ignore the lucky block that the 10% accepted. They would be ignoring the "longer" chain for now.  They would have a 90% chance of finding a block of their own and catching back up to the 10% in total blockchain length.  If they succeed in finding a block before the 10% found a second block, then they would have a 90% chance of finding an additional block before the 10% found their additional block.  And if they succeeded in doing that, then they would have the longer blockchain, and the 10% would switch over to the same blockchain as the 90% had been enforcing. Then 100% of the network will be working on continuing to extend the blockchain that has TX1 in it.  TX2 will be rejected as invalid.

If the 90% all decided that they didn't want TX2 to happen, AND if the 10% ALSO decided that they didn't want TX1 to happen, and if both sides could coordinate well enough, then they could all change their programming to just ignore any blockchain that included the transaction they didn't like.  This would result in a permanent fork in the blockchain with each side claiming to be the "real" bitcoin and claiming that the "other side" was just an altcoin that should be ignored.  Whenever you wanted to send bitcoins to someone you'd have to first make sure that you were both using the same fork.  There'd be a lot of confusion about which of the forks is which, and the resulting chaos could possibly result in people abandoning both forks to find something less confusing.  This split blockchain scenario is true of any change to any of the consensus rules without near unanimous support, and is why it is VERY difficult to change something like block size without the overwhelming support of nearly ALL users.


It really depends on what the users want.  If 90% of the users want TX2 to win, then they will all use the software and blockchain that accepts TX2.  They will all call it "Bitcoin" and they will all call that other fork something else.  Regardless of how many miners and hash power support it, there are FAR more users than miners.  If the users want to use something and call it Bitcoin, there isn't any process for stopping them from doing so.  Those TX1 miners might want to call their system Bitcoin, but the world would simply ignore them.

There would be a permanent fork, and both sides of the fork would try to claim that their side is the "real" Bitcoin.  If the users are split on how they feel about it, then there would be a LOT of confusion and chaos as each side tried to convince the world that the other side was wrong.

Thanks for very detailed answer, now it's more clear.

Also the "length" as I was told actually means the chain with the most mining capacity behind it not the one that is "long" as in lenght.

So its not like knightdk said in the previous post, that the miner that mines the block will decide the chain, but the miners with the most mining capacity behind it.

So if 90% of the miners are behind TX1 but only 10% are behind TX2, then TX1 will be the real one and TX2 will drop out eventually?

So if the TX2 miners are dishonest and persist in mining TX2 then they will be mining an altcoin right? Because the consensus enforces them to adhere to the majority mining capacity's rule. Is that true?

Ok, so far, so good.

Alice has broadcast two competing transactions onto the peer-to-peer network.

Some peers received TX1.  Most of those peers will refuse to accept TX2, and will refuse to relay it. So, until they see a confirmation, they will simply assume that TX1 is the "valid" unconfirmed transaction.

Some peers received TX2.  Most of those peers will refuse to accept TX1, and will refuse to relay it. So, until they see a confirmation, they will simply assume that TX2 is the "valid" unconfirmed transaction.


Not in the same blockchain they don't.  That's not possible since it violates the consensus rules.  Therefore, I must assume that you are talking about 2 different blockchains.  Let's look at how that can happen.

Miner Edward received TX2 before he received TX1. Therefore, he included TX2 in the block that he was working on (we'll call his block Block_Ed) and he completely ignored TX1.

Miner Frank was also working on a block (we'll call his block Block_Fr), but he decided not to include either of the transactions in his block.

Edward and Frank both solve their blocks at almost the exact same time.  They both transmit their blocks to their peers. Some nodes and miners receive Block_Ed first, so they completely ignore Block_Fr and refuse to add it to their chain.  Other nodes and miners receive Block_Fr first, so they completely ignore Block_Ed and refuse to add it to their chain.

There is now a temporarily forked blockchain.  Some percentage of the network has the blockchain that includes Block_Ed. They see 1 confirmation for TX2, and they reject TX1 as invalid. The rest of the network has the blockchain that includes Block_Fr. They see no confirmations at all for TX2 or TX1. Some of them received TX2 first, and others received TX1 first.  Each node thinks that it has the valid blockchain, and the miners work on extending the chain they think is valid.

Lets say miner George is building on top of Block_Ed.  Since George received Block_Ed first, he sees that TX2 has 1 confirmation and that TX1 is rejected because it is invalid. We'll call George's block Block_Geo.

Meanwhile, miner Henry is building on top of Block_Fr.  Miner Henry received TX1 before he received TX2, so he thinks that TX1 is an unconfirmed valid transaction, and he has rejected TX2 (he also rejected Block_Ed, since he received Block_Fr first). We'll call Henry's block Block_Hen.

George and Henry both solve their blocks at almost the exact same time.  They both transmit their blocks to their peers.  Some nodes and miners receive Block_Geo first, so they reject Block_Fr and Block_Hen and refuse to include either of them in their blockchains. Other nodes and miners receive Block_Hen first, so they reject Block_Ed and Block_Geo and refuse to include either of them in their blockchains.

There is now still a temporarily forked blockchain.  Some percentage of the network has the blockchain that includes Block_Ed and Block_Geo They see 2 confirmations for TX2, and they have rejected TX1 because it is invalid.  The rest of the network has the blockchain that includes Block_Fr and Block_Hen. They see 1 confirmation for TX1 and they have rejected TX2 because it is invalid.

This temporary fork will continue until a block is solved by a miner on one of the two chains while a competing block is not solved on the other chain at nearly the same time.  That miner will broadcast his block and the entire network will switch over to the then longer chain.  Typically, splits like this don't last more than a block or two, but in an extreme case it *might* be possible for it to last a few blocks.  This is why *some* people like to wait for 6 confirmations.  That gives the network enough time to sort out which of the two forks will become the longest.

If the chain with Block_Ed and Block_Geo ever becomes the longest chain, then TX2 will be valid and confirmed. TX1, Block_Fr, and Block_Hen will all simply cease to exist in the blokchcain.

if the chain with Block_Fr and Block_Hen ever becomes the longest chain, then TX1 will be valid and confirmed.  TX2, Block_Ed, and Block_Geo will all simply cease to exist in the blockchain.


The odds of this occurring are pretty slim.  It would require that:

Bob receives TX1 from a peer before he receives TX2 from a peer AND that Jimmy receives TX1 from a peer before he receives TX2 from a peer AND that Jimmy receives TX3 from a peer before he receives TX4 from a peer AND that Charlie receives TX2 from a peer before he receives TX1 from a peer AND that David receives TX2 from a peer before he receives TX1 from a peer AND that David receives TX4 from a peer before he receives TX3 from a peer.

Additionally, if Bob or Jimmy receives Block_Fr before they receive Block_Ed or Block_Hen before they receive Block_Geo, then they will no longer see TX1 or TX3, and Jimmy will not think he was paid. If Charlie or David receives Block_Ed before they receive Block_Fr or Block_Geo before they receive Block_Hen, then they will no longer see TX2 or TX4, and David will not think he was paid.


This would require the extremely unlikely event that the blockchain remain forked with at least two chains of equal length for at least 8 blocks. Furthermore, since you already said that TX2 has 1 more confirmation than TX1, TX1 should have 7 confirmations.  Perhaps there was a third block that competed with Block_Geo and Block_Hen?  It would have to be a block that built on top of Block_Fr and still didn't confirm either of the two transactions.


Wait, I think I missed something (or got some transactions mixed up here)?  It is not possible for TX3 (which spent TX1) to have MORE confirmations than TX1.  Since TX3 spends TX1, it will not be allowed in a block if TX1 is not in a block yet.

I suppose you could (theoretically) have a 3 way fork like this:


In that case:
TX1 would have in fork C the 2 confirmations you mention (but would have 8 confirmations in fork B, and wouldn't exist in fork A).
TX2 would have in fork A the 8 confirmations you mention (but wouldn't exist in fork B or fork C).
TX3 would have in fork B the 7 confirmations you mention (but wouldn't exist in fork A or fork C).
TX4 would have in fork A the 1 confirmation you mention (but wouldn't exist in fork B or fork C).

Each node and miner on the network would only accept one of these forks as the valid fork and would reject the others.  Eventually Block10 would be solved by a miner somewhere on the network.  Which ever fork that miner was using as his valid fork would then become the longest and the other forks would simply cease to exist.  The entire network would consolidate on that fork that included Block10.  The odds of a three way split lasting 9 blocks like that are astonomically small unless someone had control over more than 66% of the global hashpower and used it to intentionally maintain the 2 additional forks.


Nope.  That's not how it works.

So long as the blockchain remains forked, there is no "real one" and the confirmations within the forks are meaningless. Eventually one fork becomes the longest.  Then all the other forks disappear and the confirmations in the one remaining fork become the "real" confirmations.


Whichever chain becomes longer.


One. As long as the blockchain isn't forked.  If it is forked, then the doublespend will be cut off as soon as all remaining forks contain only 1 of the two competing transactions


Never in the same fork.


You don't. I have never yet felt a need to wait more than 1 confirmation before considering any transaction that I've ever received to be "safe".

Some people choose to wait additional confirmations because they are concerned that there could be a fork that they are unaware of.


Correct.  As long as the blockchain isn't forked, then 1 confirmation is enough.


Each miner considers the transaction that they saw first to be the valid one until they see one of the transactions in a block.  Once they one of the transactions in a block, then they consider whatever block they see first to be valid.  If there is a fork, then they see the chain that contains the next block they receive to be the valid chain. This continues until the blockchain is no longer forked and the remaining chain is the valid one.


They cannot both be accepted into the same block.  That would create an invalid block which the entire network would reject.  Each miner chooses the transaction that they see first.  Then when one of them solves a block, the transaction in that block becomes the valid transaction.  If two of them solve blocks at almost the exact same time and they were each using a different competing transaction then the process continues with each miner building on top of the block that they receive first until one chain is longer than all the rest.


Timestamps are not considered.  Each miner simply pays attention to the first transaction (or block) that they receive with there are competing transactions (or blocks).

Both transactions are valid. The one that gets confirmed first is determined by the miner who produces the next block first and whether that miner saw TX1 or TX2 first.


The timestamps don't matter. The clocks don't matter. It is literally decided by the order in which the transactions were received. If TX1 comes in immediately after TX2, the miner will reject TX1.

Well which miner because its not only 1 miner but many. So if miner A sees TX1 first but miner B sees TX2 first, then how they decide which one is valid?




I see,but if all miners and nodes are honest, and the transaction both get accepted at the same time, how are they decided which ones is valid?

If they are timestamped, then what if the clock of the nodes and the miners is not in synch, then what?

It depends on the miner that makes the block. If the miner sees TX1 first, it will reject TX2 and include TX1. If it sees TX2 first, it will reject TX1 and include that into a block.

Usually 1 confirmation is fine. The risk is that if there is a double spend attempt, TX1 could in theory be in a block that gets orphaned by another block and its child that contains TX2. The 6 confirmations really only applied back when the hash power was low and a 51% attack which could do this double spending was possible. It becomes exponentially harder to orphan chains of blocks as they grow.

Ok but which one will be included first TX1 or TX2?

Also if what you say is true then why do you need to wait 6 confirms, because if only 1 chain can be included then it would be enough for 1 confirmation to happen?

It is IMPOSSIBLE for two transactions which spend the same input(s) to be included in the blockchain. This is simply impossible and this is one of the things that Satoshi specifically designed the blockchain to prevent. Any blocks that include any transactions that conflict with any other transaction in the blockchain will be considered invalid.

Have you read this?

https://bitcoin.org/bitcoin.pdf

I was wondering about the following scenario.

- Alice sends 1 BTC to Bob  named TX1
- Alice double spends the 1 BTC and sends it to Charlie named TX2

- Both of them get confirmation at roughly the same rate.
- TX1 has 1 confirm TX2 has 2 confirm

-Bob sends the 1 BTC to Jimmy as TX3
-Charlie sends the 1 BTC to David as TX4

-TX3 gets 7 confirms
-TX4 gets only 1 confirm

However by this time TX2 will have 8 confirm while TX1 will have only 2

So

TX1-> TX3         (chain1)
2c        7c

and

TX2  -> TX4         (chain2)
8c            1c

This is a big dilema, as the one with the more confirms should be inside the blockchain as the real transaction, but on 1st degree you think TX2 will be the real one, but by the time TX2 gets 8 confirms to supercede TX1 , the 1st chain will have 7 confirms on the 2nd degree.

So which one will be the real chain 1 or 2?

Also how many confirmations are needed for a transaction for it's double spend counterpart transaction to be cutoff from the blockchain? Or do they both get included?