path: root/bc/ea3f77c8ceaffa95206c32dd572d201b331653

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 99888902
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 15 Apr 2017 03:05:29 +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 6E90C184
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 15 Apr 2017 03:05:28 +0000 (UTC)
DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=suredbits.com;
	q=dns/txt; 
	s=mailo; t=1492225527; h=Content-Type: Cc: To: Subject: Message-ID:
	Date: From: References: In-Reply-To: MIME-Version: Sender;
	bh=1iyXL352Rsfk7bfeqMgrrdGVDZMpKT3VF8Oh5lOgkLI=;
	b=AS3YFN3Rr8+Z8coaTbLCBvgG0AyWvDoRn2DaEBEh8GvY0W3jeMipSPT4m5CUPVJpA6egZ6cx
	Z0+9pqfMvq5InHesMKZE8mylg7o9ntXxxod231PMF+3zxP04EFiuPWhoyAvKLZqCSLBHkluX
	3EStPNnFno3MVlYB+AKqkL3T7v0=
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=jXU99bG4Og7Fkk/YVFzl1KETOJMsUofDhd2yaVOPozopyPEBOJTRKamI0wB8CWYY6Ew88o
	1nS1EI+vCYSQAs9Of9q43QKsRLIXHOAQMKGYn2YKCNGGeg0JU21wyaLnQFFxNEOv9IlB1ho/
	pEtjPpVzDxkFRIbKomCDwbPOqtfaE=
Sender: chris@suredbits.com
X-Mailgun-Sending-Ip: 198.61.254.16
X-Mailgun-Sid: WyI5MGYzNyIsICJiaXRjb2luLWRldkBsaXN0cy5saW51eGZvdW5kYXRpb24ub3JnIiwgIjJjMTQxIl0=
Received: from mail-it0-f50.google.com (mail-it0-f50.google.com
	[209.85.214.50])
	by mxa.mailgun.org with ESMTP id 58f18df7.7fe5406585f0-smtp-out-n01;
	Sat, 15 Apr 2017 03:05:27 -0000 (UTC)
Received: by mail-it0-f50.google.com with SMTP id a140so2904631ita.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Fri, 14 Apr 2017 20:05:26 -0700 (PDT)
X-Gm-Message-State: AN3rC/7pzYDyd8yBOkeeu26z0W/KY7dbX9c/PCaJhe/lzAmZQWRrYiaj
	JnjrDShdWvvGpqeDC7fGoFXJjsKeUw==
X-Received: by 10.36.216.4 with SMTP id b4mr540105itg.100.1492225526396; Fri,
	14 Apr 2017 20:05:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.19.11 with HTTP; Fri, 14 Apr 2017 20:05:25 -0700 (PDT)
In-Reply-To: <CAAjy6kAi6L9=4tgtay3m3YUk8SLs3NxD0JXp78TWmJXVMNfASQ@mail.gmail.com>
References: <CAAS2fgRdSOu8N6L3+fBpnye+rM+W6+F=cePy=9oL4tJuCj=Jsw@mail.gmail.com>
	<CAAjy6kAi6L9=4tgtay3m3YUk8SLs3NxD0JXp78TWmJXVMNfASQ@mail.gmail.com>
From: Chris Stewart <chris@suredbits.com>
Date: Fri, 14 Apr 2017 22:05:25 -0500
X-Gmail-Original-Message-ID: <CAGL6+mHjxmKGb39112_JTiWBsMr7mcVnacTb_1PQ90=nfxKonA@mail.gmail.com>
Message-ID: <CAGL6+mHjxmKGb39112_JTiWBsMr7mcVnacTb_1PQ90=nfxKonA@mail.gmail.com>
To: Steven Pine <steven.pine@gmail.com>
Content-Type: multipart/alternative; boundary=94eb2c0601986d0c34054d2bd451
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,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: Sat, 15 Apr 2017 03:27:31 +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: Sat, 15 Apr 2017 03:05:29 -0000

--94eb2c0601986d0c34054d2bd451
Content-Type: text/plain; charset=UTF-8

>Regarding this last point I was under the impression that if Segwit did
not activate by November then core was going to move on, is that no longer
the case, does the core team plan on trying to activate Segwit in some
other way?

Since block size seems to be the controversial issue, AFAIK we *could*
remove the block size increase (by removing the discount on signature
data). This discount was put in place for two reasons

1.) It allows for a block size increase
2.) It makes it more expensive to create UTXOs. UTXO bloat is a problem on
the bitcoin network and segwit was an elegant way to make the network
appreciate their real cost in terms of hardware/RAM.

We would still get the benefits of:
1.) Tx malleability elimination
2.) Script versioning

-Chris

On Fri, Apr 14, 2017 at 9:01 PM, Steven Pine via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > Segwit is a good improvement
> and we should respect it by knowing that it's good enough to wait for,
> and for however its activated to be done the best way we know how.
>
> Regarding this last point I was under the impression that if Segwit did
> not activate by November then core was going to move on, is that no longer
> the case, does the core team plan on trying to activate Segwit in some
> other way?
>
> I am also curious, but has there been a softfork, hardfork, or other major
> census change that was not rolled out and done by the core team? I only
> mention this because BIP148, if it goes ahead (and is successful), would be
> the first time a consensus change occurs outside of the core developers --
> but again I am not an expert on the history of changes and could be wrong,
> I only bring this up because core developers have in the past stressed they
> are a part of the bitcoin ecosystem and not the drivers of it (at least
> that is the ideal it seems).
>
> My impression is that the community is ready for this and wants it, and if
> that impression is correct it will go ahead. No one knows the future, and
> simply assuming it's better to be slow and methodical isn't especially
> convincing. Technology is in someways the history of failure, we like to
> celebrate the seemingly sudden breakthroughs and successes but it's rare
> that the original innovator retains a monopoly on their invention, more
> often it becomes quickly refined and iterated upon as market forces take
> hold to bring costs down and other external political issues
> take precedence, all this is say that in ten years everyone could be
> chuckling over the 3 year bitcoin scaling debate, or they could be using
> litecoin, or ethereum or some other crypto coin, or something entirely
> different, no one knows.
>
> On Fri, Apr 14, 2017 at 3:56 AM, Gregory Maxwell via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I do not support the BIP148 UASF for some of the same reasons that I
>> do support segwit:  Bitcoin is valuable in part because it has high
>> security and stability, segwit was carefully designed to support and
>> amplify that engineering integrity that people can count on now and
>> into the future.
>>
>> I do not feel the the approach proposed in BIP148 really measures up
>> to the standard set by segwit itself, or the existing best practices
>> in protocol development in this community.
>>
>> The primary flaw in BIP148 is that by forcing the activation of the
>> existing (non-UASF segwit) nodes it almost guarantees at a minor level
>> of disruption.
>>
>> Segwit was carefully engineered so that older unmodified miners could
>> continue operating _completely_ without interruption after segwit
>> activates.
>>
>> Older nodes will not include segwit spends, and so their blocks will
>> not be invalid even if they do not have segwit support. They can
>> upgrade to it on their own schedule. The only risk non-participating
>> miners take after segwit activation is that if someone else mines an
>> invalid block they would extend it, a risk many miners already
>> frequently take with spy-mining.
>>
>> I do not think it is a horrible proposal: it is better engineered than
>> many things that many altcoins do, but just not up to our normal
>> standards. I respect the motivations of the authors of BIP 148.  If
>> your goal is the fastest possible segwit activation then it is very
>> useful to exploit the >80% of existing nodes that already support the
>> original version of segwit.
>>
>> But the fastest support should not be our goal, as a community-- there
>> is always some reckless altcoin or centralized system that can support
>> something faster than we can-- trying to match that would only erode
>> our distinguishing value in being well engineered and stable.
>>
>> "First do no harm." We should use the least disruptive mechanisms
>> available, and the BIP148 proposal does not meet that test.  To hear
>> some people-- non-developers on reddit and such-- a few even see the
>> forced orphaning of 148 as a virtue, that it's punitive for
>> misbehaving miners. I could not not disagree with that perspective any
>> more strongly.
>>
>> Of course, I do not oppose the general concept of a UASF but
>> _generally_ a soft-fork (of any kind) does not need to risk disruption
>> of mining, just as segwit's activation does not.  UASF are the
>> original kind of soft-fork and were the only kind of fork practiced by
>> Satoshi. P2SH was activated based on a date, and all prior ones were
>> based on times or heights.  We introduced miner based activation as
>> part of a process of making Bitcoin more stable in the common case
>> where the ecosystem is all in harmony.  It's kind of weird to see UASF
>> portrayed as something new.
>>
>> It's important the users not be at the mercy of any one part of the
>> ecosystem to the extent that we can avoid it-- be it developers,
>> exchanges, chat forums, or mining hardware makers.  Ultimately the
>> rules of Bitcoin work because they're enforced by the users
>> collectively-- that is what makes Bitcoin Bitcoin, it's what makes it
>> something people can count on: the rules aren't easy to just change.
>>
>> There have been some other UASF proposals that avoid the forced
>> disruption-- by just defining a new witness bit and allowing
>> non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I
>> think they are vastly superior. They would be slower to deploy, but I
>> do not think that is a flaw.
>>
>> We should have patience. Bitcoin is a system that should last for all
>> ages and power mankind for a long time-- ten years from now a couple
>> years of dispute will seem like nothing. But the reputation we earn
>> for stability and integrity, for being a system of money people can
>> count on will mean everything.
>>
>> If these discussions come up, they'll come up in the form of reminding
>> people that Bitcoin isn't easily changed at a whim, even when the
>> whims are obviously good, and how that protects it from being managed
>> like all the competing systems of money that the world used to use
>> were managed. :)
>>
>> So have patience, don't take short cuts.  Segwit is a good improvement
>> and we should respect it by knowing that it's good enough to wait for,
>> and for however its activated to be done the best way we know how.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> --
> Steven Pine
> (510) 517-7075
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

--94eb2c0601986d0c34054d2bd451
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div><div>&gt;<span style=3D"font=
-size:12.8px">Regarding this last point I was under the
 impression that if Segwit did not activate by November then core was=20
going to move on, is that no longer the case, does the core team plan on
 trying to=C2=A0activate=C2=A0Segwit in some other way?<br><br></span></div=
><span style=3D"font-size:12.8px">Since
 block size seems to be the controversial issue, AFAIK we *could* remove
 the block size increase (by removing the discount on signature data).=20
This discount was put in place for two reasons <br><br></span></div><span s=
tyle=3D"font-size:12.8px">1.) It allows for a block size increase <br></spa=
n></div><span style=3D"font-size:12.8px">2.)
 It makes it more expensive to create UTXOs. UTXO bloat is a problem on=20
the bitcoin network and segwit was an elegant way to make the network=20
appreciate their real cost in terms of hardware/RAM. <br><br></span></div><=
span style=3D"font-size:12.8px">We would still get the benefits of: <br></s=
pan></div><span style=3D"font-size:12.8px">1.) Tx malleability elimination =
<br></span></div><span style=3D"font-size:12.8px">2.) Script versioning <br=
><br></span></div><span style=3D"font-size:12.8px">-Chris</span><div class=
=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Apr 14, 2017 at 9:0=
1 PM, Steven Pine via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:b=
itcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.l=
inuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<div dir=3D"ltr"><span class=3D""><span class=3D"m_7353213839404351267gmail=
-im" style=3D"font-size:12.8px">&gt;<span style=3D"font-size:12.8px">=C2=A0=
Segwit is a good improvement</span><br style=3D"font-size:12.8px"><span sty=
le=3D"font-size:12.8px">and we should respect it by knowing that it&#39;s g=
ood enough to wait for,</span><br style=3D"font-size:12.8px"><span style=3D=
"font-size:12.8px">and for however its activated to be done the best way we=
 know how.</span><div><span style=3D"font-size:12.8px"><br></span></div></s=
pan></span><div style=3D"font-size:12.8px"><span style=3D"font-size:12.8px"=
>Regarding this last point I was under the impression that if Segwit did no=
t activate by November then core was going to move on, is that no longer th=
e case, does the core team plan on trying to=C2=A0activate=C2=A0Segwit in s=
ome other way?</span></div><div style=3D"font-size:12.8px"><span style=3D"f=
ont-size:12.8px"><br></span></div><div style=3D"font-size:12.8px"><span sty=
le=3D"font-size:12.8px">I am also curious, but has there been a softfork, h=
ardfork, or other major census change that was not rolled out and done by t=
he core team? I only mention this because BIP148, if it goes ahead (and is =
successful), would be the first time a consensus change occurs outside of t=
he core developers -- but again I am not an expert on the history of change=
s and could be wrong, I only bring this up because core developers have in =
the past stressed they are a part of the bitcoin ecosystem and not the driv=
ers of it (at least that is the ideal it seems).</span></div><div style=3D"=
font-size:12.8px"><span style=3D"font-size:12.8px"><br></span></div><div st=
yle=3D"font-size:12.8px"><span style=3D"font-size:12.8px">My impression is =
that the community is ready for this and wants it, and if that impression i=
s correct it will go ahead. No one knows the future, and simply assuming it=
&#39;s better to be slow and methodical isn&#39;t especially convincing. Te=
chnology is in someways the history of failure, we like to celebrate the se=
emingly sudden breakthroughs and successes but it&#39;s rare that the origi=
nal innovator retains a monopoly on their invention, more often it becomes =
quickly refined and=C2=A0iterated upon as market forces take hold to bring =
costs down and other external political issues take=C2=A0precedence, all th=
is is say that in ten years everyone could be chuckling over the 3 year bit=
coin scaling debate, or they could be using litecoin, or=C2=A0ethereum=C2=
=A0or some other crypto coin, or something entirely different, no one knows=
.</span></div></div><div class=3D"gmail_extra"><div><div class=3D"h5"><br><=
div class=3D"gmail_quote">On Fri, Apr 14, 2017 at 3:56 AM, Gregory Maxwell =
via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.l=
inuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.<wbr>linuxfoundatio=
n.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I do not supp=
ort the BIP148 UASF for some of the same reasons that I<br>
do support segwit:=C2=A0 Bitcoin is valuable in part because it has high<br=
>
security and stability, segwit was carefully designed to support and<br>
amplify that engineering integrity that people can count on now and<br>
into the future.<br>
<br>
I do not feel the the approach proposed in BIP148 really measures up<br>
to the standard set by segwit itself, or the existing best practices<br>
in protocol development in this community.<br>
<br>
The primary flaw in BIP148 is that by forcing the activation of the<br>
existing (non-UASF segwit) nodes it almost guarantees at a minor level<br>
of disruption.<br>
<br>
Segwit was carefully engineered so that older unmodified miners could<br>
continue operating _completely_ without interruption after segwit<br>
activates.<br>
<br>
Older nodes will not include segwit spends, and so their blocks will<br>
not be invalid even if they do not have segwit support. They can<br>
upgrade to it on their own schedule. The only risk non-participating<br>
miners take after segwit activation is that if someone else mines an<br>
invalid block they would extend it, a risk many miners already<br>
frequently take with spy-mining.<br>
<br>
I do not think it is a horrible proposal: it is better engineered than<br>
many things that many altcoins do, but just not up to our normal<br>
standards. I respect the motivations of the authors of BIP 148.=C2=A0 If<br=
>
your goal is the fastest possible segwit activation then it is very<br>
useful to exploit the &gt;80% of existing nodes that already support the<br=
>
original version of segwit.<br>
<br>
But the fastest support should not be our goal, as a community-- there<br>
is always some reckless altcoin or centralized system that can support<br>
something faster than we can-- trying to match that would only erode<br>
our distinguishing value in being well engineered and stable.<br>
<br>
&quot;First do no harm.&quot; We should use the least disruptive mechanisms=
<br>
available, and the BIP148 proposal does not meet that test.=C2=A0 To hear<b=
r>
some people-- non-developers on reddit and such-- a few even see the<br>
forced orphaning of 148 as a virtue, that it&#39;s punitive for<br>
misbehaving miners. I could not not disagree with that perspective any<br>
more strongly.<br>
<br>
Of course, I do not oppose the general concept of a UASF but<br>
_generally_ a soft-fork (of any kind) does not need to risk disruption<br>
of mining, just as segwit&#39;s activation does not.=C2=A0 UASF are the<br>
original kind of soft-fork and were the only kind of fork practiced by<br>
Satoshi. P2SH was activated based on a date, and all prior ones were<br>
based on times or heights.=C2=A0 We introduced miner based activation as<br=
>
part of a process of making Bitcoin more stable in the common case<br>
where the ecosystem is all in harmony.=C2=A0 It&#39;s kind of weird to see =
UASF<br>
portrayed as something new.<br>
<br>
It&#39;s important the users not be at the mercy of any one part of the<br>
ecosystem to the extent that we can avoid it-- be it developers,<br>
exchanges, chat forums, or mining hardware makers.=C2=A0 Ultimately the<br>
rules of Bitcoin work because they&#39;re enforced by the users<br>
collectively-- that is what makes Bitcoin Bitcoin, it&#39;s what makes it<b=
r>
something people can count on: the rules aren&#39;t easy to just change.<br=
>
<br>
There have been some other UASF proposals that avoid the forced<br>
disruption-- by just defining a new witness bit and allowing<br>
non-upgraded-to-uasf miners and nodes to continue as non-upgraded, I<br>
think they are vastly superior. They would be slower to deploy, but I<br>
do not think that is a flaw.<br>
<br>
We should have patience. Bitcoin is a system that should last for all<br>
ages and power mankind for a long time-- ten years from now a couple<br>
years of dispute will seem like nothing. But the reputation we earn<br>
for stability and integrity, for being a system of money people can<br>
count on will mean everything.<br>
<br>
If these discussions come up, they&#39;ll come up in the form of reminding<=
br>
people that Bitcoin isn&#39;t easily changed at a whim, even when the<br>
whims are obviously good, and how that protects it from being managed<br>
like all the competing systems of money that the world used to use<br>
were managed. :)<br>
<br>
So have patience, don&#39;t take short cuts.=C2=A0 Segwit is a good improve=
ment<br>
and we should respect it by knowing that it&#39;s good enough to wait for,<=
br>
and for however its activated to be done the best way we know how.<br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundat<wbr>ion.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-d<wbr>ev</a><br>
</blockquote></div><br><br clear=3D"all"><div><br></div></div></div><span c=
lass=3D"HOEnZb"><font color=3D"#888888">-- <br><div class=3D"m_735321383940=
4351267gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"=
><div>Steven Pine<div><a href=3D"tel:(510)%20517-7075" value=3D"+1510517707=
5" target=3D"_blank">(510) 517-7075</a></div></div></div></div>
</font></span></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></div>

--94eb2c0601986d0c34054d2bd451--