public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Adam Back <adam@cypherspace.org>
To: digitsu@gmail.com
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	John Sacco <johnsock@gmail.com>
Subject: Re: [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M
Date: Sat, 14 Nov 2015 10:31:18 +0100	[thread overview]
Message-ID: <CALqxMTFE9W0nxGHvcJN_Wz88b00o-K29GRTbHJv+VSpYAJKUNQ@mail.gmail.com> (raw)
In-Reply-To: <1447459320911.325f57c8@Nodemailer>

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
>


  reply	other threads:[~2015-11-14  9:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-12 23:47 [bitcoin-dev] BIP - Block size doubles at each reward halving with max block size of 32M John Sacco
2015-11-13  2:56 ` Chun Wang
2015-11-13  3:37   ` John Sacco
2015-11-13  7:49     ` Btc Drak
2015-11-13  9:50       ` John Sacco
2015-11-13 10:52         ` Luke Dashjr
     [not found]           ` <1447430469019.e0ee1956@Nodemailer>
2015-11-13 22:28             ` Luke Dashjr
2015-11-14  0:02               ` digitsu
2015-11-14  9:31                 ` Adam Back [this message]
2015-11-14 10:52                   ` Jorge Timón
2015-11-14 21:11                     ` Luke Dashjr
     [not found]                       ` <CADZB0_Z3Kf4GW0VATjb10kJF0aFgyFOcqX_=y+LFoUpsi+TRUA@mail.gmail.com>
2015-11-14 21:27                         ` Luke Dashjr
2015-11-15 12:16                           ` Jorge Timón
     [not found]                             ` <CABEog-XUNt9kDS7Mc0XYFjm5ePUT0m1YaAoG9VypTCiGLBongQ@mail.gmail.com>
2015-11-18 10:15                               ` Jorge Timón
2015-11-13  6:39   ` Luke Dashjr

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=CALqxMTFE9W0nxGHvcJN_Wz88b00o-K29GRTbHJv+VSpYAJKUNQ@mail.gmail.com \
    --to=adam@cypherspace.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=digitsu@gmail.com \
    --cc=johnsock@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