Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 9DEC1273 for ; Fri, 21 Aug 2015 12:29:03 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f200.google.com (mail-ig0-f200.google.com [209.85.213.200]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C8CD513A for ; Fri, 21 Aug 2015 12:29:02 +0000 (UTC) Received: by igcse8 with SMTP id se8so26768845igc.1 for ; Fri, 21 Aug 2015 05:29:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=coinapex.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=HMdrNMFet2je8DYRGzIIosqERDd6fytGPGrincs+jH0=; b=WElp5LGgEPes1kCLnwybP00xumFKVqW78iXEF03fWLMpkcCDvEtFFU7IVYNkkocqBk UkYx+RAQ1Pjf/xP98gIeTyaNYgPNhiHsJ+MMvaxddlXUhuyTgF27057jiOBa0yaYaeAn w3Bjh9arYhjotdZg3W9rduRzWF3rYm/1tuS6c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=HMdrNMFet2je8DYRGzIIosqERDd6fytGPGrincs+jH0=; b=K2r3rixvW29/MwGFbux4M7qAqVeNPA2xIRWtvYQG2w6eRxhOIXnZiM51W+nM1J9nUw hi1KXuXDhhxUydOOfGk85x0uaeYKgLeH71LD3WUrr0wYHiFfm/QBYDzmX07Q6D7TB0Hp zYH4+M3wAx90bROpkmSsTjiEov088OUA/9Auwkl7SaakwJMgJC0pOSBfW/UdvfftQ7m3 6rSCmDqVUg3aCZmWjbJR0TCc9+nKfFMzAv/R55lgJ6eMD9tk0uGkHztZnxWEwAgDINfO jtsJVQxr5PwV/TxthjdvQUrqJVtvHmBa/ka31ekKsXrHGvAvOdPquAnhTKstpt8ww9Cm N5RQ== X-Gm-Message-State: ALoCoQmlwq1Y4p1VEylhpoeWOfy/HCjPZSVPPAlP8Ap1rmBSiojgL6UZUNUzrSgD8r3xXf5yhfpa X-Received: by 10.60.93.99 with SMTP id ct3mr7933430oeb.56.1440160142127; Fri, 21 Aug 2015 05:29:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.84.69 with HTTP; Fri, 21 Aug 2015 05:28:22 -0700 (PDT) In-Reply-To: References: <3B2A58B3-6AF6-4F1C-A6FA-7AEC97F48AD0@petertodd.org> From: Yifu Guo Date: Fri, 21 Aug 2015 08:28:22 -0400 Message-ID: To: Gregory Maxwell via bitcoin-dev Content-Type: multipart/alternative; boundary=047d7b33d952b11072051dd16959 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Core Devs : can you share your thoughts about all BIPs on this website ? X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Aug 2015 12:29:03 -0000 --047d7b33d952b11072051dd16959 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable accordingly to public release[1], They. 1. agreed that blocksize increase is needed. 2. opposed original 20mb, suggest 8mb instead as it is more technically reasonable. 3. do not want blocksize to change in the "short term future" ( direct translation. ) and in the document states. "after discussion we are in agreement that the blocksize should be within the ball park of 8mb for the short term future." They have no explicitly rejected or supported the other components of BIP101. It's my opinion that as long as the change is < 8mb. they'll take it. I don't believe in trying to predict the future, on adoption, technology growth, nor geopolitics. I think it matters very little which BIP we need up deploying, as long as all the attack vectors are covered, especially for the dynamically adjustable ones. One thing is for sure though, not increasing the blocksize is not an option= . we can't predict the future, in the mean time, Hardfork Responsibly=E2=84= =A2. [1] http://7fvhfe.com1.z0.glb.clouddn.com/@/wp-content/uploads/2015/06/%E5%8C%B= A%E5%9D%97%E6%89%A9%E5%AE%B9%E8%8D%89%E6%A1%88.jpg On Fri, Aug 21, 2015 at 7:28 AM, Btc Drak wrote: > On Fri, Aug 21, 2015 at 11:55 AM, Yifu Guo via bitcoin-dev > wrote: > > I like the intend of this attempt to bring more clarity to the blocksiz= e > > debate, however it would be more help to make this a information site > about > > the current outstanding BIPs and summarize their differences rather tha= n > > voting mechanism. > > (ofcourse the author of the BIPs would "vote" for their own proposals.= ) > > > > It would be good to include supporting and counter statements regards t= o > > these BIPs on the site. > > in addition to highlight certain things like pools in china have voiced > > their opinion that increase should happen, and 8mb is something they ar= e > > comfortable with, which is not directly related to a single BIP, but > never > > the less relevant in this discussion. > > I was rather surprised by the tweet from AntPool[1] today saying that > they support big blocks and would be prepared to upgrade to XT. Pools > have stated that they are willing to increase to a maximum of 8MB, but > upgrading to XT puts them on a schedule towards 8GB which is clearly > not what they have agreed to. > > Do you have any insights into what's going on there? > > Also do you have any insight into what Chinese pools would accept as a > compromise in terms of raising the blocksize limit? > > Drak > > [1] https://twitter.com/JihanWu/status/633288343338381314 > --=20 *Yifu Guo* *"Life is an everlasting self-improvement."* --047d7b33d952b11072051dd16959 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
accordingly to public rel= ease[1], They.

1. agreed that blocksize increase is needed.
2. opposed original 20mb, suggest 8mb instead = as it is more technically reasonable.
= 3. do not want blocksize to change in the "short term future" ( d= irect translation. ) and in the document states.
"after discussion we are in agreement that the blocksize sh= ould be within the ball park of 8mb for the short term future."
<= div style=3D"font-size:12.8px">
Th= ey have no explicitly rejected or supported the other components of BIP101.= It's my opinion that as long as the change is < 8mb. they'll ta= ke it.

I don't believe in trying to predict the future, on adoption= , technology growth, nor geopolitics. I think it matters very little which = BIP we need up deploying, as long as all the attack vectors are covered, es= pecially for the dynamically adjustable ones.

One thing is for sure tho= ugh,=C2=A0not increasing the blocksize is = not an option.

we can't predict the future, in the mean time= , Hardfork Responsibly=E2=84=A2.=

[1]http://7fvhfe.com1.z0.glb.clouddn.com/@/wp-content/uploads/201= 5/06/%E5%8C%BA%E5%9D%97%E6%89%A9%E5%AE%B9%E8%8D%89%E6%A1%88.jpg

On Fri, Aug 21,= 2015 at 7:28 AM, Btc Drak <btcdrak@gmail.com> wrote:
On Fri, Aug 21, 2015 at 11:55 AM, Yifu Gu= o via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I like the intend of this attempt to bring more clarity t= o the blocksize
> debate, however it would be more help to make this a information site = about
> the current outstanding BIPs and summarize their differences rather th= an
> voting mechanism.
>=C2=A0 (ofcourse the author of the BIPs would "vote" for thei= r own proposals.)
>
> It would be good to include supporting and counter statements regards = to
> these BIPs on the site.
> in addition to highlight certain things like pools in china have voice= d
> their opinion that increase should happen, and 8mb is something they a= re
> comfortable with, which is not directly related to a single BIP, but n= ever
> the less relevant in this discussion.

I was rather surprised by the tweet from AntPool[1] today = saying that
they support big blocks and would be prepared to upgrade to XT. Pools
have stated that they are willing to increase to a maximum of 8MB, but
upgrading to XT puts them on a schedule towards 8GB which is clearly
not what they have agreed to.

Do you have any insights into what's going on there?

Also do you have any insight into what Chinese pools would accept as a
compromise in terms of raising the blocksize limit?

Drak

[1] https://twitter.com/JihanWu/status/633288= 343338381314



--
=
Yifu Guo
"Life is an = everlasting self-improvement."
--047d7b33d952b11072051dd16959--