Another thread that shows all that tinfoil nutjobs.
He made some code, he felt to be important. Other Dev Core Commiters didn't want it in Bitcoin Core, so he put it into an alternative client and wanted users to decide and not just the Core Dev Team.
The End.
Topic: Why has Gavin left core and attempted to make a fork? - page 2. (Read 2404 times)
Gavin didn't leave the Core, he is still contributing to the code.
He is just also helping other node implementations.
He is just also helping other node implementations.
He is collaborating in the creations of "two typos of bitcoins"? This is the right thing to tell? Or I'm again wrong? How is possible this?
The Bitcoin Core team decided to hold off on block size upgrades until it was properly tested. {Let's not forget these block sizes restrictions where implemented by Satoshi to reduce spam attacks} and also to
Do they have any plan to increase the block size?With the lack of consensus? No.
Gavin didn't leave the Core, he is still contributing to the code.
He is just also helping other node implementations.
He is just also helping other node implementations.
The Bitcoin Core team decided to hold off on block size upgrades until it was properly tested. {Let's not forget these block sizes restrictions where implemented by Satoshi to reduce spam attacks} and also to
Do they have any plan to increase the block size?No and for this Gavin is gone from the team deciding to create bitcoin XT with biggest block sizes. This was the reason of the divergences and the division.
The Bitcoin Core team decided to hold off on block size upgrades until it was properly tested. {Let's not forget these block sizes restrictions where implemented by Satoshi to reduce spam attacks} and also to
Do they have any plan to increase the block size?
Because, he want his mark on Bitcoin. A war for Liberty.
It is to simple. Other part of devs didn't want that the maximum size of the blocks to be increased to allow more transaction in less time. So were two groups with radical and unchanging point of views. Gavin had the courage to go alone in his road to realize that in which he believe is the best for bitcoin. The history will tell who was right.
The debate is mainly about the future and how the increase in transactions will be handled by the network.
As blocks fill up, solutions need to be made.
Gavin wants to increase the maximum size of the blocks, to allow more transactions. Opponents don't want this, because they fear massive storage size needs and slower mining in places with high latency (china).
One important side node: The devs from the dev team that strongly oppose are heavily involved in creating a sidechain network company to fix this. It seems that financial motives play a big role too.
As blocks fill up, solutions need to be made.
Gavin wants to increase the maximum size of the blocks, to allow more transactions. Opponents don't want this, because they fear massive storage size needs and slower mining in places with high latency (china).
One important side node: The devs from the dev team that strongly oppose are heavily involved in creating a sidechain network company to fix this. It seems that financial motives play a big role too.
Who are the opponents?
And I thought that Gavin left to work for the Bitcoin Foundation.
What happened with that?
Did that sink?
IMHO it looks more and more like a 'power grab' for the bitcoin XT devs of Mike Hearns and Gavin to 'BE THE DEVS OF NOTE" for BTC
ie ....keys to the kingdom
Not sure I want these two guys to be the only folk deciding on bitcoin cores fate don't ya know on the other hand the core devs all they had to do to resolve this again imho was to put in a fixed timeline plan on when they planned to
increase block size (in that everyone says they agree eventually it should be done) that would have cut bitcoin xt off at the knees
they did not do so which makes me believe they are into "power keeping mode" and if they keep the keys to the kingdom they can slowly
with real effort drag their feet on any innovation on the coin less they do something to 'screw the pooch"
not sure I like the fact these guys shiver at any mention of bitcoin innovation at all due to fear again imho
anyway as I've said before ......put them in a room and they could play 'slap fight' for a way to consensus
I asked about the same question before, because I also find Gavins actions irritating: https://bitcointalksearch.org/topic/why-gavin-is-so-desperate-about-his-fork-is-he-hiding-something-1154636
because he works for CIA and he has a bigger ego than carrying about btc!
Gavin has not been heavily involved with Bitcoin development for nearly 2 years. His opinion on the subject as a previous Lead Developer of Bitcoin has still been valued by the community though. I think he and
Mike Hearn was under the impression that they had much bigger support for their fork, when they started out with this. When the people realized what XT was really about {Their own projects and all the extras
they wanted to implement... most people backed away from it} Who wants a Government Coin full of backdoors for US spy agencies?
Luck was on their side, when they banned/censored people on XT subjects in the \r\Bitcoin sub-Reddit ... and more people got pissed off at that, and decided to side on the XT side.
The Bitcoin Core team decided to hold off on block size upgrades until it was properly tested. {Let's not forget these block sizes restrictions where implemented by Satoshi to reduce spam attacks} and also to
bring alternatives to the table, if this happens. {side chains} ...both sides imo made mistakes by bringing in their personal interest with these forks.
Mike Hearn was under the impression that they had much bigger support for their fork, when they started out with this. When the people realized what XT was really about {Their own projects and all the extras
they wanted to implement... most people backed away from it} Who wants a Government Coin full of backdoors for US spy agencies?
Luck was on their side, when they banned/censored people on XT subjects in the \r\Bitcoin sub-Reddit ... and more people got pissed off at that, and decided to side on the XT side.
The Bitcoin Core team decided to hold off on block size upgrades until it was properly tested. {Let's not forget these block sizes restrictions where implemented by Satoshi to reduce spam attacks} and also to
bring alternatives to the table, if this happens. {side chains} ...both sides imo made mistakes by bringing in their personal interest with these forks.
Oh, and it's probably also important to note that the debate has been made heavily partisan by the conflation of BIP 101 with the XT client. In my case, I oppose XT by default since I oppose BIP 101. But XT contains other code that is controversial. These are my thoughts on the TOR IP address blacklist controversy:
Actually, it fits the definition of a blacklist quite well, particularly if you consider why the list was compiled in the first place:
https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=definition+blacklist
But this is just a silly semantic issue.
The larger issue is this: Why do people keep rationalizing a centralized solution to DDOS attacks? Compiling a centralized list introduces trust into an otherwise trustless system. That's downright foolish.
There is nothing wrong with deprioritizing IP addresses that are maliciously attacking you. Why don't we stick with that? Why can't a node determine when an IP address is spamming it, and deprioritize its access on that basis? Perhaps we can make it even easier for nodes to do that. What possible reason is there to justify using a [trusted] third party to compile a list of suspicious IP addresses that nodes will trust simply by virtue of running a node?
If there is a problem, use a decentralized solution. Nodes should be capable of identifying IP addresses that are attacking them without introducing third party trust.
Perhaps if attacks are predominantly coming from Malaysia, we should begin deprioritizing Malaysian IP ranges. There are geo-IP services that we can trust as a third party to compile lists of such suspicious IP ranges, too.
All that some of us ask is that people stop supporting unnecessary centralized solutions. Just admit that there are better ways to approach DDOS attacks, so we can oppose this aspect of the XT implementation hand in hand and move onto the next issue of contention......
@VirosaGITS
LOL
You can even add all the possible IPs to the list, then they will have all the same priority, and just during a DoS attack
Do you know that will happen when a dev will add other IP to this list? Someone will see it because ... it's an open source project!
Do you check every day what devs add to the Bitcoin Core?
Again, it isn't a black list, it is a "low priority list", that enable it self only IF there is a DoS attack.
LOL
You can even add all the possible IPs to the list, then they will have all the same priority, and just during a DoS attack
Do you know that will happen when a dev will add other IP to this list? Someone will see it because ... it's an open source project!
Do you check every day what devs add to the Bitcoin Core?
Again, it isn't a black list, it is a "low priority list", that enable it self only IF there is a DoS attack.
Actually, it fits the definition of a blacklist quite well, particularly if you consider why the list was compiled in the first place:
https://www.google.com/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=definition+blacklist
But this is just a silly semantic issue.
The larger issue is this: Why do people keep rationalizing a centralized solution to DDOS attacks? Compiling a centralized list introduces trust into an otherwise trustless system. That's downright foolish.
There is nothing wrong with deprioritizing IP addresses that are maliciously attacking you. Why don't we stick with that? Why can't a node determine when an IP address is spamming it, and deprioritize its access on that basis? Perhaps we can make it even easier for nodes to do that. What possible reason is there to justify using a [trusted] third party to compile a list of suspicious IP addresses that nodes will trust simply by virtue of running a node?
If there is a problem, use a decentralized solution. Nodes should be capable of identifying IP addresses that are attacking them without introducing third party trust.
Quote
Currently Tor exits are labelled as being lower priority than regular IP addresses, as jamming attacks via Tor have been observed
Perhaps if attacks are predominantly coming from Malaysia, we should begin deprioritizing Malaysian IP ranges. There are geo-IP services that we can trust as a third party to compile lists of such suspicious IP ranges, too.
All that some of us ask is that people stop supporting unnecessary centralized solutions. Just admit that there are better ways to approach DDOS attacks, so we can oppose this aspect of the XT implementation hand in hand and move onto the next issue of contention......
Because of his CIA meeting
The debate is mainly about the future and how the increase in transactions will be handled by the network.
As blocks fill up, solutions need to be made.
Gavin wants to increase the maximum size of the blocks, to allow more transactions. Opponents don't want this, because they fear massive storage size needs and slower mining in places with high latency (china).
One important side node: The devs from the dev team that strongly oppose are heavily involved in creating a sidechain network company to fix this. It seems that financial motives play a big role too.
As blocks fill up, solutions need to be made.
Gavin wants to increase the maximum size of the blocks, to allow more transactions. Opponents don't want this, because they fear massive storage size needs and slower mining in places with high latency (china).
One important side node: The devs from the dev team that strongly oppose are heavily involved in creating a sidechain network company to fix this. It seems that financial motives play a big role too.
It's not as partisan as you make it out to be. While I do not support BIP 101, I do support BIP 100 and BIP 102. This is not simply about those who want bigger blocks and those who oppose. That's part of the problem of lumping us into partisan camps (like XT vs. 1MBers).
Some of us think BIP 101 is rash and lacking in foresight regarding future problems. Personally, I think it's incredibly audacious to assume that we can -- today -- plan for what real adoption will look like 20 years out and arbitrarily putting it at 8000x current capacity, with sufficient thought for hardware and bandwidth capabilities, security in the case of such a potentially bloated chain, and many heretofore unknown and unacknowledged problems that may arise. And that's whether or not Gavin, Hearn and the developers of today that audit the code have the technical foresight to understand and plan for every contingency. To be clear, that is impossible. (Nevermind that Moore's Law is an unproven theory that shouldn't be used as the basis for block size. If the predominant issue appears to be capacity -- and the extent that this matters is dependent on adoption -- why an unscientific theory about expected growth in processor capacity is applicable is beyond me.)
I think people need to lose this idea that this is the "fork to end all forks." That's not how bitcoin works.
I support BIP 100 because it takes a more conservative approach that gives us ample time to observe scalability over time, and to stay in line with real growth in transaction volume rather than some arbitrary vision of exponential adoption seen in BIP 101. I think having the miners vote among themselves as to when a limit increase should occur is a preferable approach. And 90% is a much better measure of consensus than 75% -- which to me is more like 50-60% + a lucky streak.
Consensus is paramount. I believe all of the above are good reasons why BIP 100 is far preferable to BIP 101, and why it will be easier to maintain consensus post-fork.
ahh, he want something, majority of devs not, so he decided to fork the project (which is fine) and leave and continue with his ideas somewhere else (also fine)
I don't see so much drama, this is nothing new in open-source community. And actually, I'm quite happy that general consensus won over opinion of "Head of Bitcoin"..
everything bad is good for something:)
I don't see so much drama, this is nothing new in open-source community. And actually, I'm quite happy that general consensus won over opinion of "Head of Bitcoin"..
everything bad is good for something:)
I guess the part I am confused about is why is why are we are seeing Gavin making an entire new fork of bitcoin away from the current devs? Why are these changes not being made to core directly by him? Did he step down all that time ago because he couldn't do what he wanted with the other devs & wanted to take control himself??
If he is successful does that mean he and his team would have basically taken over the development of bitcoin?
I am trying to understand the motives behind what’s going on here.
If he is successful does that mean he and his team would have basically taken over the development of bitcoin?
I am trying to understand the motives behind what’s going on here.
he probably want to gain more autorithy, by creating a version , that has his own features, and can be consider more, made by him, instead core was still considered made by satoshi
i can't see other reasons
I guess the part I am confused about is why is why are we are seeing Gavin making an entire new fork of bitcoin away from the current devs? Why are these changes not being made to core directly by him? Did he step down all that time ago because he couldn't do what he wanted with the other devs & wanted to take control himself??
If he is successful does that mean he and his team would have basically taken over the development of bitcoin?
I am trying to understand the motives behind what’s going on here.
If he is successful does that mean he and his team would have basically taken over the development of bitcoin?
I am trying to understand the motives behind what’s going on here.
i think is a simple bigger block size is a problem
Jump to: