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
|
Return-Path: <jgarzik@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 36D31D0B
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Dec 2015 22:09:59 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com
[209.85.213.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C6649ED
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Dec 2015 22:09:58 +0000 (UTC)
Received: by mail-ig0-f173.google.com with SMTP id ph11so164059962igc.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 16 Dec 2015 14:09:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=eBorUrNlE0C2hhFwyFuZBZo4PQ+QN2UoUzK8r/TK3A4=;
b=Xsj8G0L6oZQj9AEK1dlO+Cwv3mkZ63JkYvEnCfdMNro5FNO4obaDP3MWduUg567k9j
WD4wPnlrCCYY6bwk1tgCyGl3KwiJEr2y0MeLqB+whbrlTgbpXIFmmqXCIcIb+eufNfjj
Ony6OyPGtMijswAtRkOYqpZ9muya3VJo/K2TF63h6GEP2s1L+Gn1ZCzVJwRuOjGHmmWN
EF//l+R4Tx9g+z8L0a798MXtfEKaAq/bNJATwhkreMP29Ly6z7ECDSlClZAsUBtQAnBZ
T7Ux3n2My5RGybMopAmL83FVcpdtXP/gYqH9xyUcpEUv/RI+IztF4w9TBUL9sxh6tIX3
WEaQ==
MIME-Version: 1.0
X-Received: by 10.51.17.39 with SMTP id gb7mr150442igd.54.1450303798312; Wed,
16 Dec 2015 14:09:58 -0800 (PST)
Received: by 10.79.8.198 with HTTP; Wed, 16 Dec 2015 14:09:58 -0800 (PST)
In-Reply-To: <CAPg+sBiVVcNNHuV9e1SaPoDSMEwjZHL7tQiszxbE2SQYp1Ongw@mail.gmail.com>
References: <CADm_WcYWh5EnBCzQQVc04sf-0seh2zrmc+5dH8Z-Bo78jhPnfA@mail.gmail.com>
<CAPg+sBhUso0ddfYQMgwF7yX9_VoqP9CZN5h45t3eQi4v3m6f6A@mail.gmail.com>
<CADm_WcYZq3nzfYMXfzkZsTCsgmzy4L_nYpa5Kax8uF_ajuUTiQ@mail.gmail.com>
<CAPg+sBiVVcNNHuV9e1SaPoDSMEwjZHL7tQiszxbE2SQYp1Ongw@mail.gmail.com>
Date: Wed, 16 Dec 2015 17:09:58 -0500
Message-ID: <CADm_WcZbbv9zy_5kN264GhYC_kBBr+Leoi0y1PA4pm23CaW3QQ@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=001a1134b41eb7060e05270b2a71
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin development mailing list <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Segregated Witness in the context of Scaling
Bitcoin
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Wed, 16 Dec 2015 22:09:59 -0000
--001a1134b41eb7060e05270b2a71
Content-Type: text/plain; charset=UTF-8
Maybe a new analogy helps.
SW presents a blended price and blended basket of two goods. You can
interact with the Service through the blended price, but that does not
erase the fact that the basket contains two separate from similar resources.
A different set of economic actors uses one resource, and/or both. There
are explicit incentives to shift actors from solely using one resource to
using both.
The fact that separate sets of economic actors and incentives exist is
sufficient to prove it is indeed a basket of goods, not a single good.
On Wed, Dec 16, 2015 at 4:36 PM, Pieter Wuille <pieter.wuille@gmail.com>
wrote:
> Thus, the miners' best strategy is to accept the witness transactions,
> as it allows 1000000/110=9090 transactions rather than
> 1000000/200=5000.
>
Under your blended algorithm, this seems reasonable as a first pass.
> In fact, the optimal fee maximizing strategy is always to maximize fee
> per virtual size.
>
This is a microscopic, not macroscopic analysis. Externalities and long
term incentives can severely perturb or invalidate that line of thinking.
Typical counter-example: Many miners are perfectly happy with very low
fees to encourage long term growth of their bitcoin income through network
effect growth -- rendering fee micro-optimizations largely in the realm of
DoS prevention rather than miner incentive.
--001a1134b41eb7060e05270b2a71
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Maybe a new analogy helps.<div><br></div><div>SW presents =
a blended price and blended basket of two goods.=C2=A0 You can interact wit=
h the Service through the blended price, but that does not erase the fact t=
hat the basket contains two separate from similar resources.</div><div><br>=
</div><div>A different set of economic actors uses one resource, and/or bot=
h.=C2=A0 There are explicit incentives to shift actors from solely using on=
e resource to using both.</div><div><br></div><div>The fact that separate s=
ets of economic actors and incentives exist is sufficient to prove it is in=
deed a basket of goods, not a single good.</div><div><br></div><div><br></d=
iv><div>On Wed, Dec 16, 2015 at 4:36 PM, Pieter Wuille <span dir=3D"ltr">&l=
t;<a href=3D"mailto:pieter.wuille@gmail.com" target=3D"_blank">pieter.wuill=
e@gmail.com</a>></span> wrote:<br></div><div class=3D"gmail_extra"><div =
class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thus, the miners' =
best strategy is to accept the witness transactions,<br>
as it allows 1000000/110=3D9090 transactions rather than<br>
1000000/200=3D5000.<br></blockquote><div><br></div><div>Under your blended =
algorithm, this seems reasonable as a first pass.</div><div><br></div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex">
In fact, the optimal fee maximizing strategy is always to maximize fee<br>
per virtual size.<br></blockquote><div><br></div><div></div></div></div><di=
v class=3D"gmail_extra">This is a microscopic, not macroscopic analysis.=C2=
=A0 Externalities and long term incentives can severely perturb or invalida=
te that line of thinking.</div><div class=3D"gmail_extra"><br></div><div cl=
ass=3D"gmail_extra">Typical counter-example: =C2=A0Many miners are perfectl=
y happy with very low fees to encourage long term growth of their bitcoin i=
ncome through network effect growth -- rendering fee micro-optimizations la=
rgely in the realm of DoS prevention rather than miner incentive.</div><div=
class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><div =
class=3D"gmail_extra"><br></div></div>
--001a1134b41eb7060e05270b2a71--
|
