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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1U5pei-0007bn-5Q
for bitcoin-development@lists.sourceforge.net;
Thu, 14 Feb 2013 03:38:40 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.181 as permitted sender)
client-ip=209.85.217.181; envelope-from=gmaxwell@gmail.com;
helo=mail-lb0-f181.google.com;
Received: from mail-lb0-f181.google.com ([209.85.217.181])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1U5peg-0007BO-Ia
for bitcoin-development@lists.sourceforge.net;
Thu, 14 Feb 2013 03:38:39 +0000
Received: by mail-lb0-f181.google.com with SMTP id gm6so1437431lbb.26
for <bitcoin-development@lists.sourceforge.net>;
Wed, 13 Feb 2013 19:38:32 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.152.125.239 with SMTP id mt15mr22327075lab.26.1360813111981;
Wed, 13 Feb 2013 19:38:31 -0800 (PST)
Received: by 10.112.96.164 with HTTP; Wed, 13 Feb 2013 19:38:31 -0800 (PST)
In-Reply-To: <CADb9v0Kf1TfzWnUb3J8YNsLUxsbkeFX2nZXRnW5JJnmfDV9psQ@mail.gmail.com>
References: <CAN1xFdrX61HsRxsXxXW+i0FzjQkoNVRaDG-2yJNOfYUi5FnsPA@mail.gmail.com>
<CAAS2fgTwjXCGFS-N8a8Ro80ahxXT01dCfqWYOqmwCkdRramaMg@mail.gmail.com>
<CAN1xFdrGiWmn_EaBNMXXZAV38oeqP14YiMzMZQrkA+WL9QEMfA@mail.gmail.com>
<CAAS2fgR5=nLTBQUBzjZQs91AVw5XSTiqe-KB_T9R9wKfBrOq6Q@mail.gmail.com>
<CABsx9T2RWamFxebVJExo_4NT4WPPE=Fd4deG1AFmT=GqjD=vwQ@mail.gmail.com>
<CADb9v0L9RgfK8=FaM-tZm7AcYMhP6+OAyWu4x+3pLrrQ8yoeLw@mail.gmail.com>
<CAAS2fgQRineAXRs9uaLRv-YaXMfjd+ietzd1aRmYV98N0y=OuQ@mail.gmail.com>
<CADb9v0Kf1TfzWnUb3J8YNsLUxsbkeFX2nZXRnW5JJnmfDV9psQ@mail.gmail.com>
Date: Wed, 13 Feb 2013 19:38:31 -0800
Message-ID: <CAAS2fgTNQZkUo3k4Uke7sLrZd1=o2TO1BLtdA6_Q7hUegHRQHQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Stephen Pair <stephen@bitpay.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1U5peg-0007BO-Ia
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Incorporating block validation rule
modifications into the block chain
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 14 Feb 2013 03:38:40 -0000
On Wed, Feb 13, 2013 at 6:44 PM, Stephen Pair <stephen@bitpay.com> wrote:
> One of the beauties of bitcoin is that the miners have a very strong ince=
ntive to distribute as widely and as quickly as possible the blocks they fi=
nd...they also have a very strong incentive to hear about the blocks that o=
thers find. There will not be an issue with blocks being "jealously guarde=
d"
Then perhaps I totally misunderstood what you were suggesting. I
believed you were saying blocksize would be controlled by people
having to pay to receive and pay to have blocks forwarded.
>(by which I mean the fee or cost associated with the bandwidth and validat=
ion that a transaction requires) with some amount of profit. This means th=
at the relay node will not fetch and propagate those transactions whose fee=
is too small (unless there was some other fee structure outside the miners=
fee).
The only fee-or-cost they're worrying about is their own marginal
costs. This says nothing about the externalized cost of the hundreds
of thousands of other nodes which also must validate the block they
produce, many of which are not miners=E2=80=94 if we are well distributed=
=E2=80=94 and
thus don't have any way to monetize fees. And even if they are all
miners for some reason, if these fees are paying the ever growing
validation/storage costs what expenditure is left for the proof of
work that makes Bitcoin resistant to reversal?
If the cost is soaked up by validation/forwarding then the capacity to
run a validating node ends up being the barrier to entry and
difficulty would be very low... which sounds fine until you realize
that an attacker doesn't have validation costs, and that selfish
("optimally rational") miners could just eschew validation (who cares
if you lose some blocks to invalidity if you're producing them so much
cheaper than the honest players?).
> It is good to be wary of these potential issues, but I don't see how the =
economics are likely to yield the outcome you fear. And, really, there's n=
ot a lot that can be done to prevent economics from dictating the ultimate =
outcome. In fact, what I write above is not so much about what I think *sh=
ould* be built, it's more about what I *predict* will be built.
What I want is for economics to dictate a positive outcome. They can
do this how the system is currently constructed where the economics of
using the system are clearly aligned with securing it.
|
