On Thu, May 7, 2015 at 4:05 PM, Mike Hearn <m...@plan99.net> wrote: >> If his explanation was "I will change my mind after we increase block >> >> size", I guess the community should say "then we will just ignore your >> nack because it makes no sense". > > > Oh good! We can just kick anyone out of the consensus process if we think > they make no sense. > > I guess that means me and Gavin can remove everyone else from the developer > consensus, because we think trying to stop Bitcoin growing makes no sense. > > Do you see the problem with this whole notion? It cannot possibly work. > Whenever you try and make the idea of developer consensus work, what you end > up with is "I believe in consensus as long as it goes my way". Which is > worthless.
That is not what I said. Then you demonstrated that it was absurd. That's called a straw man argument and it's a well known fallacy, it is precisely the example of arguments that can be safely ignored. It is an argument against my admittedly vague definition of "non-controversial change". More importantly, I never said anything about "removing anyone", I was always talking about arguments and not people. One person could use fallacious arguments to attack or defend a given proposal and use perfectly valid ones in another, a person can even mix valid and invalid arguments in the same mail. >> One thing is the Bitcoin core project where you could argue that the 5 >> committers decide (I don't know why Wladimir would have any more >> authority than the others). > > > Because he is formally the maintainer. Yes, the maintainer of the Bitcoin core free software project (I cannot stressed this enough, that can be forked by anyone), not the president of Bitcoin the p2p network. > Maybe you dislike that idea. It's so .... centralised. So let's say Gavin > commits his patch, because his authority is equal to all other committers. > Someone else rolls it back. Gavin sets up a cron job to keep committing the > patch. Game over. > > You cannot have committers fighting over what goes in and what doesn't. > That's madness. There must be a single decision maker for any given > codebase. I'm sure that if they become that stupid, developers would move to a fork of the project in no time. >> Ok, so in simple terms, you expect people to have to pay enormous fees >> and/or wait thousands of blocks for their transactions to get included >> in the chain. Is that correct? > > > No. I'll write an article like the others, it's better than email for more > complicated discourse. Ok, thanks in advance. >> As others have said, if the answer is "forever, adoption is always the >> most important thing" then we will end up with an improved version of Visa. > > > This appears to be another one of those fundamental areas of disagreement. I > believe there is no chance of Bitcoin ending up like Visa, even if it is > wildly successful. I did the calculations years ago that show that won't > happen: > > https://en.bitcoin.it/wiki/Scalability > > Decentralisation is a spectrum and Bitcoin will move around on that spectrum > over time. But claiming we have to pick between 1mb blocks and "Bitcoin = > VISA" is silly. Again, I didn't say any of that. My point is that a network that becomes too "centralized" (like visa, that is centralized vs p2p, not vs distributed) doesn't offer any security or decentralization advantage over current networks (and of course I meant that could happen with larger blocks, not 1 MB blocks). I'm sure that's not what the proponents of the size increase want, and I'm not defending 1 MB as a sacred limit or anything, but my question is "where is the limit for them?" Even a limitless block size would technically work because miners would limit it to limit the orphan rate. So "no hardcoded consensus limit on transaction volume/block size" could be a valid answer to the question "what is the right consensus limit to block size?" for which there's no real right answer because there is a tradeoff between transaction volume and centralization. Should we maintain 1 MB forever? Probably not. Is 20 MB a bad size? I honestly don't know. Is this urgent? I don't think so. Should we rush things when we don't have clear answers to many related questions? I don't think so. You think that it is too soon to start restricting transaction volume in any way. You will answer why in your post. When is the right time and what is the right limitation then? I want to have fee competition as soon as possible, at least temporarily. But you say that it can wait for later. Ok, when do you think we should make that happen then? When 20 MB are full, will that be the right time to let the fee market develop then or will it be urgent to increase the block size again? Should we directly remove the limit then and let miners handle it as they want? If so, why not now? Maybe we can increase to 2 MB, then wait for fee competition, then wait for 2 more subsidy halvings and then increase to 11 or 20 MB? There's so many possibilities that I don't understand how can be surprising that "20 MB, as soon as possible" is not the obvious answer to everyone... ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y _______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development