sr. member
Activity: 409
Merit: 286
@Lauda
I appreciate we establish a civlized, intelligent conversation about arguments, not insult, in a thread that was made to insult.
While we do it, someone let the hooligans out which yell from the sideline
I don't care about such kind of childish hatefull chorus, but I have a hard time to understand why you and your co-moderators tolerate that these people rampage your forum and damage the reputation of knowledged small blockers like you and the core developers.
I was really really shocked that
this quote from brg444 was not deleted:
If you say moderators are independent, I believe you. But it's hard to believe that every moderator in this forum came freely to the conclusion that there should be no alternative client who violates consensus and that the blocks should not be raised now. It sounds more like the unity of a party than of free men. Or did I miss something?
Every moderator? No. While quite a lot have not expressed their views strongly like I have, there are others that have. E.g. Hostfat, he is in a strong disagreement with theymos on the matter (I think he even supports XT, I'm not sure).
That's kind of interesting. Thank you @Hostfat for you comment in this thread. Are you still moderator? Are you allowed to promote XT or any other forkcoin? Why are you still a moderator here?
I just know that in the german section I once postet a link to my blog where I did write about Bitcoins unsecure future and XT as an instrument to pressure devs to solve the scalability-problem, and this post was moved to altcoins, even as anybody did know that I wrote about Bitcoin and not an altcoin, and made some controversial, but valid point about the future and the government of bitcoin. This was the reason I thought the moderation policy "Don't talk about alternate clients with consensus critical change in bitcoin-sections" was enforced by every moderator of every section.
Tell me more about the 8MB blocks. What could they do? I follow this debate for long, more on reddit then here, but - I never heard really confessing reasons for not raising the limit. Bandwith? Space? CPU? Node-Centralization? Mega-Transactions? None of this problem seemed like a problem large enough to stall development of bitcoin and / or scaling it completely in a way that's not the original bitcoin (lightning).
This is what I was referencing (such blocks might occur):
Thanks for sharing. I read the roadmap-faq (and I find the roadmap a solution that could be quiet reasonable, especially with the now mentioned 2-4-8 approach after IBLT and thin blocks ...).
So I did know about that hard-to-verify transaction. But I never understood why this is such a big problem. If I send now a 2MB-Transaktion with my node - will other nodes validate it? If not - why not? Do other nodes have a limit of transactions that are valid? And what's the problem with making nodes say: "max-tx-size=1MB"? I have a really hard time to believe that this is a major problem. It would be quiet ironic after all if this would become the problem that makes bitcoin failing.
The other thing I deeple disargue with you is, as other people said: You and your team seem not to be willing to allow a free market of alternative clients and you hinder the community to collect informations to express their opinion with the choice of the client. This is a major democratic element in open source and in bitcoin, it's the major mechanism to protect bitcoin for an destructive takeover by developers (I explicitly don't mint this on Core!). If you deny and surpress this possibility, - what you say you do - you are no longer in a consensus of democracy. And bitcoin needs its own kind of democracy to survice.
When I see a good alternative that isn't biased by various suspicious people, then I might consider it. I would be okay with a decent alternative implementation, but you do have to admit that more implementations make the ecosystem more complex. This isn't good if one wants to keep Bitcoin simpler while introducing it to more people (e.g.Telling someone that they have to choose between X, Y, Z implementations).
Yes, I'm completely aware that the more clients, the more complexity and the more fragmentation of the development and the eco-system. If every client has its own developers, we'll face insufficient developer-communication and development-redundancy, and if every exchange and payment-provider and wallet has to integrate different clients and make them compatible, we will loose a lot of development-time. As I said in the conversation with Veritas in this thread, I also fear that a fragmentation of bitcoin can destroy the ecosystem.
BUT ...
You have to admit that solutions like SW and LN also add complexity to the ecosystem.+
Also, and Imho more important, the development and usage of different clients with, in the worst case, critical consensus changes, is the only instrument for the ecosystem to 1. express their unsatisfaction with core-development, 2. protect the system against a takeover of development and 3. enforce a consensus by pressure
I think these are integral parts of Bitcoin as a system and shouldn't be thrown away out of fear of a hard fork. We are far away from an hard fork, all alternate clients out there need to get a lot more support by nodes and miners to even think about forking the system. If they reach this point all it needs to prevent a split is core changing their minds and make a little step to big blockers. For example, if core accepts the solution brought in the game some days ago by a well-known payment-provider, i think this whole debate would be over in less than a week.
So at the moment I see more advantages by competing clients with competing consensus rules than in the prevention of this competition.
At last, I don't agree with you to rejecting alternate clients by some prejudicement of their developers. If you'd ask me about the integrity of core, I'd say it suffers heaviliy from the small block militia and that I'm skeptical to their biasment cause they don't distance themself from this kind of hooligans and from the restrictions in free speach that HostFat also criticizes. But if core presents good code, I'll run it. From the alternatives I like some, and dislike some other - I'm not sure if I'm allowed to talk about them explicitly - but this has nothing to do with the persons behind it.