Re: [Bitcoin-development] Block Size Increase

["Jorge Timón" <jtimon@jtimon.cc>]

On Thu, May 7, 2015 at 4:05 PM, Mike Hearn <mike@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...