public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Hector Chu <hectorchu@gmail.com>
To: Eric Lombrozo <elombrozo@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] A reason we can all agree on to increase block size
Date: Mon, 3 Aug 2015 10:22:19 +0100	[thread overview]
Message-ID: <CAAO2FKEzzYaHa9ZOC1Dq-F1RK61X9dt=2cvq97p2yOzYhLSCMQ@mail.gmail.com> (raw)
In-Reply-To: <9D6A80DF-83E6-4F98-B7C2-2EE2F79CB2D1@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 5095 bytes --]

On 3 August 2015 at 10:01, Eric Lombrozo <elombrozo@gmail.com> wrote:

> I agree. But again, once we’ve identified specific issues, it is
> irresponsible to continue to pretend they don’t exist…and to more highly
> prioritize changes that can only make the problem worse.
>

> Again, for the record, I am not against ultimately allowing bigger blocks.
> I think it would be a good thing to be able to do this…and my main concerns
> are not around things like equipment costs or typical household bandwidth.
> I just think security is a more important feature than greater throughput
> and prioritize it thusly.
>

Security is an ongoing incremental process and everyone is giving it the
highest priority. Forgive me for being a bit behind on this - are you able
to point me to the potential solutions for the problems that were
identified from the unintentional hard forks?


> I don’t disagree…clearly even the miners that lost money believed that
> consensus was more valuable to them than a few bitcoins. However, it seems
> to be EXTREMELY dangerous to assume that it will always work out this way.
> What’s to stop a mining majority from deciding on-the-fly they want to keep
> a particular consensus rule that benefits them even if the core developers
> disagree?
>

The users of Bitcoin are living in a free world. Bitcoin like many
political systems requires the cooperation of the majority. If a majority
of miners decide to change the rules to benefit only themselves then the
system will quickly lead to collapse, until a new system arising from the
ashes of the previous one is erected.

In fact the situation is more optimistic than this. Miners don't set the
rules, the economic majority does. The miners must follow the rules that
are acceptable by the economic majority, or quickly go out of business.


>
>> - Eric
>>
>> On Aug 3, 2015, at 1:31 AM, Hector Chu <hectorchu@gmail.com> wrote:
>>
>> What's wrong with a little cooperation to resolve things now and then?
>> Man is not an island unto himself, we compete with each other and we
>> cooperate with each other occasionally if it's mutually beneficial.
>>
>> You said yourself that a lot of money would have been lost if the two
>> hard forks cited weren't resolved - that's the correct incentives at work
>> again.
>>
>> On 3 August 2015 at 09:20, Eric Lombrozo <elombrozo@gmail.com> wrote:
>>
>>> There have already been two notable incidents requiring manual
>>> intervention and good-faith cooperation between core devs and mining pool
>>> operators that would have either never gotten resolved alone or would have
>>> ended up costing a lot of people a lot of money had no action been taken
>>> (March 2013 and July 2015). They were both caused by consensus disagreement
>>> that directly or indirectly were brought about by bigger blocks. There is
>>> *strong* evidence…and a great deal of theory explaining it…that links
>>> larger blocks with the propensity for consensus forks that require manual
>>> intervention.
>>>
>>> Please, can we stop saying this is merely about decentralization and
>>> trustlessness? The very model upon which the security of the system is
>>> based *broke*…as in, we were only able to recover because a few individuals
>>> deliberately manipulated the consensus rules to fix it manually. Shouldn’t
>>> we more highly prioritize fixing the issues that can lead to these
>>> incidents than trying to increase throughput? Increasing block size cannot
>>> possibly make these forking tendencies better…but it very well could make
>>> them worse.
>>>
>>> - Eric
>>>
>>> On Aug 3, 2015, at 1:06 AM, Hector Chu via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>> On 3 August 2015 at 08:53, Adam Back <adam@cypherspace.org> wrote:
>>>
>>>> Again this should not be a political or business compromise model - we
>>>> must focus on scientific evaluation, technical requirements and
>>>> security.
>>>>
>>>
>>> I will assert that the block size is political because it affects nearly
>>> all users to some degree and not all those users are technically inclined
>>> or care to keep decentralisation in the current configuration as you do.
>>> This debate has forgotten the current and future users of Bitcoin. Most of
>>> them think the hit to node count in the short term preferable to making it
>>> expensive and competitive to transact.
>>>
>>> We all need a little faith that the system will reorganise and readjust
>>> after the move to big blocks in a way that still has a reasonable degree of
>>> decentralisation and trustlessness. The incentives of Bitcoin remain, so
>>> everyone's decentralised decision throughout the system, from miners,
>>> merchants and users, will continue to act according to those incentives.
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>>
>>>
>>
>>
>
>

[-- Attachment #2: Type: text/html, Size: 7514 bytes --]

  reply	other threads:[~2015-08-03  9:22 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-02 21:02 [bitcoin-dev] A reason we can all agree on to increase block size Jim Phillips
2015-08-03  1:21 ` Pindar Wong
2015-08-03  4:33   ` Jim Phillips
2015-08-03  3:13 ` odinn
2015-08-03  6:34 ` Adam Back
2015-08-03  6:53   ` Jim Phillips
2015-08-04 10:53     ` Jorge Timón
2015-08-03  7:16   ` Simon Liu
2015-08-03  7:34     ` Hector Chu
2015-08-03  7:53       ` Adam Back
2015-08-03  8:06         ` Hector Chu
2015-08-03  8:20           ` Eric Lombrozo
2015-08-03  8:31             ` Hector Chu
2015-08-03  8:38               ` Eric Lombrozo
2015-08-03  8:52                 ` Hector Chu
2015-08-03  9:01                   ` Eric Lombrozo
2015-08-03  9:22                     ` Hector Chu [this message]
2015-08-03  7:46     ` Adam Back
2015-08-03 13:57   ` Michael Ruddy

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAAO2FKEzzYaHa9ZOC1Dq-F1RK61X9dt=2cvq97p2yOzYhLSCMQ@mail.gmail.com' \
    --to=hectorchu@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=elombrozo@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox