Re: [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M

[Adam Back <adam@cypherspace.org>]

There is a difference between miners signalling intent (as they have
been for various BIPs, which is mostly informational only - they are
mostly not running the code, and in some cases it is not implemented,
so they cant be) there is a difference between that and a 95% miner
majority consensus rule.  Former can be useful information as you
said, latter implies as Luke described something that is not really
accurate, it is not strictly only a miner upgrade needed for basic
safety as with soft-forks.  If you look at BIP 103 for example it is
flag day based, and I think this is a more accurate approach.  Also
with miner votes they can be misleading - vote for one thing, but run
something else; what they are running is not generally
detectable/enforceable - see for example what happened with the BIP66
accidental fork due to "SPV mining" (ie validationless mining).

A hard-fork is for everyone to upgrade and talk with each other to see
that the vast majority is on the same plan which includes users,
ecosystem companies & miners.

Adam

On 14 November 2015 at 01:02, digitsu412 via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Well I'd like to think that with an economy all parts of it interact with
> each other in ways more complex than simplistic imperative logic.
>
> I agree that the economic majority is essentially what matters in a hard
> fork but everyone (miners,devs,public thought leaders,businesses) is part of
> that economy. Additionally what miners signal as their intention affects the
> decision of that economic majority (and vice versa).  You can see the
> effects of this in traditional political processes in how preliminary vote
> polling results affect (reinforce) the final vote.
> We also can see the results of this in (dare I mention) the whole XT affair
> which had the signed intent of many of the economy (payment processors and
> wallets and one miner pool) and the rest of the miners did not go along with
> it. This experiment either means that the rest of the miners couldn't be
> bothered to signal at all (because they didn't know how) or they were
> affected by the influence of core devs or the opinions of others on the
> matter and rejected the economic majority.  (Which would imply core devs
> have some power by way of indirect influence) I would be inclined to believe
> the latter was more likely.
>
> The conclusion which this would seem to imply is that at the very least,
> miners matter (to what exact extent is debatable).  And although there is no
> direct control of any party over the other in the strict sense, the public
> vocal opinions of any part of the Bitcoin economy does have an effect in its
> ability to sway the opinions of the other parts.
>
> Digitsu
>
> — Regards,
>
>
> On Sat, Nov 14, 2015 at 7:29 AM, Luke Dashjr <luke@dashjr.org> wrote:
>>
>> On Friday, November 13, 2015 4:01:09 PM digitsu@gmail.com wrote:
>> > Forgive the frankness but I don't see why signaling your intent to
>> > support
>> > an upgrade to one side of a hard fork can be seen as a bad thing. If for
>> > nothing else doesn't this make for a smoother flag day? (Because once
>> > you
>> > signal your intention, it makes it hard to back out on the commitment.)
>>
>> It isn't a commitment in any sense, nor does it make it smoother, because
>> for
>> a hardfork to be successful, it is the *economy* that must switch
>> entirely.
>> The miners are unimportant.
>>
>> > If miners don't have any choice in hard forks, who does? Just the core
>> > devs?
>>
>> Devs have even less of a choice in the matter. What is relevant is the
>> economy: who do people want to spend their bitcoins with? There is no
>> programmatic way to determine this, especially not in advance, so the best
>> we
>> can do is a flag day that gets called off if there isn't clear consensus.
>>
>> Luke
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>