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
MIME-Version: 1.0
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
Message-ID: <CAGL6+mHpAAqNVU6SvxK2ymP=9ekJ5M4R0xW4wVqadYLk550fsA@mail.gmail.com>
To: praxeology_guy <praxeology_guy@protonmail.com>
Content-Type: multipart/alternative; boundary=001a113eb66a0d5a77054d23e2a2
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] I do not support the BIP 148 UASF
Precedence: list

--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--