path: root/bd/b1d8944782390b7a87c771b6f268eb30de75e4

Return-Path: <bounce+33760e.2c141-bitcoin-dev=lists.linuxfoundation.org@suredbits.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 731CFBCB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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: <CAAS2fgRdSOu8N6L3+fBpnye+rM+W6+F=cePy=9oL4tJuCj=Jsw@mail.gmail.com>
	<6Q-8gcti6Iml_nMKLlBIiS2WTVYxtRB30yRz0UqAe4-OmryaZCTYr0IrIl3RjFN3X6Yd_D_eWyXSN1ZNjq1l3dq5oXbYRmZfn1C1IvJ8FJc=@protonmail.com>
From: Chris Stewart <chris@suredbits.com>
Date: Fri, 14 Apr 2017 12:36:34 -0500
X-Gmail-Original-Message-ID: <CAGL6+mHpAAqNVU6SvxK2ymP=9ekJ5M4R0xW4wVqadYLk550fsA@mail.gmail.com>
Message-ID: <CAGL6+mHpAAqNVU6SvxK2ymP=9ekJ5M4R0xW4wVqadYLk550fsA@mail.gmail.com>
To: praxeology_guy <praxeology_guy@protonmail.com>
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 <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

<div dir=3D"ltr"><div><div><div><div>&gt;Criticizing 148 without suggesting=
 a specific alternative leaves the community in disarray.<br><br></div>I re=
ally disagree with this sentiment, you don&#39;t need to provide alternativ=
es to criticize a technical proposal. I don&#39;t like this &quot;active se=
gwit at all costs&quot; theme that has been going around the community. I a=
m a fan of segwit, but we shouldn&#39;t push things through in an unsafe ma=
nner. <br><br>&gt;If 148 causes orphaning and a fork, I don&#39;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&#39;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.<br><br></div>This seems like a lot=
 of reckless hand waving to me. <br><br></div>Food for thought, why are we =
rejecting *all* blocks that do not signal segwit? Can&#39;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? <br><br></div>-Chris<br><=
/div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Apr =
14, 2017 at 11:50 AM, praxeology_guy via bitcoin-dev <span dir=3D"ltr">&lt;=
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div>Gregory Maxwell,<br></div><div><br></div><div>Criti=
cizing 148 without suggesting a specific alternative leaves the community i=
n disarray.<br></div><div><br></div><div>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.<br></div><div> <br></div><div>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: <a href=3D"https://lists.linuxfou=
ndation.org/pipermail/bitcoin-dev/2017-April/014049.html" target=3D"_blank"=
>https://lists.linuxfoundation.<wbr>org/pipermail/bitcoin-dev/<wbr>2017-Apr=
il/014049.html</a>.=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.<br></div><div><br></div><div>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&#39;m aware =
of.<br></div><div><br></div><div>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&#39;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.<br></div=
><div><br></div><div>SegWit has already undergone enough testing.=C2=A0 It =
is time to activate it.<br></div><div><br></div><div>Cheers,<br></div><div>=
Praxeology Guy<br></div><br>______________________________<wbr>____________=
_____<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
<br></blockquote></div><br></div>

--001a113eb66a0d5a77054d23e2a2--