summaryrefslogtreecommitdiff
path: root/21/a9646046565d28ef12505d0fb1e8217b143630
blob: d73f9948a9aac851127c20d6828d5a1abe6e7fb6 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
Return-Path: <mark@friedenbach.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id BBCD6720
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 15 Apr 2017 13:42:47 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f170.google.com (mail-io0-f170.google.com
	[209.85.223.170])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 31D6D79
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 15 Apr 2017 13:42:47 +0000 (UTC)
Received: by mail-io0-f170.google.com with SMTP id o22so2946561iod.3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 15 Apr 2017 06:42:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=friedenbach-org.20150623.gappssmtp.com; s=20150623;
	h=mime-version:from:date:message-id:subject:to;
	bh=GkVrTr6B7cJ8f6wFaYr8Ewpmlf4MfH1fhWn5AFDwhxA=;
	b=OUMOnxVWrKTx5sYLKpO7hC9CZOYDg4Uop9UwJJnyVNMidh83YrU7ma86XkfObpfvav
	XwyLOO1nEEGFue+KFH4MKRa3FPVfndMRp7LOWhCIE5Q8ZNBQt3INlz7/HqzkFFnW2HTs
	KQ+bIXrA+oG2fgOb/D8MVquJca5cz568ahY+nqtgvf1vdypiKRVfyNVZJugcGQtG5UnH
	nkQCrW0jGROYSLoX+2P5Rp1ny9a1LmNFGBLKt+pu7a0FkmVKdwLnbXITZdkC5aP5e5TN
	BWwOAtkgdCXW5zGn/3dpqtj8Sc6RNk7ZBdBKV6Damh8b3NcEGCsV4S/Vaf/iGC6wC+hR
	Iivw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
	bh=GkVrTr6B7cJ8f6wFaYr8Ewpmlf4MfH1fhWn5AFDwhxA=;
	b=oSBuI1LPSZP+qU7v4QjN37TEmZj0Tr5A39hfR1cU7uPb2Mmkq8nLtHP7qOG7MyRpkr
	dWhQHaFRCZ4XYihijLSe6ev/TzgI6l1sHV9BjHnzJ90vS5pS/8oFDx3+WIEt1kxPDZ42
	Xy/6tpDAO1ZtajfIQBbz5e9A589RHVh0GJN0DAGKtblQRf/RBh+XQ+LZSZ5fRgu6dJ7Q
	0YBxTmq8r+WF50nzgUYCnfy7n3q5nlfNSqbyJ3wKfhoj+NWONR1UjT6mPQuHOgQrfU+O
	UPI2Oa1FCiFhTfT97c8tEaUP0ohkqoYbl9yy3ZYj7saNzD4FpAOlDZeaD3AqRTWFra0g
	fB7w==
X-Gm-Message-State: AN3rC/7PApIQJLkyasgtMluN1MuzK77G80DiIDow+wfRmTLBY1MA89UD
	1+owSyEbLH306rdwOBoQmFEcPhQXjB+UOBA=
X-Received: by 10.107.1.205 with SMTP id 196mr2088995iob.131.1492263766230;
	Sat, 15 Apr 2017 06:42:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.51.137 with HTTP; Sat, 15 Apr 2017 06:42:25 -0700 (PDT)
X-Originating-IP: [108.48.174.158]
From: Mark Friedenbach <mark@friedenbach.org>
Date: Sat, 15 Apr 2017 09:42:25 -0400
Message-ID: <CAOG=w-saibrGeOSaLFtcFo_D+2Gw4zoNA-brS=aPuBoyGuPCZA@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113a673cb2a5e3054d34bb72
X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,HTML_IMAGE_ONLY_16,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,
	RCVD_IN_SORBS_SPAM,T_REMOTE_IMAGE 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 13:57:06 +0000
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 13:42:47 -0000

--001a113a673cb2a5e3054d34bb72
Content-Type: text/plain; charset=UTF-8

Greg,

If I understand correctly, the crux of your argument against BIP148 is that
it requires the segwit BIP9 activation flag to be set in every block after
Aug 1st, until segwit activates. This will cause miners which have not
upgrade and indicated support for BIP141 (the segwit BIP) to find their
blocks ignored by UASF nodes, at least for the month or two it takes to
activate segwit.

Isn't this however the entire point of BIP148? I understand if you object
to this, but let's be clear that this is a design requirement of the
proposal, not a technical oversight. The alternative you present (new BIP
bit) has the clear downside of not triggering BIP141 activation, and
therefore not enabling the new consensus rules on already deployed full
nodes. BIP148 is making an explicit choice to favor dragging along those
users which have upgraded to BIP141 support over those miners who have
failed to upgrade.

On an aside, I'm somewhat disappointed that you have decided to make a
public statement against the UASF proposal. Not because we disagree -- that
is fine -- but because any UASF must be a grassroots effort and
endorsements (or denouncements) detract from that.

Mark Friedenbach

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

<div dir=3D"ltr"><span style=3D"background-color:rgba(255,255,255,0)">Greg,=
<br><br>If I=20
understand correctly, the crux of your argument against BIP148 is that=20
it requires the segwit BIP9 activation flag to be set in every block=C2=A0<=
a dir=3D"ltr">after Aug 1st</a>,
 until segwit activates. This will cause miners which have not upgrade=20
and indicated support for BIP141 (the segwit BIP) to find their blocks=20
ignored by UASF nodes, at least for the month or two it takes to=20
activate segwit.<br><br>Isn&#39;t this however the entire point of BIP148? =
I
 understand if you object to this, but let&#39;s be clear that this is a=20
design requirement of the proposal, not a technical oversight. The=20
alternative you present (new BIP bit) has the clear downside of not=20
triggering BIP141 activation, and therefore not enabling the new=20
consensus rules on already deployed full nodes. BIP148 is making an=20
explicit choice to favor dragging along those users which have upgraded=20
to BIP141 support over those miners who have failed to upgrade.<br><br>On
 an aside, I&#39;m somewhat disappointed that you have decided to make a=20
public statement against the UASF proposal. Not because we disagree --=20
that is fine -- but because any UASF must be a grassroots effort and=20
endorsements (or denouncements) detract from that.<div class=3D"gmail-yj6qo=
 gmail-ajU"><div id=3D"gmail-:1jd" class=3D"gmail-ajR" tabindex=3D"0"><img =
class=3D"gmail-ajT" src=3D"https://ssl.gstatic.com/ui/v1/icons/mail/images/=
cleardot.gif"><br></div><div id=3D"gmail-:1jd" class=3D"gmail-ajR" tabindex=
=3D"0">Mark Friedenbach<br></div></div></span></div>

--001a113a673cb2a5e3054d34bb72--