Pages:
Author

Topic: ... - page 9. (Read 60963 times)

legendary
Activity: 1442
Merit: 1001
August 29, 2015, 07:19:13 PM
Don't you see how the 'dictator' arguments in FOSS and software forks is a logical fallacy? People exercising their free will but not doing what you want does not equal dictatorship.

This is actually why dictatorship often succeed. They give to "the people" the impression of a choice by encouraging them to exercise "their free will" when they are tired of waiting for traditional issue resolution processes.

This is textbook "why the worst people get on top".

If BIP 101 succeeds, what makes you think that I won't be able to switch back to Core or only-bigblocks with a different set of developers? Is Core just going to give up?

For BIP101 to succeed it needs to be merged into Core so I am not sure what you are talking about?


I presume that your concern about XT is that it and BIP 101 succeed without core adopting it, right? Most on this list don't really seem to be worried about that given that miners aren't jumping onboard (yet). If XT were to somehow 'takeover' then my point is that BIP101 would get merged into core since there's no way core would just continue on with <25% hashrate, no coinbase or bitpay, etc.

The point being is that no matter what big blocks BIP ends up being finally adopted, there will be and should be multiple software clients available to end users which makes some sort of dictatorship completely impossible.
hero member
Activity: 644
Merit: 504
Bitcoin replaces central, not commercial, banks
August 29, 2015, 07:03:06 PM
Don't you see how the 'dictator' arguments in FOSS and software forks is a logical fallacy? People exercising their free will but not doing what you want does not equal dictatorship.

This is actually why dictatorship often succeed. They give to "the people" the impression of a choice by encouraging them to exercise "their free will" when they are tired of waiting for traditional issue resolution processes.

This is textbook "why the worst people get on top".

If BIP 101 succeeds, what makes you think that I won't be able to switch back to Core or only-bigblocks with a different set of developers? Is Core just going to give up?

For BIP101 to succeed it needs to be merged into Core so I am not sure what you are talking about?



legendary
Activity: 1442
Merit: 1001
August 29, 2015, 06:57:53 PM
Don't you see how the 'dictator' arguments in FOSS and software forks is a logical fallacy? People exercising their free will but not doing what you want does not equal dictatorship.

This is actually why dictatorship often succeed. They give to "the people" the impression of a choice by encouraging them to exercise "their free will" when they are tired of waiting for traditional issue resolution processes.

This is textbook "why the worst people get on top".

If BIP 101 succeeds, what makes you think that I won't be able to switch back to Core or only-bigblocks with a different set of developers? Is Core just going to give up?
legendary
Activity: 1442
Merit: 1001
August 29, 2015, 06:56:33 PM

That's the issue - you have your "legitimate critiques" that "diehard XT supporters won't address" which seems to primarily be the Tor IP address list. Fine, so BIP 101 and only-bigblocks code allows you to run that without any anti-ddos protection and the supposed IP address centralization.

People have choices about what to run and are welcome to choose Core or only-bigblocks or some other BIP variation and yet you still want to bash away at XT. Do you have anything to add to the conversation or is it just 'blah, blah, centralization, IP addresses, trust, omg, Hearn, CIA'?

Excuse me? I've written quite a bit about why BIP 101 is reckless and there are more responsible solutions, and why painting the situation as "optional = okay" is problematic. This sort of baseless vitriol is insulting. And why can't you address the argument, rather than set up straw men like "omg, Hearn, CIA" which are irrelevant to anything I have said? This is what people mean by populism -- ignoring academic, technical and political arguments out of loyalty to their cause. Keep up good work ad hominem.

And why wouldn't you prefer to take the decentralized, trustless route (which is 100% doable) rather than simply assuming that it is innocent and supporting XT regardless of any features that it supports (and will presumably support in the future)? This just reeks of blind trust.
[/quote]

Vitriol is never good for the bitcoin community - apologies for any frustrations that I have with what I view are poor arguments.

I support XT primarily because I strongly believe that having a single bitcoin client is bad for the community - it implies that we have one small group of developers that lead without much of any check on their decisions. Yes, if the core team did something egregiously bad for the community, it would get rejected. However, any features that the community is interested in but aren't approved by essentially all 5 committers will have no chance to get tested.

I read the XT manifesto and for the most part, I think that it breathes some fresh air into a group of devs that is hostile toward not just ideas but individuals who try to contribute but don't have enough patience to deal with the personal attacks. To paraphrase Peter Todd from a recent meetup - "I would like to be working on tree chains, but the likelihood of that getting adopted is very low so instead I chose to work on something less controversial - checklocktimeverify." While this is fine, it does mean that a lot of developers that could be working in significant improvements may be sitting on the sidelines or choosing only the lowest hanging fruit since spending their time on anything that will get shot down is a waste of their time.

Regarding the IP addresses, I think it's a red herring. It's just not that important to me and you would be hard pressed to come up with a plausible scenario that will affect users. Regarding "blind trust" - this is also a terrible argument. This is FOSS. Everyone can review the code or rely on a trusted community member to review the code before running it. I never have to upgrade XT or Core if I don't want to. How is XT blind trust when Core is something else?
hero member
Activity: 644
Merit: 504
Bitcoin replaces central, not commercial, banks
August 29, 2015, 06:46:47 PM
Don't you see how the 'dictator' arguments in FOSS and software forks is a logical fallacy? People exercising their free will but not doing what you want does not equal dictatorship.

This is actually why dictatorship often succeed. They give to "the people" the impression of a choice by encouraging them to exercise "their free will" when they are tired of waiting for traditional issue resolution processes.

This is textbook "why the worst people get on top".
sr. member
Activity: 504
Merit: 250
Earn with impressio.io
August 29, 2015, 06:40:51 PM
I'll never climb the "leadership hierarchy" if I try that.

Yeah, someone might call you a dictator for giving people a choice. Smiley

Right now, just a dictator of a tiny island with nuclear missiles pointed at the Bitcoin network.  But, if XT succeeds, he could become dictator of the Bitcoin protocol.  

Riiight. Wouldn't this only happen if, oh, the majority of people running XT nodes thought you were dead wrong? How exactly can a fork of bitcoin create a dictatorship? If the users didn't like the code, it would be re-forked and users would run right back to Core or another version.

Don't you see how the 'dictator' arguments in FOSS and software forks is a logical fallacy? People exercising their free will but not doing what you want does not equal dictatorship.

This is more about if they switch their code to XT from Core, and let's say that Core loses its momentum.  It wouldn't be so easy to switch back.  Everyone talk as if a single client is what matters.  It is the network as a whole.  Control the clients, you control the network.  

If you consider his bias towards centralization, and his new development model where he can do whatever he wants unopposed in XT, if XT had a critical mass of installs, he could change the network in a way that would make it very hard to leave.  Perhaps leaving could end up putting your node on an untrusted ban list.  

To be sure, this is big picture and a long-shot.  But, given the proposals of Mike over the years, and his new status as king of all XT commits, and XT's clear plans to dominate the network, it is not beyond imagination to see how, even in the bitcoin world, we have to counter dictators BEFORE they rise to power. Is this really any different than 1000s of years of history, except this is now in a new virtual world that most end-users do not want to begin to understand?  There isn't a whole of of accuracy from the mass media reporting on the detailed concerns of this fork.


hero member
Activity: 756
Merit: 502
CryptoTalk.Org - Get Paid for every Post!
August 29, 2015, 06:35:46 PM
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.

Sure. There is also nothing wrong with debating the merits of any of the options -- particularly when there are so many people that are conflating support of BIP 101 with support of XT (ie. there are two options: XT, which means big blocks OR the 1MB status quo). In reality, there are many options, including BIPs that have already been proposed.

So the real issue is only whose boots are to be licked, Adam's or Mike's?

correct Wink

^^-- 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.

That's the issue - you have your "legitimate critiques" that "diehard XT supporters won't address" which seems to primarily be the Tor IP address list. Fine, so BIP 101 and only-bigblocks code allows you to run that without any anti-ddos protection and the supposed IP address centralization.

People have choices about what to run and are welcome to choose Core or only-bigblocks or some other BIP variation and yet you still want to bash away at XT. Do you have anything to add to the conversation or is it just 'blah, blah, centralization, IP addresses, trust, omg, Hearn, CIA'?

Excuse me? I've written quite a bit about why BIP 101 is reckless and there are more responsible solutions, and why painting the situation as "optional = okay" is problematic. This sort of baseless vitriol is insulting. And why can't you address the argument, rather than set up straw men like "omg, Hearn, CIA" which are irrelevant to anything I have said? This is what people mean by populism -- ignoring academic, technical and political arguments out of loyalty to their cause. Keep up the good work ad hominem.

And why wouldn't you prefer to take the decentralized, trustless route (which is 100% doable) rather than simply assuming that it is innocent and supporting XT regardless of any features that it supports (and will presumably support in the future)? This just reeks of blind trust.
legendary
Activity: 1442
Merit: 1001
August 29, 2015, 06:27:36 PM
I'll never climb the "leadership hierarchy" if I try that.

Yeah, someone might call you a dictator for giving people a choice. Smiley

Right now, just a dictator of a tiny island with nuclear missiles pointed at the Bitcoin network.  But, if XT succeeds, he could become dictator of the Bitcoin protocol.  

Riiight. Wouldn't this only happen if, oh, the majority of people running XT nodes thought you were dead wrong? How exactly can a fork of bitcoin create a dictatorship? If the users didn't like the code, it would be re-forked and users would run right back to Core or another version.

Don't you see how the 'dictator' arguments in FOSS and software forks is a logical fallacy? People exercising their free will but not doing what you want does not equal dictatorship.
legendary
Activity: 1442
Merit: 1001
August 29, 2015, 06:25:44 PM
So the real issue is only whose boots are to be licked, Adam's or Mike's?

correct Wink

^^-- 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.

That's the issue - you have your "legitimate critiques" that "diehard XT supporters won't address" which seems to primarily be the Tor IP address list. Fine, so BIP 101 and only-bigblocks code allows you to run that without any anti-ddos protection and the supposed IP address centralization.

People have choices about what to run and are welcome to choose Core or only-bigblocks or some other BIP variation and yet you still want to bash away at XT. Do you have anything to add to the conversation or is it just 'blah, blah, centralization, IP addresses, trust, omg, Hearn, CIA'?
sr. member
Activity: 504
Merit: 250
Earn with impressio.io
August 29, 2015, 06:19:10 PM
I'll never climb the "leadership hierarchy" if I try that.

Yeah, someone might call you a dictator for giving people a choice. Smiley

Right now, just a dictator of a tiny island with nuclear missiles pointed at the Bitcoin network.  But, if XT succeeds, he could become dictator of the Bitcoin protocol. 
legendary
Activity: 2296
Merit: 1014
August 29, 2015, 06:12:20 PM
just vote with client, bitcoin core or xt
this extra features are only temporary since if bitcoin xt will win, bitcoin core will adjust and you could switch back from xt
newbie
Activity: 42
Merit: 0
August 29, 2015, 06:10:15 PM
I'll never climb the "leadership hierarchy" if I try that.

Yeah, someone might call you a dictator for giving people a choice. Smiley
newbie
Activity: 42
Merit: 0
August 29, 2015, 05:59:36 PM
If its purely client side, it also mean even the code isint included in the "core XT" branch, people would still be able to use the DDoS protection module if they so desire by using the other version.

Yes, you're right.
sr. member
Activity: 504
Merit: 250
Earn with impressio.io
August 29, 2015, 05:45:37 PM
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.

#4 Ahahahahah *deep breath* ahahahhaha

I'll never climb the "leadership hierarchy" if I try that.

You forgot option 6: Vote for XT2

https://bitcointalksearch.org/topic/bitcoin-xt2-proposed-1165957

NOTE: Nay votes may also paint their roofs red, where we will tally via Google Earth.
full member
Activity: 196
Merit: 100
August 29, 2015, 05:42:53 PM
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.



Are you not understanding what i am saying? If you take the source and modify the code, its not the same coin anymore. So unless the IP list is exempted...

Oh i didnt know that, thanks for telling me.


Nobody should argue with you now, they must not understand this.



But regardless, you can disable to "DDoS protection" for your node by using a flag. And i also think they released a candidate with absolutely no code except BIP101. So this shouldn't be an issue anymore.

LOL speechless.

I think i will vote you to be the lead dev of the core team.
legendary
Activity: 1302
Merit: 1068
August 29, 2015, 05:42:18 PM
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.

It depends what you modify. DDOS protection among other additions is just a client feature and doesn't affect compatibility with the protocol, while blocksize limit needs to be same in all clients (thus requiring a blockchain fork if changed).

Thanks for the clarification. I really just don't know how deeply embedded that portion was. If its purely client side, it also mean even the code isint included in the "core XT" branch, people would still be able to use the DDoS protection module if they so desire by using the other version.
newbie
Activity: 42
Merit: 0
August 29, 2015, 05:39:16 PM
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.

It depends what you modify. DDOS protection among other additions is just a client feature and doesn't affect compatibility with the protocol, while blocksize limit needs to be same in all clients (thus requiring a blockchain fork if changed).

There is no single correct client for bitcoin. As long as the client follows the protocol it works. It's like there's not a single correct web browser. You can use Chrome, Firefox or make one of your own..as long as it's compatible with basic rules it works.
legendary
Activity: 1302
Merit: 1068
August 29, 2015, 05:38:23 PM
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.



Are you not understanding what i am saying? If you take the source and modify the code, its not the same coin anymore. So unless the IP list is exempted...

Oh i didnt know that, thanks for telling me.


Nobody should argue with you now, they must not understand this.



But regardless, you can disable to "DDoS protection" for your node by using a flag. And i also think they released a candidate with absolutely no code except BIP101. So this shouldn't be an issue anymore.
full member
Activity: 196
Merit: 100
August 29, 2015, 05:35:50 PM
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.



Are you not understanding what i am saying? If you take the source and modify the code, its not the same coin anymore. So unless the IP list is exempted...

Oh i didnt know that, thanks for telling me.


Nobody should argue with you now, they must not understand this.

legendary
Activity: 1302
Merit: 1068
August 29, 2015, 05:30:25 PM
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.



Are you not understanding what i am saying? If you take the source and modify the code, its not the same coin anymore. So unless the IP list is exempted...
Pages:
Jump to: