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
|
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 <gmaxwell@gmail.com>) id 1Sir9Z-0006gG-ML
for bitcoin-development@lists.sourceforge.net;
Sun, 24 Jun 2012 18:03:17 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.181 as permitted sender)
client-ip=209.85.216.181; envelope-from=gmaxwell@gmail.com;
helo=mail-qc0-f181.google.com;
Received: from mail-qc0-f181.google.com ([209.85.216.181])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Sir9Y-0000WN-8x
for bitcoin-development@lists.sourceforge.net;
Sun, 24 Jun 2012 18:03:17 +0000
Received: by qcpx40 with SMTP id x40so1817428qcp.12
for <bitcoin-development@lists.sourceforge.net>;
Sun, 24 Jun 2012 11:03:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.224.207.4 with SMTP id fw4mr17101645qab.82.1340560990795; Sun,
24 Jun 2012 11:03:10 -0700 (PDT)
Received: by 10.229.192.201 with HTTP; Sun, 24 Jun 2012 11:03:10 -0700 (PDT)
In-Reply-To: <CANEZrP0nagdAXyMEY5yxyXBjdo78YC16mjUG9=b0AMe4qOS=fA@mail.gmail.com>
References: <CANEZrP0nagdAXyMEY5yxyXBjdo78YC16mjUG9=b0AMe4qOS=fA@mail.gmail.com>
Date: Sun, 24 Jun 2012 14:03:10 -0400
Message-ID: <CAAS2fgSWb2v6F2xbK0ZFNPz5cwgf6zwB8QbRYgyS1u8xmgAUTQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.5 (-)
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
0.1 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1Sir9Y-0000WN-8x
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [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 18:03:17 -0000
On Sun, Jun 24, 2012 at 8:45 AM, Mike Hearn <mike@plan99.net> wrote:
> 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
Link?
I also proposed this on this list (see the response in the tree
datastructures thread) along with more elaboration on IRC. If multiple
people are coming up with it thats a good sign that it it might
actually be viable. :)
I was going for a slightly different angle and pointing out that the
proofs would mean that a node doing validation with TxOUT tree which
hasn't personally wittnessed the complete history of Bitcoin actually
has basically the same security=E2=80=94 including resistance to miners
creating fake coin in the past=E2=80=94 as a full node today because in ord=
er
to get away with a lie every single node must conspire: It's adequate
that only one honest node wittness the lie because once it has the
proof information is hard to suppress.
To save people from having to dig through the public IRC logs for what
I wrote there:
--- Day changed Thu Jun 21 2012
15:10 < gmaxwell> etotheipi_: amiller: an interesting point with all
this txout tree stuff is that if you join the network late and just
trust that the history is correct based on the headers, any other node
who has witnessed a rule violation in the past can prepare a small
message which you would take to be conclusive proof of a rule
violation and then ignore that chain.
15:11 < gmaxwell> e.g. if someone doublespends I just take the
conflicting transactions out and the segments connecting them to the
chain... and show them to you. And without trusting me you can now
ignore the entire child chain past that point.
15:13 < gmaxwell> This fits nicely with the Satoshi comment "It takes
advantage of the nature of information being easy to spread but hard
to stifle" ... it would be safe to late-join a txout tree chain,
because if there is only a single other honest node in the world who
was around long enough to wittness the cheating, he could still tell
you and it would be as good as if you saw it yourself.
15:17 < gmaxwell> (this is akin to the provable doublespend alert
stuff we talked about before, but applied to blocks)
|
