summaryrefslogtreecommitdiff
path: root/b3/7e91e4e89c9bfde69c09176359bb83de96bb95
blob: e2152beea615a3fd61e0e04455703fb0defcd70f (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
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
Return-Path: <da2ce7@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id C8429B63
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 15 Apr 2017 08:05:19 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-lf0-f48.google.com (mail-lf0-f48.google.com
	[209.85.215.48])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 42858E2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 15 Apr 2017 08:05:15 +0000 (UTC)
Received: by mail-lf0-f48.google.com with SMTP id 88so1956555lfr.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 15 Apr 2017 01:05:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=LixYhSE0Egjrah+5MIrAqkSShK/n+X1FP2l67gxcpPg=;
	b=EjpdjX/b5gegV5YctUEqlxEu7aTIVd//8J9z5htTcKDAdEGvzmoraFIAlNMUx8pNcb
	5y51y6j+aahWmJxPXlQSLPwmqYnbYqY8fDl3kIPrra4fKpklGFbhiZBBdAEnQdwhZoHM
	V3OG1C706ecBihjSPfDGqnuVUEEBErG9tnwkLGsFZ/9K1NA+n3OHLN2mQY5zkAHIXbyH
	TWw07403/jz6VS1D0oJKbJGL0VPkEJtLJpzkywLJJUKc3YFVygmCSuFO5WJ8GNsxKoWh
	qgGrJsoJl/ruLV8iUZdFYHQ+fgIrCHz/hAfbYmLvp+B0yY5tAoIScc/I0TWdHsmFhOWY
	w7og==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc
	:content-transfer-encoding:message-id:references:to;
	bh=LixYhSE0Egjrah+5MIrAqkSShK/n+X1FP2l67gxcpPg=;
	b=C/fUGYuOyahQqnaGh3qGROokUWf6MoE2yiS5KABlB+v2uJ7uLCwCJausjQDrVwh54Q
	5jo6lrgy4e9idF8Z6rpChHtda/0TZe+bHkibJNr0WZzKVB2VlNquVSraO7LuX79eC2wR
	tzADQYjqG1ot7+eSpmiUZq22/YOvTm1zGbxq1mT6JW3A8LR+ixWRwwwpUMg2owadIH09
	HZ6PeGgqlKQNgvmE927Z5A0DEk2gWvkYjZTWH7rCoX6p0D25QT3ePTrhd5nWTCZcragk
	/U2vS4NkxckbInOrwcyBKvc9nerTQ4rqwXNsIMA2CoiZuduT5lmDuNa1hVXilvzHvDGl
	iwtA==
X-Gm-Message-State: AN3rC/79F18PBJ2tfOfvyq8XTbZORtFm3CFf/m3SLUdmcPgYn4Y6nSvT
	s0GWQtWGgBTx3w==
X-Received: by 10.46.88.29 with SMTP id m29mr356565ljb.91.1492243513580;
	Sat, 15 Apr 2017 01:05:13 -0700 (PDT)
Received: from [192.168.0.102] ([78.26.162.42])
	by smtp.gmail.com with ESMTPSA id x22sm255730ljd.38.2017.04.15.01.05.11
	(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
	Sat, 15 Apr 2017 01:05:12 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Cameron Garnham <da2ce7@gmail.com>
In-Reply-To: <CAAS2fgSXOkTcJ5tTssuGMCQwh-JFQTkzU5VBjaR+hKT+bD3Q6A@mail.gmail.com>
Date: Sat, 15 Apr 2017 11:05:10 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <99CEF27C-4C2B-4F62-91D4-37ACB63B443A@gmail.com>
References: <CAAS2fgRdSOu8N6L3+fBpnye+rM+W6+F=cePy=9oL4tJuCj=Jsw@mail.gmail.com>
	<E7A3E345-15C9-4C4C-B3D7-C75634243430@gmail.com>
	<CAAS2fgSXOkTcJ5tTssuGMCQwh-JFQTkzU5VBjaR+hKT+bD3Q6A@mail.gmail.com>
To: Gregory Maxwell <greg@xiph.org>
X-Mailer: Apple Mail (2.3273)
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
	LOTS_OF_MONEY, 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
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 08:05:19 -0000

Thank-you for your prompt response,

I believe I must have a different prospective of Bitcoin to you.  =
Ideologically I don=E2=80=99t agree that miners can be passive =
participants in the Bitcoin Network; and I certainly don=E2=80=99t see =
them acting as passive participants in the Bitcoin Community now.

The miners are very much political actors.  Hence why I fail to =
take-to-heart your concern "that the proposal will reject the blocks of =
passive participants=E2=80=9D.

With AsicBoost, there are three miner groups: Those who use it (and have =
legal sanction to do so); Those who use it (without legal sanction); and =
those who don=E2=80=99t use it.  If SegWit didn=E2=80=99t directly =
affect miners, then one could possibly claim that there could be an =
ideal passive participant miner in reality. However since your important =
revelations on AsicBoost: SegWit cannot be a =E2=80=98passive=E2=80=99 =
option for miners.

Hence, I don=E2=80=99t care about orphaning the blocks of of the =
theoretical "passive participant=E2=80=9D miner. As I have no logical =
reasoning to suggest one could exists; and a large amount of evidence to =
suggesting one dose not exit.


On BIP 16 vs. BIP 17;  I cannot see how BIP 148 similar engineering =
tradeoffs.  Is there any long-term =E2=80=98technical debt=E2=80=99 from =
BIP 148 that I=E2=80=99m unaware of that could be similar to BIP 16?


On the Drama:  Well 100M USD p/a can pay for lots of Drama; Hence going =
back to the first point: The miners are not passive participants when it =
comes to *any* form of activation of SegWit.

Cameron.



> On 15 Apr 2017, at 10:04 AM, Gregory Maxwell <greg@xiph.org> wrote:
>=20
> On Sat, Apr 15, 2017 at 6:28 AM, Cameron Garnham <da2ce7@gmail.com> =
wrote:
>> As many may remember, there was quite some controversy about the =
BIP16 vs BIP 17 split; the main argument for BIP16 was the urgency of =
P2SH, and how this was the already =E2=80=9Ctested and proven to work=E2=80=
=9D solution.
>=20
> And as a result we ultimately got a clearly inferior solution (520
> byte script limit; 80-bit security; months of orphaned blocks-- and
> two of those were not issues in BIP17).  I went along for the cram
> fest on 16 after 12 caught fire, and I was mistaken to do so.
>=20
> Doubly so because it took years for P2SH to achieve any kind of mass
> deployment due to issues far away from consensus.  An extra two months
> spent on some ground-work (including communications and documentation)
> could have pulled forward practical deployment by a year and given
> time to find and fix some of the flaws in the design of P2SH.
>=20
>> BIP 148 is out (our?) terms of peace.  The Bitcoin Community is =
tired-to-death of this war and wants a resolution swiftly. BIP 148 =
proves a outlet, and in Maxwell words: =E2=80=9C...almost guarantees at =
a minor level of disruption.=E2=80=9D.
>=20
> It seems I lost a word in my comment: that should have been "almost
> guarantees at _least_ a minor level of disruption". A minor level of
> disruption is the _minimum_ amount of disruption, and for no good
> reason except an unprecedented and unjustified level of haste.
>=20
> Considering that you did not spare a single word about the specific
> property that I am concerned about-- that the proposal will reject the
> blocks of passive participants, due to avoidable design limitations--
> I can't help but feel that you don't even care to understand the
> concern I was bringing up. :(
>=20
> How many people barely reviewed the specifics of the proposal simply
> because they want something fast and this proposal does something
> fast?
>=20
>> tired-to-death of this war and wants a resolution swiftly
>=20
> By now competitors and opponents to Bitcoin have surely realized that
> they can attack Bitcoin by stirring up drama.
>=20
> As a result, the only way that we will ever be free from "war" is if
> we choose to not let it impact us as much as possible. We must be
> imperturbable and continue working at the same level of excellence as
> if virtual shells weren't flying overhead-- or otherwise there is an
> incentive to keep them flying 24/7. Internet drama is remarkably cheap
> to generate. "The only thing we have to fear is fear itself".
>=20
> The alternative is that we hand opponents a ready made formula for
> disruption: astroturf enough drama up that Bitcoiners "sacrifice
> correctness" themselves right off a cliff in a futile attempt to make
> it go away. :)