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
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6A5BE4A8
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Jul 2015 18:00:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wi0-f181.google.com (mail-wi0-f181.google.com
[209.85.212.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 32AF8161
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Jul 2015 18:00:12 +0000 (UTC)
Received: by wibxm9 with SMTP id xm9so212231922wib.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 29 Jul 2015 11:00:10 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type
:content-transfer-encoding;
bh=GbP4cU3t5/BxgKobcN0e/ix8atVCCcCHLuwIufZX3ME=;
b=bogTjFtQ7vXFxyNaM+PjLFabqvFGOFFX/PLFIirSU1nk1+GSkEeMP9QPAOkAn1LL0P
emld+Cc7iukQMdF33H0j1A6dc77pubgWUzRpxq+n29O6Z0woWAJmZumSP8YyrIjsFPPz
DXWopgqSaW+ShvcCA/skhQHeBc2C/v46tC5gd8Ik5nL5h5Chu+65I8Gs9um3sXCng7Eg
AEa2K7vdqJI1OkA1D9Dfw4flNvvZ4+wu+R/Nw45AVKhuX735Rf4AeE7NLdls+5Rl6TVt
Bx6CBcvt1OolJGEJmKCxpIgT3jwO1wN4eIKwVldHTCB306yNTLabbHETD/IgcfZTpUaQ
MxDQ==
X-Gm-Message-State: ALoCoQnEqXMd1LpBHsHRZ+xX7OoWJMqelHZBAHu5xy7wzrf2/WuuJf/Edh+OzCbKWVgOxJJ8OM+D
MIME-Version: 1.0
X-Received: by 10.180.37.74 with SMTP id w10mr5355502wij.92.1438192810777;
Wed, 29 Jul 2015 11:00:10 -0700 (PDT)
Received: by 10.194.95.168 with HTTP; Wed, 29 Jul 2015 11:00:10 -0700 (PDT)
In-Reply-To: <D25BD175-7099-4A6B-89BB-A35E94F555A9@gmail.com>
References: <1B7F00D3-41AE-44BF-818D-EC4EF279DC11@gmail.com>
<CA+w+GKTfPXkVPaCC+3ZsQv=_DPMHoRwbigS40Testpyq4rZxsw@mail.gmail.com>
<D25BD175-7099-4A6B-89BB-A35E94F555A9@gmail.com>
Date: Wed, 29 Jul 2015 20:00:10 +0200
Message-ID: <CABm2gDqdN9o0SrpSRA3WPAaMGhbBY3EvXcE-KHa0q2qQgxaQ3Q@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
To: Eric Lombrozo <elombrozo@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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 Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn't
temporary
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, 29 Jul 2015 18:00:13 -0000
On Wed, Jul 29, 2015 at 12:43 PM, Eric Lombrozo via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Erm=E2=80=A6most miners just trust mining pool operators to validate bloc=
ks for
> them=E2=80=A6and some of the biggest pools have been blatantly cutting co=
rners. Yes,
> a few pools might have temporarily bled a little=E2=80=A6but properly val=
idating is
> probably not the equilibrium strategy=E2=80=A6and as time goes on, they a=
re likely
> to start cutting corners again. Whether they ultimately bleed money isn=
=E2=80=99t
> really the point - many believe that cutting corners is actually a ration=
al
> strategy. If you want to discuss the game theory behind this, fine=E2=80=
=A6but the
> fact some of the biggest mining pool operators are on record saying they =
are
> likely to continue doing this is enough to seriously put to question one =
of
> the most fundamental assumptions behind the network security model.
Actually validating blocks IS the equilibrium strategy. When the
subsidy is completely gone (or at least when the block reward is not
almost exclusively composed of subsidy [a future where fees are not a
completely negligible part of the total reward]), miners will
re-calculate their estimations and they will find out that mining
empty blocks won't be so profitable in a future with less subsidy. In
fact, with the incentives they currently have (negligible fees)
actually bothering about including transactions at all it's not really
worth it for them. They may just do it because they're nice people,
meta-incentives...whatever the reason is, they users are enjoying a
service they're not paying for.
Only subsidy and no fees creates other incentive problems, not just
SPV mining. But apparently some people think that scaring some users
with unreasonable expectations away because they have to pay fees
(still, non-proportional [to the amount you're moving] fees due to the
irreversibility of the payments: something the reversible payments
based on the banking industry can't simply compete with) it's much
worse than perpetuating big incentive problems that could break the
system. And, of course, short term convenience for users is much more
important than figuring out the long term viability of the system once
the seigniorage (spent on the miner's subsidy) goes away.
The pattern seems clear to be: decentralization and long term
viability don't matter too much to some people.
For some people, short term market cap seems to be the most important
priority and everything else is secondary.
|
