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 731CFBCB for ; Fri, 14 Apr 2017 17:36:38 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from so254-16.mailgun.net (so254-16.mailgun.net [198.61.254.16]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 72E9510A for ; Fri, 14 Apr 2017 17:36:37 +0000 (UTC) DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=suredbits.com; q=dns/txt; s=mailo; t=1492191396; h=Content-Type: Cc: To: Subject: Message-ID: Date: From: References: In-Reply-To: MIME-Version: Sender; bh=bt/T3KqLFIB67INuk24winNc/OLlSYIyZf3XxmOANac=; b=Gxcv+i6xkIx7WiT6YdlufghW8Qkb2iNDm9NeNyXN9PZd2UTCVefy+1IasqPuSOxLtWAJnRLY JJS8Nh+rQ1Firg7X0AaEB8VL0yjp651x+m+j9w9QocS3pByUbPybirDAjciD/TE4rQsHn1QL FRs0X68dhIIOIQ6SCGdD4MTIWqE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=suredbits.com; s=mailo; q=dns; h=Sender: MIME-Version: In-Reply-To: References: From: Date: Message-ID: Subject: To: Cc: Content-Type; b=ZtC7g7RI04fDgbTzOpllWMRvNLoDmnDhLeFsjouhrGa9wyZ1gR2AfoMMJ4OOC2SpaNjXto 5qmIxDL2d47rQCWt80LUUefRymlbV2+vwokcaAwhwIcgMd5lltqnw5OYRIPQXRDlqIkryNEB 5A8pPhxtd+CvjxKec379bpNB1rLW4= Sender: chris@suredbits.com X-Mailgun-Sending-Ip: 198.61.254.16 X-Mailgun-Sid: WyI5MGYzNyIsICJiaXRjb2luLWRldkBsaXN0cy5saW51eGZvdW5kYXRpb24ub3JnIiwgIjJjMTQxIl0= Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) by mxa.mailgun.org with ESMTP id 58f108a4.7f74506a70b0-smtp-out-n01; Fri, 14 Apr 2017 17:36:36 -0000 (UTC) Received: by mail-io0-f178.google.com with SMTP id l7so115594758ioe.3 for ; Fri, 14 Apr 2017 10:36:35 -0700 (PDT) X-Gm-Message-State: AN3rC/5PJ9nXo/DJ5FabpOkjlyB24zI+PxFW4WJRmtQwlZnyvgivDQUo dDcsmPCBsmZujSOI36uLkfLjQscHLA== X-Received: by 10.107.9.231 with SMTP id 100mr11056418ioj.90.1492191395260; Fri, 14 Apr 2017 10:36:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.19.11 with HTTP; Fri, 14 Apr 2017 10:36:34 -0700 (PDT) In-Reply-To: <6Q-8gcti6Iml_nMKLlBIiS2WTVYxtRB30yRz0UqAe4-OmryaZCTYr0IrIl3RjFN3X6Yd_D_eWyXSN1ZNjq1l3dq5oXbYRmZfn1C1IvJ8FJc=@protonmail.com> References: <6Q-8gcti6Iml_nMKLlBIiS2WTVYxtRB30yRz0UqAe4-OmryaZCTYr0IrIl3RjFN3X6Yd_D_eWyXSN1ZNjq1l3dq5oXbYRmZfn1C1IvJ8FJc=@protonmail.com> From: Chris Stewart Date: Fri, 14 Apr 2017 12:36:34 -0500 X-Gmail-Original-Message-ID: Message-ID: To: praxeology_guy Content-Type: multipart/alternative; boundary=001a113eb66a0d5a77054d23e2a2 X-Spam-Status: No, score=0.0 required=5.0 tests=BAYES_00,BODY_ENHANCEMENT2, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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: Fri, 14 Apr 2017 18:30:20 +0000 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] I do not support the BIP 148 UASF 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: Fri, 14 Apr 2017 17:36:38 -0000 --001a113eb66a0d5a77054d23e2a2 Content-Type: text/plain; charset=UTF-8 >Criticizing 148 without suggesting a specific alternative leaves the community in disarray. I really disagree with this sentiment, you don't need to provide alternatives to criticize a technical proposal. I don't like this "active segwit at all costs" theme that has been going around the community. I am a fan of segwit, but we shouldn't push things through in an unsafe manner. >If 148 causes orphaning and a fork, I don't think such really matters in the long term. The non-SegWit miners will probably just quickly give up their orphans once they realize that money users like being able to have non-mutable TX IDs. If they do create a long lasting branch... well that is good too, I'd be happy to no longer have them in our community. Good luck to them in creating a competitive money, so that we can all enjoy lower transaction fees. This seems like a lot of reckless hand waving to me. Food for thought, why are we rejecting *all* blocks that do not signal segwit? Can't we just reject blocks that *do not* signal segwit, but *do* contain segwit transactions? It seems silly to me that if a miner mines a block with all pre segwit txs to reject that block. Am I missing something here? -Chris On Fri, Apr 14, 2017 at 11:50 AM, praxeology_guy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Gregory Maxwell, > > Criticizing 148 without suggesting a specific alternative leaves the > community in disarray. > > I know you are emphasizing patience. But at the same time, with your > patience we are allowing ourselves to get dicked for longer than necessary. > > I think that core could easily develop code that could create a > solid/reliable date/height based activation to allow miners to create > SegWit block candidates and having nodes fully verify them. Shaolinfry is > the only person Ive seen actually make such a proposal: > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/ > 2017-April/014049.html. His makes it so that SegWit default gets > activated at the end of the BIP9 signalling timeframe instead of default > leaving it non-activated. > > I agree that 148 is is not ideal. Non-SegWit signaling blocks are not a > Denial of Service, given that other activation methods are available. > Someone just needs to code something up that is better that we can all use > in a satisfying time frame. So far 148 is the most practical and reliable > method I'm aware of. > > If 148 causes orphaning and a fork, I don't think such really matters in > the long term. The non-SegWit miners will probably just quickly give up > their orphans once they realize that money users like being able to have > non-mutable TX IDs. If they do create a long lasting branch... well that > is good too, I'd be happy to no longer have them in our community. Good > luck to them in creating a competitive money, so that we can all enjoy > lower transaction fees. > > SegWit has already undergone enough testing. It is time to activate it. > > Cheers, > Praxeology Guy > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > --001a113eb66a0d5a77054d23e2a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
>Criticizing 148 without suggesting= a specific alternative leaves the community in disarray.

I re= ally disagree with this sentiment, you don't need to provide alternativ= es to criticize a technical proposal. I don't like this "active se= gwit at all costs" theme that has been going around the community. I a= m a fan of segwit, but we shouldn't push things through in an unsafe ma= nner.

>If 148 causes orphaning and a fork, I don't think suc= h really matters in the long term.=C2=A0 The non-SegWit miners will probably just quickly give= =20 up their orphans once they realize that money users like being able to=20 have non-mutable TX IDs.=C2=A0 If they do create a long lasting branch...= =20 well that is good too, I'd be happy to no longer have them in our=20 community.=C2=A0 Good luck to them in creating a competitive money, so that= =20 we can all enjoy lower transaction fees.

This seems like a lot= of reckless hand waving to me.

Food for thought, why are we = rejecting *all* blocks that do not signal segwit? Can't we just reject = blocks that *do not* signal segwit, but *do* contain segwit transactions? I= t seems silly to me that if a miner mines a block with all pre segwit txs t= o reject that block. Am I missing something here?

-Chris
<= /div>

On Fri, Apr = 14, 2017 at 11:50 AM, praxeology_guy via bitcoin-dev <= = bitcoin-dev@lists.linuxfoundation.org> wrote:
Gregory Maxwell,

Criti= cizing 148 without suggesting a specific alternative leaves the community i= n disarray.

I know you are emphasizing patienc= e.=C2=A0 But at the same time, with your patience we are allowing ourselves= to get dicked for longer than necessary.

I t= hink that core could easily develop code that could create a solid/reliable= date/height based activation to allow miners to create SegWit block candid= ates and having nodes fully verify them.=C2=A0 Shaolinfry is the only perso= n Ive seen actually make such a proposal: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-Apr= il/014049.html.=C2=A0 His makes it so that SegWit default gets activate= d at the end of the BIP9 signalling timeframe instead of default leaving it= non-activated.

I agree that 148 is is not ide= al.=C2=A0 Non-SegWit signaling blocks are not a Denial of Service, given th= at other activation methods are available.=C2=A0 Someone just needs to code= something up that is better that we can all use in a satisfying time frame= .=C2=A0 So far 148 is the most practical and reliable method I'm aware = of.

If 148 causes orphaning and a fork, I don&= #39;t think such really matters in the long term.=C2=A0 The non-SegWit mine= rs will probably just quickly give up their orphans once they realize that = money users like being able to have non-mutable TX IDs.=C2=A0 If they do cr= eate a long lasting branch... well that is good too, I'd be happy to no= longer have them in our community.=C2=A0 Good luck to them in creating a c= ompetitive money, so that we can all enjoy lower transaction fees.

SegWit has already undergone enough testing.=C2=A0 It = is time to activate it.

Cheers,
= Praxeology Guy

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


--001a113eb66a0d5a77054d23e2a2--