From: Luke Dashjr <luke@dashjr.org>
To: Gavin Andresen <gavinandresen@gmail.com>
Date: Sat, 6 Feb 2016 20:36:23 +0000
User-Agent: KMail/1.13.7 (Linux/4.1.13-gentoo; KDE/4.14.8; x86_64; ; )
References: <CABsx9T1Bd0-aQg-9uRa4u3dGA5fKxaj8-mEkxVzX8mhdj4Gt2g@mail.gmail.com>
	<CABm2gDrns0+eZdLyNk=tDNbnMsC1tT1MfEY93cJf1V_8TPjmLA@mail.gmail.com>
	<CABsx9T2LuMZciXpMiY24+rPzhj1VT6j=HJ5STtnQmnfnA_XFUw@mail.gmail.com>
In-Reply-To: <CABsx9T2LuMZciXpMiY24+rPzhj1VT6j=HJ5STtnQmnfnA_XFUw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: 7bit
Message-Id: <201602062036.25979.luke@dashjr.org>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP proposal: Increase block size limit to 2
	megabytes
Precedence: list

On Saturday, February 06, 2016 3:37:30 PM Gavin Andresen wrote:
> I suspect there ARE a significant percentage of un-maintained full nodes--

Do you have evidence these are intentionally unmaintained, and not users who 
have simply not had time to review and decide on upgrading?

> There is broad agreement that a capacity increase is needed NOW.

If so, it is only based on misinformation. I am concerned you are implying 
this conclusion is true. When I spoke with you maybe a year ago with my 
concerns that block size might grow too fast, you suggested that the miners 
could be trusted to not increase the block size until necessary (which is not 
likely to be any time soon, despite the massive misinformation campaigns out 
there).

> On Sat, Feb 6, 2016 at 1:12 AM, Luke Dashjr via bitcoin-dev
> > > > Miners express their support for this BIP by ...
> > > 
> > > But miners don't get to decide hardforks. How does the economy
> > > express their support for it? What happens if miners trigger it
> > > without consent from the economy?
> 
> "The economy" does support this.

I have seen evidence which suggests the contrary. For example:
    https://twitter.com/barrysilbert/status/694911989701861376


Where is yours?

> > If you are intent on using the version bits to trigger the
> > hardfork, I suggest rephrasing this such that miners should
> > only enable the bit when they have independently confirmed
> > economic support (this means implementations need a config
> > option that defaults to off).
> 
> Happy to add words about economic majority.
> 
> Classic will not implement a command-line option (the act of running
> Classic is "I opt in"), but happy to add one for a pull request to Core,
> assuming Core would not see such a pull request as having any hostile
> intent.

But this isn't about the miner opting in, it is about the miner *observing 
economic support* for the change. I have successfully downloaded Bitcoin 
Classic's beta binaries without ANY warning that by running it, I am 
expressing that I believe the economy has approved of a hardfork.

> > > SPV (simple payment validation) wallets are compatible with this
> > > change.
> > 
> > Would prefer if this is corrected to "Light clients" or something.
> > Actual SPV wallets do not exist at this time, and would not be
> > compatible with a hardfork.
> 
> Is there an explanation of SPV versus "Light Client" written somewhere more
> permanent than a reddit comment or forum post that I can point to?

Not that I am aware of. (But both reddit comments and forum posts have  
outlived many other posts, such as blogs, so I'm not sure why to exclude them 
specifically...)

In any case, since SPV nodes don't exist, there is probably no real need to 
address them. Everyone will know what "light client" means.
 
> > I would also prefer to see any hardfork:
> > 2. Be deployed as a soft-hardfork so as not to leave old nodes entirely
> > insecure.
> 
> I haven't been paying attention to all of the
> "soft-hardfork/hard-softfork/etc" terminology so have no idea what you
> mean. Is THAT written up somewhere?

Working on a BIP draft for it, but it's not ready for publication yet. The 
basic idea is to turn the merkle root in the block header into simply a hash 
of a second block header, which is constructed to parse as a valid empty 
generation transaction under the old rules. Thus, old nodes see the forked 
blockchain as valid with continually growing work on it, but as if the blocks 
were all empty. This protects them from attackers mining a short blockchain 
they perceive as valid.

Luke