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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1SimCX-0004cZ-Te
for bitcoin-development@lists.sourceforge.net;
Sun, 24 Jun 2012 12:46:01 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.169 as permitted sender)
client-ip=209.85.212.169; envelope-from=mh.in.england@gmail.com;
helo=mail-wi0-f169.google.com;
Received: from mail-wi0-f169.google.com ([209.85.212.169])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1SimCV-000411-EY
for bitcoin-development@lists.sourceforge.net;
Sun, 24 Jun 2012 12:46:01 +0000
Received: by wibhn14 with SMTP id hn14so1944712wib.4
for <bitcoin-development@lists.sourceforge.net>;
Sun, 24 Jun 2012 05:45:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.180.95.100 with SMTP id dj4mr17421991wib.17.1340541953297;
Sun, 24 Jun 2012 05:45:53 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.216.254.232 with HTTP; Sun, 24 Jun 2012 05:45:53 -0700 (PDT)
Date: Sun, 24 Jun 2012 14:45:53 +0200
X-Google-Sender-Auth: 1U5sZjJvC1H2bX8Q2ozKZb0lWis
Message-ID: <CANEZrP0nagdAXyMEY5yxyXBjdo78YC16mjUG9=b0AMe4qOS=fA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.4 (-)
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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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
0.1 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1SimCV-000411-EY
Subject: [Bitcoin-development] Enforcing inflation rules for SPV clients
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: Sun, 24 Jun 2012 12:46:02 -0000
I've been having a discussion with d'aniel from the forums=C2=A0about how
to handle the possibility of a majority-miner conspiracy to raise
inflation, if most economic actors use SPV clients.
Because of how blocks are formatted you cannot check the coinbase of a
transaction without knowing the fees in the block, and the fees can
only be calculated if you have all the input transactions for every
transaction in that block. Because the attack scenario is an attempted
takeover of the economy by miners, attempting to put hints into the
blocks won't work - we have to assume the hardest chain is in fact
wrong according to the rules signed up to by the Bitcoin user.
The most obvious goal for a cartel of miners is to change the
inflation formula, either for purely selfish reasons (they want more
money than can be obtained by fees) or due to coercion by
governments/central banks who still subscribe to the "inflation is
good" idea.
Whilst "good" nodes (still on the old ruleset) won't relay blocks that
violate the rules no matter how hard they are, in a situation where an
SPV client DOES hear about the bad best chain, it would switch to it
automatically. And who knows how the network might look in future -
perhaps most nodes would end up run by miners, or other entities that
upgrade to the new ruleset for other reasons.
d'aniel made a good proposal - having good nodes broadcast
announcements when they detect a rule that breaks the rules, along
with a proof that it did so. Checking the proof might be very
expensive, but it would only have to be done for split points,
limiting the potential for DoS. If a node announces that it has a
weaker chain and that the split point is a rule-breaker, the SPV
client would download the headers for the side chain to verify the
split, then download all the transactions in the split block along
with all their inputs, and the merkle branches linking the inputs to
the associated block headers. In this way the fee can be calculated,
the inflation formula applied and the coinbase value checked.
If the block is indeed found to be a rule-breaker, it'd be blacklisted
and chains from that point forward ignored.
Miners may decide to allow themselves to create money with
non-index-zero transactions to work around this. In that case the good
node can announce that a given tx in the rule-breaker block is
invalid. The SPV node would then challenge nodes announcing the longer
chain to provide the inputs for the bad tx all the way back to a
pre-split coinbase.
Doing these checks would be rather time consuming with huge blocks,
but it's a last resort only. In the absence of bugs, the mere presence
of the mechanism should ensure it never has to be used.
|
