Bitcoin - Open Source - Questions!

[Kromos]

Hi fellows,
I have some questions which I have looked for but didn't find a clear answer. Could you please help me?

1 - The Bitcoin Core, beeing an open source software where people can contribute and make changes, isn't it and issue? I would like to know how the changes are made on the code? Anyone can access and make changes? Is necessary any approval? If yes, from who?

2 - Is it possible to change the maximum supply of coins? For instance, instead of 21 million coins, from now on the community decides to supply the system with 42 millions. Is it possible?

3 - Why do miners charge for verifying the transactions? Once they receive new bitcoins for each block that is mined, why is it necessary to charge?

I think that is it for while.
I appreciate your support, thank you!

[1714649006]

1714649006

[achow101]

1 - The Bitcoin Core, beeing an open source software where people can contribute and make changes, isn't it and issue? I would like to know how the changes are made on the code? Anyone can access and make changes? Is necessary any approval? If yes, from who?

Bitcoin Core is developed on github here: https://github.com/bitcoin/bitcoin. If you want to contribute, you make a fork of the repository (which goes to your account), make your changes, and then open a Pull Request on Bitcoin Core's repo. Then other Core contributors review your code and indicate whether they support the change or not. If a lot of the reviewers think the change is something that they want in Core, the maintainers of the repo will merge the change and it will be a part of Bitcoin Core.

2 - Is it possible to change the maximum supply of coins? For instance, instead of 21 million coins, from now on the community decides to supply the system with 42 millions. Is it possible?

Yes, but it requires a hard fork. It would require every single person running a Bitcoin node to update their software to accept that new rule.

3 - Why do miners charge for verifying the transactions? Once they receive new bitcoins for each block that is mined, why is it necessary to charge?

Because the block subsidy will go to 0 over time (and it decreases very quickly). Transaction fees are to pay miners so that they keep mining in the future as the block subsidy goes to 0. Otherwise there would be no incentive to mine blocks.

[Kromos]

Thank you achow101

4. Is there an issue for using the same wallet address for many transactions? Talking about being investigated or followed by a governmental agency? How traceable a transaction is? How vulnerable is it?

Thanks!

[achow101]

4. Is there an issue for using the same wallet address for many transactions? Talking about being investigated or followed by a governmental agency? How traceable a transaction is? How vulnerable is it?

Yes. Using the same address will result in less privacy and potentially less security. People who send you money will know how much money you actually have. People can then also see who you are paying and how much you are paying them. It is highly recommended that you do not use the same address but instead generate a new address for each payment you want to receive.

[Cryptolator]

1 - The Bitcoin Core, beeing an open source software where people can contribute and make changes, isn't it and issue? I would like to know how the changes are made on the code? Anyone can access and make changes? Is necessary any approval? If yes, from who?

Bitcoin Core is developed on github here: https://github.com/bitcoin/bitcoin. If you want to contribute, you make a fork of the repository (which goes to your account), make your changes, and then open a Pull Request on Bitcoin Core's repo. Then other Core contributors review your code and indicate whether they support the change or not. If a lot of the reviewers think the change is something that they want in Core, the maintainers of the repo will merge the change and it will be a part of Bitcoin Core.

I've always wondered whom decided who would have the control over the repo and if the fact that a few peoples has the final word on what can be changed in the source code could potentially be a problem in the future ?

[amaclin]

I've always wondered whom decided who would have the control over the repo

You are welcome to use your own implementation

and if the fact that a few peoples has the final word on what can be changed in
the source code could potentially be a problem in the future ?

Problem for whom?

[Cryptolator]

I've always wondered whom decided who would have the control over the repo

You are welcome to use your own implementation

and if the fact that a few peoples has the final word on what can be changed in
the source code could potentially be a problem in the future ?

Problem for whom?

Maybe I don't get it right, but I thought that the Bitcoin Core developement team were the one who could decide for soft or hard fork, so they could decide for any fundamental changes in Bitcoin (ex. Block size), and that if only a handful of people had the final says on what can be change, it could eventualy create conflict with people that don't have the same thought.

But I might be totally wrong and would certainly like to be corrected if so

[DannyHamilton]

Maybe I don't get it right, but I thought that the Bitcoin Core developement team were the one who could decide for soft or hard fork, so they could decide for any fundamental changes in Bitcoin (ex. Block size), and that if only a handful of people had the final says on what can be change, it could eventualy create conflict with people that don't have the same thought.

But I might be totally wrong and would certainly like to be corrected if so

You are totally wrong.

There are many bitcoin clients, each with their own development team.  Some of the more well known efforts are: Bitcoin Unlimited, Bitcoin Knots, Bitcoin Core, Bitcoin XT.  However, there are many services (such as wallet explorers and mining pools) that have their own custom written nodes as well.

The "Bitcoin Core development team" is just the team of developers that happen to contribute to the software named "Bitcoin Core".

Each team can make any changes they want to in their own software, and you can take a copy of the software and make any changes you want to as well.

As long as the changes don't break any of the consensus rules, then changes you make to your software will only effect users that shoose to run your software.

If you make a change to the consensus rules, then your software may accept a block that the rest of the network considers to be invalid.  This is called a "fork".  After that happens, it is possible that your software will never revert back to the blocks that the rest of the network is accepting, or it is possible that your software will eventually abandon the block that the rest of the network rejected and will join back to the same series of blocks as everyone else.  That all depends on how exactly you implement your change, and how popular your change is.

Any time ANYBODY changes a consensus rule (even Bitcoin Core), that is a risk.

If the change is made in a way that is backward compatible, then you generally only need the miners to accept the change.  Any node that doesn't upgrade might not get to use the new features, but they won't reject the blocks that have the new features in them.  This is called a "soft fork", and to prevent a situation where some miners accept blocks with the new features and others reject them soft forks changes are generally written such that they won't "activate" until a significant percentage (like 95%) of the hashpower signals that they are ready to accept the new feature.

If the change is made in a way that is not backward compatible, then you need ALL nodes to accept the change.  Any node that doesn't upgrade will reject any block that has the new feature (no matter how long the chain gets).  Therefore, if even one miner continues to reject the new features and mines the old block type, there could be a permanent split in the blockchain with nodes on the new software accepting blocks with the new features, and nodes on the old software accepting blocks that don't have the new features.  This is called a "hard fork", and to prevent a disastrous split in the blockchain an overwhelming majority of ALL nodes (wallets, miners, services, etc) must ALL upgrade to the new software before the feature gets used.

It is the users that run the nodes that get to decide what the rules are.  Development teams can add features to their software or remove features from their software, but they can't force users to run the software that the development team creates.  The users choose the software that they agree with, and abandon the software that they disagree with.  If a development team want's to remain relevant and avoid wasting time developing software that never gets used, then they need to be aware of what will give the users the best possible security, reliability, and usability.

There is no such thing as "official" when it comes to Bitcoin.  There is no government or business in charge.  It is a decentralized open system that anyone can participate in without requiring any type of permission.  If you can convince an overwhelming majority of the users to use software that you use, then you are in control (for so long as the users continue to use the software that you are writing). If users don't like something you are doing, then can just switch to someone else's software.  If users disagree, and there is competing software available, then it is possible for changes to be made that split the blockchain in each group is left with a system that is incompatible with the other.  They might both try to call themselves the "real" bitcoin, but in the end, the actual "real" bitcoin will be the one that survives (if any).

[Carlton Banks]

There is no such thing as "official" when it comes to Bitcoin.  There is no government or business in charge.  It is a decentralized open system that anyone can participate in without requiring any type of permission.  If you can convince an overwhelming majority of the users to use software that you use, then you are in control (for so long as the users continue to use the software that you are writing).

You are also totally wrong, and demonstrably contradicting yourself in this passage.


There is, by design and necessity, one prevalent set of consensus rules running the network at any one time, and those rules are delivered as a single package by a single development team.

The fact that you claim "no-one is in charge" while simultaneously claiming "if you can convince an overwhelming majority of the users to use software that you use, then you are in control" demonstrates the extremely contradictory nature of your rhetoric here, Danny Hamilton, you're hitting black = white levels of argument.

It's very simple Danny Hamilton, real life is more complex than the "freedom for everyone concerning everything" rhetoric that you and your cohorts continually espouse. In order to safeguard the freedom to transact without 3rd party permission or interference, Bitcoin must have rules, rules that are well designed to perform the task of conferring that ability to it's users. Ditto the safeguarding of the limited supply, and of keeping user identity pseudonymous.

You're right about one thing, people are indeed free to run different software, to fork Bitcoin unilaterally without majority support, or to create a separate network with their preferred consensus rules. The question to you, Danny Hamilton, is why you and your little cabal are constantly driving at trying to infiltrate Bitcoin's network and Bitcoin's rules from within, instead of trying to ley your (according to you) "better" consensus rules compete externally to the Bitcoin system? Don't tell me, it's because you "love Bitcoin so much, that you just can't stand to see it failing".

Thanks very much, but no thanks. Leave, quietly please. Or, as I expect, continue to try and rot this system and it's community from the inside, as you are wont to do both now and in the past. You're a disgrace to your fellow humans, who never did you any wrong, you're disgusting.

[Cryptolator]

Maybe I don't get it right, but I thought that the Bitcoin Core developement team were the one who could decide for soft or hard fork, so they could decide for any fundamental changes in Bitcoin (ex. Block size), and that if only a handful of people had the final says on what can be change, it could eventualy create conflict with people that don't have the same thought.

But I might be totally wrong and would certainly like to be corrected if so

You are totally wrong.

There are many bitcoin clients, each with their own development team.  Some of the more well known efforts are: Bitcoin Unlimited, Bitcoin Knots, Bitcoin Core, Bitcoin XT.  However, there are many services (such as wallet explorers and mining pools) that have their own custom written nodes as well.

The "Bitcoin Core development team" is just the team of developers that happen to contribute to the software named "Bitcoin Core".

Each team can make any changes they want to in their own software, and you can take a copy of the software and make any changes you want to as well.

As long as the changes don't break any of the consensus rules, then changes you make to your software will only effect users that shoose to run your software.

If you make a change to the consensus rules, then your software may accept a block that the rest of the network considers to be invalid.  This is called a "fork".  After that happens, it is possible that your software will never revert back to the blocks that the rest of the network is accepting, or it is possible that your software will eventually abandon the block that the rest of the network rejected and will join back to the same series of blocks as everyone else.  That all depends on how exactly you implement your change, and how popular your change is.

Any time ANYBODY changes a consensus rule (even Bitcoin Core), that is a risk.

If the change is made in a way that is backward compatible, then you generally only need the miners to accept the change.  Any node that doesn't upgrade might not get to use the new features, but they won't reject the blocks that have the new features in them.  This is called a "soft fork", and to prevent a situation where some miners accept blocks with the new features and others reject them soft forks changes are generally written such that they won't "activate" until a significant percentage (like 95%) of the hashpower signals that they are ready to accept the new feature.

If the change is made in a way that is not backward compatible, then you need ALL nodes to accept the change.  Any node that doesn't upgrade will reject any block that has the new feature (no matter how long the chain gets).  Therefore, if even one miner continues to reject the new features and mines the old block type, there could be a permanent split in the blockchain with nodes on the new software accepting blocks with the new features, and nodes on the old software accepting blocks that don't have the new features.  This is called a "hard fork", and to prevent a disastrous split in the blockchain an overwhelming majority of ALL nodes (wallets, miners, services, etc) must ALL upgrade to the new software before the feature gets used.

It is the users that run the nodes that get to decide what the rules are.  Development teams can add features to their software or remove features from their software, but they can't force users to run the software that the development team creates.  The users choose the software that they agree with, and abandon the software that they disagree with.  If a development team want's to remain relevant and avoid wasting time developing software that never gets used, then they need to be aware of what will give the users the best possible security, reliability, and usability.

There is no such thing as "official" when it comes to Bitcoin.  There is no government or business in charge.  It is a decentralized open system that anyone can participate in without requiring any type of permission.  If you can convince an overwhelming majority of the users to use software that you use, then you are in control (for so long as the users continue to use the software that you are writing). If users don't like something you are doing, then can just switch to someone else's software.  If users disagree, and there is competing software available, then it is possible for changes to be made that split the blockchain in each group is left with a system that is incompatible with the other.  They might both try to call themselves the "real" bitcoin, but in the end, the actual "real" bitcoin will be the one that survives (if any).

Thanks for the lenghty reply, this was a quite interesting read ! You say that 95% of the hashing power would have to agree in order to make a fundamental change but I've always read that a hard fork would need 50% + 1 of the hashing power ? Can you elaborate on that ?

[Cryptolator]

There is no such thing as "official" when it comes to Bitcoin.  There is no government or business in charge.  It is a decentralized open system that anyone can participate in without requiring any type of permission.  If you can convince an overwhelming majority of the users to use software that you use, then you are in control (for so long as the users continue to use the software that you are writing).

You are also totally wrong, and demonstrably contradicting yourself in this passage.


There is, by design and necessity, one prevalent set of consensus rules running the network at any one time, and those rules are delivered as a single package by a single development team.

The fact that you claim "no-one is in charge" while simultaneously claiming "if you can convince an overwhelming majority of the users to use software that you use, then you are in control" demonstrates the extremely contradictory nature of your rhetoric here, Danny Hamilton, you're hitting black = white levels of argument.

It's very simple Danny Hamilton, real life is more complex than the "freedom for everyone concerning everything" rhetoric that you and your cohorts continually espouse. In order to safeguard the freedom to transact without 3rd party permission or interference, Bitcoin must have rules, rules that are well designed to perform the task of conferring that ability to it's users. Ditto the safeguarding of the limited supply, and of keeping user identity pseudonymous.

You're right about one thing, people are indeed free to run different software, to fork Bitcoin unilaterally without majority support, or to create a separate network with their preferred consensus rules. The question to you, Danny Hamilton, is why you and your little cabal are constantly driving at trying to infiltrate Bitcoin's network and Bitcoin's rules from within, instead of trying to ley your (according to you) "better" consensus rules compete externally to the Bitcoin system? Don't tell me, it's because you "love Bitcoin so much, that you just can't stand to see it failing".

Thanks very much, but no thanks. Leave, quietly please. Or, as I expect, continue to try and rot this system and it's community from the inside, as you are wont to do both now and in the past. You're a disgrace to your fellow humans, who never did you any wrong, you're disgusting.

Why being so rude ? I would like to understand why do you hate this guy so much ? I don't know him but you seems to have a really bad opinion about him... :/

[Carlton Banks]

I'm not being rude, I'm giving an entirely appropriate ethical dressing down to someone who is trying to corrupt Bitcoin's strengths using cleverly constructed technical rhetoric.

Danny Hamilton is the person behaving immorally, and deserves everything he gets.

[DannyHamilton]

Thanks for the lenghty reply, this was a quite interesting read ! You say that 95% of the hashing power would have to agree in order to make a fundamental change but I've always read that a hard fork would need 50% + 1 of the hashing power ? Can you elaborate on that ?

I gave 95% as an example, and not as a specific required number (which is why I put the word "like" in front of it).

What is important is that the change be accepted by "a significant percentage".

The larger that percentage is the smaller the risk to the users.  How significant that risk is depends on what the effects of the change are.

As an example, lets say a decision is made to have a smaller maximum allowed block size...

This is backward-compatible since any old node or miner is already perfectly willing to accept a smaller block.  It only requires enough miners running the new software enforce the new rule. Therefore it is considered to be a "soft-fork".


Now lets say only 10% of the the global hashpower implements the change:

In that case, on average, the new software will solve 1 out of every 10 blocks. Lets say I'm a miner on the new software, and you're a miner on the old software.  I mine a small block, and you accept it...  So far so good.  The blockchain is growing as it should.  Next you mine a block, and broadcast it to the network.  Me and all the other miners on the new software will consider your block to be invalid.  We will toss it out and not build on top of it.  Instead we will continue to build on top of the block that I mined earlier.  Meanwhile, you and the other 90% of miners on the old software will accept your block, add it to your blockchain, and then build on top of that.

Uh oh.  We've got a fork in the chain.  Which one is the "real" chain?  Which one is the "right" chain?  There is a disagreement on that matter because there is a disagreement in the software on what the consensus rules are.  Since 90% of the hashpower is running the old software, that fork will grow faster than the chain being built by the new software. It will always be longer.  However, since that longer fork includes blocks that the new software thinks are invalid, the new software will never accept that fork as being valid and will continue to ignore it.

Whether a user sees a transaction as confirmed or not will depend on whether that transaction is in only one side of the fork, and which software that user is running.  This is quite a mess.


Now lets say that 90% of the global hashpower implements the change:

In that case, on average, the new software will solve 9 out of every 10 blocks. Lets say I'm a miner on the new software, and you're a miner on the old software.  I mine a small block, and you accept it...  So far so good.  The blockchain is growing as it should.  Next you mine a block, and broadcast it to the network.  Me and all the other miners on the new software will consider your block to be invalid.  We will toss it out and not build on top of it.  Instead we will continue to build on top of the block that I mined earlier.  Meanwhile, you and the other 10% of miners on the old software will accept your block, add it to your blockchain, and then build on top of that.

Hmm.  We've got a fork in the chain, but in this situation maybe it isn't too bad.  Since the new software is likely to create another 9 blocks before you and your "old software" friends create even 1 more block, our chain will be longer than yours.  Since the old software doesn't see small blocks as invalid, all the miners running the old software will just abandon/orphan the bigger block and switch over to the longer fork as soon as it has more blocks.

Whether a user sees a transaction as confirmed or not will depend on whether that transaction is in only one side of the fork, and which software that user is running.  But, their wallet will switch over to the "new software" fork within a few blocks.  Anyone that is running the old software might want to wait for a few more confirmations than they usually would just to make sure they are on the "correct" fork, but if a transaction has more than 10 confirmations, they can be pretty confident that the entire network sees the transaction as confirmed.


Now lets say that 51% of the global hashpower implements the change:

In that case, on average, the new software will solve just barely more than half the blocks. Lets say I'm a miner on the new software, and you're a miner on the old software.  I mine a small block, and you accept it...  So far so good.  The blockchain is growing as it should.  Next you mine a block, and broadcast it to the network.  Me and all the other miners on the new software will consider your block to be invalid.  We will toss it out and not build on top of it.  Instead we will continue to build on top of the block that I mined earlier.  Meanwhile, you and the other 49% of miners on the old software will accept your block, add it to your blockchain, and then build on top of that.

Oh dear.  We've got a fork in the chain, and this seems to be the worst of the three scenarios. Since both versions of the software are likely to create blocks at a nearly equal rate it is possible that the "old software" chain could get a second block before the "new software" miners can catch up.  Then it's possible that for the next 2 weeks the blocks are effectively back-and-forth (new software solves, then old software solves, then new software, etc).  In this case, the "old software" fork stays longer (and therefore is accepted by all "old software" nodes as "valid") for the entire two weeks.  Then suddenly the "new software" miners might get lucky and solve the next three blocks in a row before the "old software" nodes can solve any.  BAM.  The "new software" fork is now longer, and the entire last two weeks of confirmations and history is wiped out from the "old software" nodes.  POOF. They suddenly forget everything that they thought was true and switch over to the "new software" fork, treating it as "true" and "valid".

At least when the "new software" miners only had 10%, you could count on consistency with your own view of the world.  You could be sure that everyone that was running the "old software" would agree on what the blockchain looked like and it wouldn't change.  You could be sure that everyone that was running the "new software" would agree on what the blockchain looked like and it wouldn't change.

Now you have a situation where everyone running the "old software" agrees for a while (hours? days? weeks? years?), and then suddenly all that history disappears and is replaced with a re-written history.  That's completely unreliable and unusable.


So, perhaps you can see that trying to soft-fork with too small of a minority of hashpower results in a permanently split chain (not much different than a hard-fork), trying to soft-fork with an overwhelming majority of hashpower results in the majority imposing their will on those that don't upgrade, and trying to fork with just a small majority of the hashpower results in an inconsistent and unusable system.

The larger the majority on the "new software", the safer it is and the less blocks that are likely to be orphaned when the "old software" nodes jump back to the longer chain.

[DannyHamilton]

I would like to understand why do you hate this guy so much ? I don't know him but you seems to have a really bad opinion about him... :/

Carlton Banks is a very vocal and aggressive supporter of the Bitcoin Core software.  Because my explanations suggest that Bitcoin Core doesn't have exclusive eternal power over what Bitcoin gets to be, he gets angry at me. He accuses me of being sneaky and trying to influence people into supporting implementations that are not created by Bitcoin Core.  This appears to make him very angry, and he scolds me frequently.

[Carlton Banks]

If you can explain how simultaneously stating "no-one is in charge" and that "convincing a majority of users to use software that you use puts you in control" are not convenient contradictions to sneakily prosecute your support of tearing down Bitcoin's consensus rules, then go right ahead

I predict you are unwilling to engage the question, as it's a summary and categorical dismissal of the covert political rhetoric that forms your entire reason for being here on Bitcointalk.

[Cryptolator]

Thanks for the lenghty reply, this was a quite interesting read ! You say that 95% of the hashing power would have to agree in order to make a fundamental change but I've always read that a hard fork would need 50% + 1 of the hashing power ? Can you elaborate on that ?

I gave 95% as an example, and not as a specific required number (which is why I put the word "like" in front of it).

What is important is that the change be accepted by "a significant percentage".

The larger that percentage is the smaller the risk to the users.  How significant that risk is depends on what the effects of the change are.

As an example, lets say a decision is made to have a smaller maximum allowed block size...

This is backward-compatible since any old node or miner is already perfectly willing to accept a smaller block.  It only requires enough miners running the new software enforce the new rule. Therefore it is considered to be a "soft-fork".


Now lets say only 10% of the the global hashpower implements the change:

In that case, on average, the new software will solve 1 out of every 10 blocks. Lets say I'm a miner on the new software, and you're a miner on the old software.  I mine a small block, and you accept it...  So far so good.  The blockchain is growing as it should.  Next you mine a block, and broadcast it to the network.  Me and all the other miners on the new software will consider your block to be invalid.  We will toss it out and not build on top of it.  Instead we will continue to build on top of the block that I mined earlier.  Meanwhile, you and the other 90% of miners on the old software will accept your block, add it to your blockchain, and then build on top of that.

Uh oh.  We've got a fork in the chain.  Which one is the "real" chain?  Which one is the "right" chain?  There is a disagreement on that matter because there is a disagreement in the software on what the consensus rules are.  Since 90% of the hashpower is running the old software, that fork will grow faster than the chain being built by the new software. It will always be longer.  However, since that longer fork includes blocks that the new software thinks are invalid, the new software will never accept that fork as being valid and will continue to ignore it.

Whether a user sees a transaction as confirmed or not will depend on whether that transaction is in only one side of the fork, and which software that user is running.  This is quite a mess.


Now lets say that 90% of the global hashpower implements the change:

In that case, on average, the new software will solve 9 out of every 10 blocks. Lets say I'm a miner on the new software, and you're a miner on the old software.  I mine a small block, and you accept it...  So far so good.  The blockchain is growing as it should.  Next you mine a block, and broadcast it to the network.  Me and all the other miners on the new software will consider your block to be invalid.  We will toss it out and not build on top of it.  Instead we will continue to build on top of the block that I mined earlier.  Meanwhile, you and the other 10% of miners on the old software will accept your block, add it to your blockchain, and then build on top of that.

Hmm.  We've got a fork in the chain, but in this situation maybe it isn't too bad.  Since the new software is likely to create another 9 blocks before you and your "old software" friends create even 1 more block, our chain will be longer than yours.  Since the old software doesn't see small blocks as invalid, all the miners running the old software will just abandon/orphan the bigger block and switch over to the longer fork as soon as it has more blocks.

Whether a user sees a transaction as confirmed or not will depend on whether that transaction is in only one side of the fork, and which software that user is running.  But, their wallet will switch over to the "new software" fork within a few blocks.  Anyone that is running the old software might want to wait for a few more confirmations than they usually would just to make sure they are on the "correct" fork, but if a transaction has more than 10 confirmations, they can be pretty confident that the entire network sees the transaction as confirmed.


Now lets say that 51% of the global hashpower implements the change:

In that case, on average, the new software will solve just barely more than half the blocks. Lets say I'm a miner on the new software, and you're a miner on the old software.  I mine a small block, and you accept it...  So far so good.  The blockchain is growing as it should.  Next you mine a block, and broadcast it to the network.  Me and all the other miners on the new software will consider your block to be invalid.  We will toss it out and not build on top of it.  Instead we will continue to build on top of the block that I mined earlier.  Meanwhile, you and the other 49% of miners on the old software will accept your block, add it to your blockchain, and then build on top of that.

Oh dear.  We've got a fork in the chain, and this seems to be the worst of the three scenarios. Since both versions of the software are likely to create blocks at a nearly equal rate it is possible that the "old software" chain could get a second block before the "new software" miners can catch up.  Then it's possible that for the next 2 weeks the blocks are effectively back-and-forth (new software solves, then old software solves, then new software, etc).  In this case, the "old software" fork stays longer (and therefore is accepted by all "old software" nodes as "valid") for the entire two weeks.  Then suddenly the "new software" miners might get lucky and solve the next three blocks in a row before the "old software" nodes can solve any.  BAM.  The "new software" fork is now longer, and the entire last two weeks of confirmations and history is wiped out from the "old software" nodes.  POOF. They suddenly forget everything that they thought was true and switch over to the "new software" fork, treating it as "true" and "valid".

At least when the "new software" miners only had 10%, you could count on consistency with your own view of the world.  You could be sure that everyone that was running the "old software" would agree on what the blockchain looked like and it wouldn't change.  You could be sure that everyone that was running the "new software" would agree on what the blockchain looked like and it wouldn't change.

Now you have a situation where everyone running the "old software" agrees for a while (hours? days? weeks? years?), and then suddenly all that history disappears and is replaced with a re-written history.  That's completely unreliable and unusable.


So, perhaps you can see that trying to soft-fork with too small of a minority of hashpower results in a permanently split chain (not much different than a hard-fork), trying to soft-fork with an overwhelming majority of hashpower results in the majority imposing their will on those that don't upgrade, and trying to fork with just a small majority of the hashpower results in an inconsistent and unusable system.

The larger the majority on the "new software", the safer it is and the less blocks that are likely to be orphaned when the "old software" nodes jump back to the longer chain.

That was another really interesting post, thanks for taking the time to post such a lengthy and constructive explaination !

[wingding]

@Kromos: Good questions asked

@achow101: It does not "require every single person running a Bitcoin node to update their software to accept that new rule." I f a significant number do, you would have 2 Bitcoins - or 2 blockchains.

@Danny Hamilton: You say: "As long as the changes don't break any of the consensus rules, then changes you make to your software will only effect users that choose to run your software."
Then my question is: Have this rules been subject to changes since deployment? If the answer is yes, I suppose this is why Carlton Banks attacks you?