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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1VdMQs-00023s-QV
for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 15:51:14 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.176 as permitted sender)
client-ip=209.85.217.176; envelope-from=gmaxwell@gmail.com;
helo=mail-lb0-f176.google.com;
Received: from mail-lb0-f176.google.com ([209.85.217.176])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VdMQs-0008Bh-1q
for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 15:51:14 +0000
Received: by mail-lb0-f176.google.com with SMTP id z5so5577441lbh.35
for <bitcoin-development@lists.sourceforge.net>;
Mon, 04 Nov 2013 07:51:07 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.152.202.167 with SMTP id kj7mr1531706lac.43.1383580267306;
Mon, 04 Nov 2013 07:51:07 -0800 (PST)
Received: by 10.112.63.164 with HTTP; Mon, 4 Nov 2013 07:51:07 -0800 (PST)
In-Reply-To: <CANEZrP3iYBdg3p7Ru4O-UENY_yyQDA8=9PGn=KDKGGTrZ-xkRw@mail.gmail.com>
References: <CANEZrP3iYBdg3p7Ru4O-UENY_yyQDA8=9PGn=KDKGGTrZ-xkRw@mail.gmail.com>
Date: Mon, 4 Nov 2013 07:51:07 -0800
Message-ID: <CAAS2fgQsq0XWb7FZRFrJUmorQfeS=xXa-R4LWneq2LS48tFmng@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.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
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: plan99.net]
X-Headers-End: 1VdMQs-0008Bh-1q
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Auto-generated miner backbone
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: Mon, 04 Nov 2013 15:51:15 -0000
On Mon, Nov 4, 2013 at 3:26 AM, Mike Hearn <mike@plan99.net> wrote:
> I'm wondering about an alternative protocol change that perhaps has less
> subtle implications than their suggested change. Rather than address the
> problem by assuming the network is full of sybil nodes and changing the
> rules for selecting the chain to build on, how about if we wrote code to
> automatically build a miner backbone by having IP addresses of nodes
> embedded into coinbases, then having any bitcoind that is creating work
> automatically connect to IPs that appeared in enough recent blocks?
Yea, I've proposed this too (both in the past and in the context of
this). I don't think, however, that the announcements need to be the
miners themselves=E2=80=94 but instead just need to be nodes that the miner=
s
think are good (and, for their own sake=E2=80=94 ones they're well connecte=
d
to).
Miner's could keep a list of address messages nodes they
like/are-connected to, perhaps prioritizing their own nodes, than
exclude ones which are already in the most recent blocks, and include
the best remaining. Of course, if it's using address messages (or
perhaps a new address message syntax) it would automatically support
hidden services.
They should probably be included as OP_RETURN outputs in coinbase
transactions, maybe only limited (by what other clients pay attention
to) to one or two per block.
This should make it harder to get partitioned from the majority
hashrate (or partition the majority hashrate from itself), though
these hosts would be DOS targets, so it isn't a silver bullet.
Making the majority hashrate self-unpartitionabilty stronger is
possible=E2=80=94 have miners add an encryption key to their coinbase
transactions, then have subsequent miners mine encrypted addr messages
to single other block sources to automatically weave a miner darknet
with access controlled by successful block creation. But I doubt it's
worth the complexity of bandwidth.
|
