If you modify the code and recompile it, then try to run it. Are you sure it will work? Because usually when you change the code, it cause a fork.
wtf?
This is why stupid FUD got everywhere due to parrots.
Topic: ... - page 10. (Read 61013 times)
I don't understand what's so hard.
1. You like 1 MB blocksize limit and think there's no need to raise it anytime soon.
Solution: Install Bitcoin Core
2. You want blocksize limit to be increased (BIP 101), but disagree with additions made to Bitcoin XT
Solution: Install Core codebase + BIP 101. You don't even have to compile it yourself, there's precompiled binaries available.
https://www.reddit.com/r/bitcoinxt/comments/3hsc3f/bitcoinxt_with_just_the_patch_for_big_blocks_only/
3. You want blocksize limit to be increased and think other additions in Bitcoin XT are cool.
Solution: Install Bitcoin XT
4. You want blocksize limit to be increased and think other additions in Bitcoin XT are cool, except the evil TOR node dropping DDOS protection.
Solution: Raise discussion with Bitcoin XT devs for that part of code to be removed/disabled by default or be a sport and compile the code yourself without the offending code and put the binaries available for others to download.
5. You're not happy with 1MB blocksize limit and BIP 101 sounds like a stupid idea.
Solution: A.) Wait patiently and someone might make BIP XXX fork that you like better. B) Code something that pleases you and publish your own BIP.
This is decentralization.
1. You like 1 MB blocksize limit and think there's no need to raise it anytime soon.
Solution: Install Bitcoin Core
2. You want blocksize limit to be increased (BIP 101), but disagree with additions made to Bitcoin XT
Solution: Install Core codebase + BIP 101. You don't even have to compile it yourself, there's precompiled binaries available.
https://www.reddit.com/r/bitcoinxt/comments/3hsc3f/bitcoinxt_with_just_the_patch_for_big_blocks_only/
3. You want blocksize limit to be increased and think other additions in Bitcoin XT are cool.
Solution: Install Bitcoin XT
4. You want blocksize limit to be increased and think other additions in Bitcoin XT are cool, except the evil TOR node dropping DDOS protection.
Solution: Raise discussion with Bitcoin XT devs for that part of code to be removed/disabled by default or be a sport and compile the code yourself without the offending code and put the binaries available for others to download.
5. You're not happy with 1MB blocksize limit and BIP 101 sounds like a stupid idea.
Solution: A.) Wait patiently and someone might make BIP XXX fork that you like better. B) Code something that pleases you and publish your own BIP.
This is decentralization.
Sounds like you picked the worlds worst sys admin team there. Sorry for ya troubles, brah.... 
You know what they say. "You can't pick your family."
But when my car breaks down, my dad is the one to visit and he doesn't tell me to go and buy all the tools, panels and a workshop manual to fix it myself
He just drives it back a day later and hangs around for some beers. 
Right now most bitcoin users are completely unaware of the blacklist, we need to spread this information asap. Please retweet my tweet or make your own. We need this information to reach both the media and the community, it's a fundamental threat to bitcoin https://twitter.com/turtlehurricane/status/633844328205430784
Heck, what's the big deal? Can't you just remove the IPs in list above, recompile and run your own XT version that would even trust Stalin's personal node?
This is not a fundamental issue. The code is open-source: you are free to remove/edit any source code to your liking.
My dad can't. Neither can my mother, 2 sisters, grandfather, grandmother, most of my cousins or my wife. Thats the big deal unless you want to come round and do it for us everytime there is an update?
Sounds like you picked the worlds worst sys admin team there. Sorry for ya troubles, brah....
Right now most bitcoin users are completely unaware of the blacklist, we need to spread this information asap. Please retweet my tweet or make your own. We need this information to reach both the media and the community, it's a fundamental threat to bitcoin https://twitter.com/turtlehurricane/status/633844328205430784
Heck, what's the big deal? Can't you just remove the IPs in list above, recompile and run your own XT version that would even trust Stalin's personal node?
This is not a fundamental issue. The code is open-source: you are free to remove/edit any source code to your liking.
My dad can't. Neither can my mother, 2 sisters, grandfather, grandmother, most of my cousins or my wife. Thats the big deal unless you want to come round and do it for us everytime there is an update?
BIP101 and XT are separate issues. I oppose both, although I do support some mechanism for increasing block size limit, generally. IF BIP101 is going to happen (doubtful), we as a community need to discourage the use of XT, as its default implementation (which the vast majority of nodes will use) contains trust-adding features, and unnecessarily so.
How is getting a list of tor exit nodes "adding trust"? There is no editorialising of the list - its just what tor returns.
That doesn't matter (whether or not it remains true). What matters is that we are downloading and trusting a central list that is published by a third party (torproject.org now -- who knows, later).... That is the very definition of trust.
Nodes can see IP addresses that are DDOSing them. They can deprioritize them as needed without downloading a list from a (trusted) third party. Why is this even a subject of discussion?
If they have the skills to do that, why don't you think they can set a value in a conf file?
Good questions. The answers to your questions are in the dev discussion on the pull request to Core. Please read this discussion. If you continue to have questions after reading this, then post here.
https://github.com/bitcoin/bitcoin/pull/6364
BIP101 and XT are separate issues. I oppose both, although I do support some mechanism for increasing block size limit, generally. IF BIP101 is going to happen (doubtful), we as a community need to discourage the use of XT, as its default implementation (which the vast majority of nodes will use) contains trust-adding features, and unnecessarily so.
How is getting a list of tor exit nodes "adding trust"? There is no editorialising of the list - its just what tor returns.
That doesn't matter (whether or not it remains true). What matters is that we are downloading and trusting a central list that is published by a third party (torproject.org now -- who knows, later).... That is the very definition of trust.
Nodes can see IP addresses that are DDOSing them. They can deprioritize them as needed without downloading a list from a (trusted) third party. Why is this even a subject of discussion?
If they have the skills to do that, why don't you think they can set a value in a conf file?
BIP101 and XT are separate issues. I oppose both, although I do support some mechanism for increasing block size limit, generally. IF BIP101 is going to happen (doubtful), we as a community need to discourage the use of XT, as its default implementation (which the vast majority of nodes will use) contains trust-adding features, and unnecessarily so.
How is getting a list of tor exit nodes "adding trust"? There is no editorialising of the list - its just what tor returns.
That doesn't matter (whether or not it remains true). What matters is that we are downloading and trusting a central list that is published by a third party (torproject.org now -- who knows, later).... That is the very definition of trust.
Nodes can see IP addresses that are DDOSing them. They can deprioritize them as needed without downloading a list from a (trusted) third party. Why is this even a subject of discussion?
BIP101 and XT are separate issues. I oppose both, although I do support some mechanism for increasing block size limit, generally. IF BIP101 is going to happen (doubtful), we as a community need to discourage the use of XT, as its default implementation (which the vast majority of nodes will use) contains trust-adding features, and unnecessarily so.
How is getting a list of tor exit nodes "adding trust"? There is no editorialising of the list - its just what tor returns.
So the real issue is only whose boots are to be licked, Adam's or Mike's?
correct
^^-- LIKE
JorgeStolfi, if you read the thread topic, the goal is to not run software that does blacklisting, or more specifically, introduces centralized trust, which is a systemic risk and counter to the principles of Bitcoin. What differentiates Bitcoin from everything that came before it is that it is a TRUSTLESS SYSTEM.
I think most people support larger blocks overall, but don't support the additional logic being thrown into XT. It looks like Mike has turned block size into a red herring for other agenda, permitting him to take over bitcoin code and introduce other "features" that run counter to the trustless network that Bitcoin was designed to be.
Bingo. Unfortunately, the diehard XT supporters in here won't address legitimate critiques, whether of XT or BIP 101. They'd rather continue to act as if anyone who doesn't support XT is a "Blockstream shill" and continue shouting while knocking over straw men. That way, it's pretty easy to force the discussion onto the next page and gloss over thoughtful posts.
Every time I've brought up how the third party compilation of IP addresses is centralized and trust-adding, the standard response (in the unlikely event that an XT supporter actually responds to the argument) is that "oh, anyone running a node can disable that feature." That's not good enough. Nodes don't need a centralized, trusted list to tell them when someone is attacking them from a certain IP address. That's laughable.
Why would anyone want to introduce trust, when the objective can be achieved without it?
What does this have to do with BIP 101?
That's very cute. The point I was responding to and the general subject of discussion here (see thread title) is XT. I'm not sure why you are implying that my comments are out of place.
BIP101 and XT are separate issues. I oppose both, although I do support some mechanism for increasing block size limit, generally. IF BIP101 is going to happen (doubtful), we as a community need to discourage the use of XT, as its default implementation (which the vast majority of nodes will use) contains trust-adding features, and unnecessarily so.
So the real issue is only whose boots are to be licked, Adam's or Mike's?
correct
^^-- LIKE
JorgeStolfi, if you read the thread topic, the goal is to not run software that does blacklisting, or more specifically, introduces centralized trust, which is a systemic risk and counter to the principles of Bitcoin. What differentiates Bitcoin from everything that came before it is that it is a TRUSTLESS SYSTEM.
I think most people support larger blocks overall, but don't support the additional logic being thrown into XT. It looks like Mike has turned block size into a red herring for other agenda, permitting him to take over bitcoin code and introduce other "features" that run counter to the trustless network that Bitcoin was designed to be.
Bingo. Unfortunately, the diehard XT supporters in here won't address legitimate critiques, whether of XT or BIP 101. They'd rather continue to act as if anyone who doesn't support XT is a "Blockstream shill" and continue shouting while knocking over straw men. That way, it's pretty easy to force the discussion onto the next page and gloss over thoughtful posts.
Every time I've brought up how the third party compilation of IP addresses is centralized and trust-adding, the standard response (in the unlikely event that an XT supporter actually responds to the argument) is that "oh, anyone running a node can disable that feature." That's not good enough. Nodes don't need a centralized, trusted list to tell them when someone is attacking them from a certain IP address. That's laughable.
Why would anyone want to introduce trust, when the objective can be achieved without it?
What does this have to do with BIP 101?
So the real issue is only whose boots are to be licked, Adam's or Mike's?
correct
^^-- LIKE
JorgeStolfi, if you read the thread topic, the goal is to not run software that does blacklisting, or more specifically, introduces centralized trust, which is a systemic risk and counter to the principles of Bitcoin. What differentiates Bitcoin from everything that came before it is that it is a TRUSTLESS SYSTEM.
I think most people support larger blocks overall, but don't support the additional logic being thrown into XT. It looks like Mike has turned block size into a red herring for other agenda, permitting him to take over bitcoin code and introduce other "features" that run counter to the trustless network that Bitcoin was designed to be.
Bingo. Unfortunately, the diehard XT supporters in here won't address legitimate critiques, whether of XT or BIP 101. They'd rather continue to act as if anyone who doesn't support XT is a "Blockstream shill" and continue shouting while knocking over straw men. That way, it's pretty easy to force the discussion onto the next page and gloss over thoughtful posts.
Every time I've brought up how the third party compilation of IP addresses is centralized and trust-adding, the standard response (in the unlikely event that an XT supporter actually responds to the argument) is that "oh, anyone running a node can disable that feature." That's not good enough. Nodes don't need a centralized, trusted list to tell them when someone is attacking them from a certain IP address. That's laughable.
Why would anyone want to introduce trust, when the objective can be achieved without it?
It'll still be "gavincoin" this and "altcoin" that, just with newer and lamer excuses. This is the internet, the flaming doesn't stop. 
Who needs flaming? The facts speak for themselves...
1. Mike proposes controversial idea after another over the years, always proposing to introduce centralization and trust to Bitcoin, which is built on decentralization and is a TRUSTLESS network.
2. Becomes a committer to Core in 2013.
3. Partners with Gavin
4. Tired of having his centralization ideas shot down, forks Bitcoin XT in June 2015. Establishes a "leadership hierarchy" for development in place of Core's consensus development. "Decisions are made according to a leadership hierarchy." Who is at the top of this hierarchy? Clearly, Mike has launched a fork where he is the dictator and can now get every bad idea of his that was ever rejected by both people in open discussions and the Core devs in an easy to download client. All of the features described on the site sound rosy, do not discuss any of the objections to those changes, and even outright claim there is no risk. All discussion of the client is to be discussed on a moderated forum he controls.
“The Bitcoin Core project has shown it cannot reform and so it must be abandoned.” Mike Hearn
By reformed, I presume he means will not permit Mike to erode its decentralization and trust-less foundation.
5. He uses block size as the red herring to promote XT, and a whole lot of nice words to make developers feel love at the bottom of his hierarchy.
“XT is about more than just the block size limit.” — Mike Hearn
6. He then proposes a ridiculous centralized scheme to Core that runs counter to the decentralized trustless concepts that Bitcoin was created to be. Read the entire discussion.
https://github.com/bitcoin/bitcoin/pull/6364
Based on what? Because his partner in crime, Gavin, claims to of suffered a DoS attack via Tor. No evidence was shared. There was no other node identified as being attacked. A little convenient, don't you think?
The devs gave really good reasons why this was not only a bad idea, but would do nothing to thwart DoS attacks as the vast majority will not occur through Tor exit nodes. Like always, Mike brushed off EVERY concern and line of reason with vague philosophical statements.
7. He then, of course, includes it in XT.
The concern people in this thread have is that people will download and install the client having no idea what can of worms they are unleashing, both on their systems, and the Bitcoin network.
Yes, there is a fork with only the block size change. But, will that be enough to thwart Mike's clear attempt to take over the Bitcoin protocol with nice marketing? Clearly, open discussion leading to insight is beneficial.
They really should have kept the difference between XT and Core the same EXCEPT the size limit. This Mike Hearn guy seems to get everybody's feathers ruffled on a regular basis like he's feeding on the fallout.
You asked, they delivered. Core + BIP 101 only.
https://www.reddit.com/r/bitcoinxt/comments/3hsc3f/bitcoinxt_with_just_the_patch_for_big_blocks_only/
I guess they caught on the people's mood. I'd still go for BIP100 now, but with this we could stop the XT Flaming.
Sorry, but I had to chuckle at that one. Would be nice if that was the end of it, but I don't think that's how it works. What happens is that someone finds a way to take something perfectly innocent and then twists it into the most vile and horrid thing imaginable, then plasters it all over the boards to cause a panic. The so-called "blacklist code" was never actually an issue, but they found a way to turn it into one because they wanted an issue. If they genuinely believed the code was an issue, they'd have simply asked for that particular code to be removed, but they didn't. It's the fork itself they actually disapprove of and they have to attack it in any way they can. Now that the big-blocks-only patch is available, they'll just find another molehill to transform into the worlds tallest mountain and start kicking up a load of undue fuss about that instead.
It'll still be "gavincoin" this and "altcoin" that, just with newer and lamer excuses. This is the internet, the flaming doesn't stop.
Indeed. You would think that Jamie Dimon had paid a bunch of JPMorgan Chase interns to "go disrupt that bitcoin thing" given the quality of arguments that have been tossed around.
They really should have kept the difference between XT and Core the same EXCEPT the size limit. This Mike Hearn guy seems to get everybody's feathers ruffled on a regular basis like he's feeding on the fallout.
You asked, they delivered. Core + BIP 101 only.
https://www.reddit.com/r/bitcoinxt/comments/3hsc3f/bitcoinxt_with_just_the_patch_for_big_blocks_only/
I guess they caught on the people's mood. I'd still go for BIP100 now, but with this we could stop the XT Flaming.
Sorry, but I had to chuckle at that one. Would be nice if that was the end of it, but I don't think that's how it works. What happens is that someone finds a way to take something perfectly innocent and then twists it into the most vile and horrid thing imaginable, then plasters it all over the boards to cause a panic. The so-called "blacklist code" was never actually an issue, but they found a way to turn it into one because they wanted an issue. If they genuinely believed the code was an issue, they'd have simply asked for that particular code to be removed, but they didn't. It's the fork itself they actually disapprove of and they have to attack it in any way they can. Now that the big-blocks-only patch is available, they'll just find another molehill to transform into the worlds tallest mountain and start kicking up a load of undue fuss about that instead.
It'll still be "gavincoin" this and "altcoin" that, just with newer and lamer excuses. This is the internet, the flaming doesn't stop.
They really should have kept the difference between XT and Core the same EXCEPT the size limit. This Mike Hearn guy seems to get everybody's feathers ruffled on a regular basis like he's feeding on the fallout.
You asked, they delivered. Core + BIP 101 only.
https://www.reddit.com/r/bitcoinxt/comments/3hsc3f/bitcoinxt_with_just_the_patch_for_big_blocks_only/
Does BIP 101 means those big blocks? I assumed it was somekinda encryption standard.
What is the difference on BIP 100, BIP 101 and BIP 102?
Still not convinced about this whole XT thing, got a baaad feeling about it.
BIP100 - miners vote - 1MB min, 32MB max and there is no code written yet
BIP101 - 750/1000 blocks voted for BIP101 starting in Jan 2016 trigger allowing up to 8MB blocks, doubling 2X every 2 yr, ending with 8GB in 2036
BIP102 - 17% increases annual starting in 2017. Approximately 2MB blocks by 2021.
XT = BIP101 + 5-6 non-consensus changes
They really should have kept the difference between XT and Core the same EXCEPT the size limit. This Mike Hearn guy seems to get everybody's feathers ruffled on a regular basis like he's feeding on the fallout.
You asked, they delivered. Core + BIP 101 only.
https://www.reddit.com/r/bitcoinxt/comments/3hsc3f/bitcoinxt_with_just_the_patch_for_big_blocks_only/
Does BIP 101 means those big blocks? I assumed it was somekinda encryption standard.
What is the difference on BIP 100, BIP 101 and BIP 102?
Still not convinced about this whole XT thing, got a baaad feeling about it.
They really should have kept the difference between XT and Core the same EXCEPT the size limit. This Mike Hearn guy seems to get everybody's feathers ruffled on a regular basis like he's feeding on the fallout.
You asked, they delivered. Core + BIP 101 only.
https://www.reddit.com/r/bitcoinxt/comments/3hsc3f/bitcoinxt_with_just_the_patch_for_big_blocks_only/
I guess they caught on the people's mood. I'd still go for BIP100 now, but with this we could stop the XT Flaming.
They really should have kept the difference between XT and Core the same EXCEPT the size limit. This Mike Hearn guy seems to get everybody's feathers ruffled on a regular basis like he's feeding on the fallout.
You asked, they delivered. Core + BIP 101 only.
https://www.reddit.com/r/bitcoinxt/comments/3hsc3f/bitcoinxt_with_just_the_patch_for_big_blocks_only/
Jump to: