Nice, thanks for pointing me in the right direction!
Josh
Topic: How does the network resolve conflicting transactions? (Read 780 times)
Basically, only one of the conflicting transactions can be included in a block. If a miner sees more than one of the transactions before one is included in a block, he could theoretically select which one he wants to try including in the block he is attempting to make (in practice, they select the one they saw first). Once a block is produced, everyone else will consider that transaction to be the only true transaction. If more than one block is produced at the same time, a similar process happens: the next block after that decides which block was the true block. This process continues infinitely, eventually causing everyone to come to a consensus about the history of transactions.
You might find it helpful to read satoshi's explanation when someone asked him this same question (it's somewhere in this thread):
http://www.mail-archive.com/[email protected]/msg09975.html
You might find it helpful to read satoshi's explanation when someone asked him this same question (it's somewhere in this thread):
http://www.mail-archive.com/[email protected]/msg09975.html
I'm curious, how does the Bitcoin network resolve conflicting transactions? I looked for this in a FAQ, but couldn't find details on exactly how the network chooses which of two choices to believe, when given conflicting choices.
This could either be done intentionally (flooding others in an effort to induce lag, hacking the Bitcoin client to disable consistency checks, generating false confirmations, intentional double-spending, connecting a large network of your hacked Bitcoin clients in an effort to steal traffic from the existing network, any other ways) or accidentally (connecting to the Test network instead of the real network, running offline for a while then reconnecting later).
Which determines the winner? How does the network know to discard unwanted transactions, provided that those unwanted transactions are not totaling enough to constitute a 51% attack?
It makes sense that Bitcoin would still be vulnerable to a 51% attack. A corporation is vulnerable (convince 51% of shareholders to vote your way, or just buy 51% of all shares, and you can appoint yourself CEO and do whatever you want), and a democratic government is vulnerable (convince 51% of voters to vote for you, and you are President). Evidently that's pretty much how the world works, nothing can really be done about that
Josh
This could either be done intentionally (flooding others in an effort to induce lag, hacking the Bitcoin client to disable consistency checks, generating false confirmations, intentional double-spending, connecting a large network of your hacked Bitcoin clients in an effort to steal traffic from the existing network, any other ways) or accidentally (connecting to the Test network instead of the real network, running offline for a while then reconnecting later).
Which determines the winner? How does the network know to discard unwanted transactions, provided that those unwanted transactions are not totaling enough to constitute a 51% attack?
It makes sense that Bitcoin would still be vulnerable to a 51% attack. A corporation is vulnerable (convince 51% of shareholders to vote your way, or just buy 51% of all shares, and you can appoint yourself CEO and do whatever you want), and a democratic government is vulnerable (convince 51% of voters to vote for you, and you are President). Evidently that's pretty much how the world works, nothing can really be done about that
Josh
Jump to: