From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 3E297B0B for ; Wed, 29 Mar 2017 19:07:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-vk0-f42.google.com (mail-vk0-f42.google.com [209.85.213.42]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6CDC317E for ; Wed, 29 Mar 2017 19:07:17 +0000 (UTC) Received: by mail-vk0-f42.google.com with SMTP id d188so29270919vka.0 for ; Wed, 29 Mar 2017 12:07:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=fC0dm4apVMMj1j/6RcZbaIlShimTKvplW+f+FhfO2mQ=; b=jN1G3liGhOhzwSwKapd1AgTZ7qgcK2uKPOup7oGAq3NY1Yg7iB0u92EXdnQJM9Vkwb nPZwpu1jgu+2ySRnpvMCEbRrVRc5EA9qM487/tCzVosceThCvFEC0WxNIz3RymX8xe9k 6oypWU09CCfmRYKsXbXfbQ4tPEoEdthLsplNyhyVhof+aT5HGMsbQsvfvhv2McTw9oGI FQJuqJRmb6YoMZaZvxSt45wz7rkileCJYVsYegQS7aRJMR9ZpXWDASLp3eCh9LkUEqqD DhMrypb9hh5D6F9wu+JZmY2ClRqWg5BjjrMEbLIUSvI94uEYdJUJeXOLOyg9j3sOCk1S lDoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=fC0dm4apVMMj1j/6RcZbaIlShimTKvplW+f+FhfO2mQ=; b=adl7AvKqOFH1HImdmEFrSo15AAcbONwVCjqVdyBrBRL+qU3fP37gBEOsGakJaVu7a0 Qe24T4QsWP41rf/LqADBNQMLkbmqyEQ9YGMJNUpQ4xyUmD0KuodFdKnAyl8JrYiKNdk9 6Ctiy0snqjHCncgQ2XA0Jnc7Hhk/b+7ulsuMD53GJZdiK3Q0cynNJy8+R8WnMsLGJJNr xRUoICue0yiqt4hjifPgy3k5EL5QWGIrKTMTRejPf+gGFcX7byTVC9lXkfwySc38k7Ia 7dQnzUGJm6dvwh0GMhHEjU2WMEu4lEGBP2Rpg7MsZHiCH2vkjMYjQlEolBZ/SfNkP7dt M+gw== X-Gm-Message-State: AFeK/H0cVDFfe/W+6y7FvAHpWZZ6QFX1obDKMHKRc3qojTZf/E5Ml1s6KiukIXtJsrFG7++qg+HIAJPWYOnkYQ== X-Received: by 10.31.218.195 with SMTP id r186mr938243vkg.112.1490814436328; Wed, 29 Mar 2017 12:07:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.157.143 with HTTP; Wed, 29 Mar 2017 12:07:15 -0700 (PDT) In-Reply-To: References: From: Jared Lee Richardson Date: Wed, 29 Mar 2017 12:07:15 -0700 Message-ID: To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=94eb2c07adbce74d92054be3481a X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 29 Mar 2017 19:08:56 +0000 Subject: Re: [bitcoin-dev] Hard fork proposal from last week's meeting X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 19:07:18 -0000 --94eb2c07adbce74d92054be3481a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable > While Segwit's change from 1 mb size limit to 4 mb weight limit seems to be controversial among some users [..] I don't think it's very interesting to discuss further size increases. I think the reason for this is largely because SegWit as a blocksize increase isn't very satisfying. It resolves to a one-time increase with no future plans, thus engendering the same objections as people who demand we just "raise the number to N." People can argue about what N should be, but when N is just a flat number, we know we'll have to deal with the issue again. In that light I think it is even more essential to continue to discuss the blocksize debate and problem. > I find more interesting to talk to the users and see how they think Segwit harms them, >From an inordinant amount of time spent reading Reddit, I believe this largely comes down to the rumor that has a deathgrip on the BU community - That Core are all just extensions of Blockstream, and blockstream wants to restrict growth on-chain to force growth of their 2nd layer services(lightning and/or sidechains). I believe the tone of the discussion needs to be changed, and have been trying to work to change that tone for weeks now. There's one faction that believes that Bitcoin will rarely, if ever, benefit from a blocksize increase, and fees rising is a desired/unavoidable result. There's a different faction that believes Bitcoin limits are arbitrary and that all people worldwide should be able to put any size transactions, even microtransactions, on-chain. Both factions are extreme in their viewpoints and resort to conspiracy theories to interpret the actions of Core(blockstream did it) or BU(Jihan controls everything and anyone who says overwise is a shill paid by Roger Ver!) It is all very unhealthy for Bitcoin. Both sides need to accept that microtransactions from all humans cannot go on-chain, and that never increasing the blocksize doesn't mean millions of home users will run nodes. The node argument breaks down economically and the microtransaction argument is an impossible mountain for a blockchain to climb. On Wed, Mar 29, 2017 at 2:37 AM, Jorge Tim=C3=B3n via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > While Segwit's change from 1 mb size limit to 4 mb weight limit seems to > be controversial among some users (I find that very often it is because > they have been confused about what segwit does or even outright lied abou= t > it) I don't think it's very interesting to discuss further size increases= . > I find more interesting to talk to the users and see how they think Segwi= t > harms them, maybe we missed something in segwit that needs to be removed > for segwit to become uncontroversial, or maybe it is just disinformation. > > On the other hand, we may want to have our first uncontroversial hardfork > asap, independently of block size. For example, we could do something as > simple as fixing the timewarp attack as bip99 proposes. I cannot think of= a > hf that is easier to implement or has less potential for controversy than > that. > > On 29 Mar 2017 8:32 am, "Bram Cohen via bitcoin-dev" linuxfoundation.org> wrote: > > On Tue, Mar 28, 2017 at 9:59 AM, Wang Chun via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> >> The basic idea is, as many of us agree, hard fork is risky and should >> be well prepared. We need a long time to deploy it. >> > > Much as it may be appealing to repeal the block size limit now with a > grace period until a replacement is needed in a repeal and replace > strategy, it's dubious to assume that an idea can be agreed upon later wh= en > it can't be agreed upon now. Trying to put a time limit on it runs into t= he > possibility that you'll find that whatever reasons there were for not > having general agreement on a new setup before still apply, and running > into the embarrassing situation of winding up sticking with the status qu= o > after much sturm and drang. > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --94eb2c07adbce74d92054be3481a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>=C2=A0While Segwit= 9;s change from 1 mb size limit to 4 mb weight limit seems to be controvers= ial among some users [..]=C2=A0I do= n't think it's very interesting to discuss further size increases.<= /span>

I think the reason for this = is largely because SegWit as a blocksize increase isn't very satisfying= .=C2=A0 It resolves to a one-time increase with no future plans, thus engen= dering the same objections as people who demand we just "raise the num= ber to N." =C2=A0People can argue about what N should be, but when N i= s just a flat number, we know we'll have to deal with the issue again.<= br>
In that light I think it is even more essential to continue to discu= ss the blocksize debate and problem.

>=C2=A0I find more interesting to talk to the users and see how= they think Segwit harms them,

From an inordinant amount of time spe= nt reading Reddit, I believe this largely comes down to the rumor that has = a deathgrip on the BU community - That Core are all just extensions of Bloc= kstream, and blockstream wants to restrict growth on-chain to force growth = of their 2nd layer services(lightning and/or sidechains).

I believe the tone of the discussion needs to be changed, and have b= een trying to work to change that tone for weeks now.=C2=A0 There's one= faction that believes that Bitcoin will rarely, if ever, benefit from a bl= ocksize increase, and fees rising is a desired/unavoidable result.=C2=A0 Th= ere's a different faction that believes Bitcoin limits are arbitrary an= d that all people worldwide should be able to put any size transactions, ev= en microtransactions, on-chain.=C2=A0 Both factions are extreme in their vi= ewpoints and resort to conspiracy theories to interpret the actions of Core= (blockstream did it) or BU(Jihan controls everything and anyone who says ov= erwise is a shill paid by Roger Ver!)

It is all very unhealthy for Bitcoin.=C2=A0 Both sides nee= d to accept that microtransactions from all humans cannot go on-chain, and = that never increasing the blocksize doesn't mean millions of home users= will run nodes.=C2=A0 The node argument breaks down economically and the m= icrotransaction argument is an impossible mountain for a blockchain to clim= b.


On Wed, Mar 29, 2017 at 2:37 AM, Jorge Tim=C3=B3n via bitcoin-d= ev <bitcoin-dev@lists.linuxfoundation.org> wrote:
While Se= gwit's change from 1 mb size limit to 4 mb weight limit seems to be con= troversial among some users (I find that very often it is because they have= been confused about what segwit does or even outright lied about it) I don= 't think it's very interesting to discuss further size increases.
I find more interesting to talk to the users and see = how they think Segwit harms them, maybe we missed something in segwit that = needs to be removed for segwit to become uncontroversial, or maybe it is ju= st disinformation.=C2=A0

On the other hand, we may want to have our first uncontroversial hardfork = asap, independently of block size. For example, we could do something as si= mple as fixing the timewarp attack as bip99 proposes. I cannot think of a h= f that is easier to implement or has less potential for controversy than th= at.

On 29 Mar 2017 8:32 am, "Bram Cohen via bitc= oin-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:=
=
= On Tue, Mar 28, 2017 at 9:59 AM, Wang Chun via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
The basic idea is, as many of us agree, hard fork is risky and should
be well prepared. We need a long time to deploy it.
Much as it may be appealing to repeal the block size lim= it now with a grace period until a replacement is needed in a repeal and re= place strategy, it's dubious to assume that an idea can be agreed upon = later when it can't be agreed upon now. Trying to put a time limit on i= t runs into the possibility that you'll find that whatever reasons ther= e were for not having general agreement on a new setup before still apply, = and running into the embarrassing situation of winding up sticking with the= status quo after much sturm and drang.


_____________________________________= __________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev



_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org= /mailman/listinfo/bitcoin-dev


--94eb2c07adbce74d92054be3481a--