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
114
115
116
117
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1VdIIm-0000ym-Un
for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 11:26:37 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.182 as permitted sender)
client-ip=209.85.214.182; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f182.google.com;
Received: from mail-ob0-f182.google.com ([209.85.214.182])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VdIIl-0003Yq-Tx
for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 11:26:36 +0000
Received: by mail-ob0-f182.google.com with SMTP id wn1so6906099obc.41
for <bitcoin-development@lists.sourceforge.net>;
Mon, 04 Nov 2013 03:26:30 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.22.33 with SMTP id a1mr232321obf.60.1383564390562; Mon,
04 Nov 2013 03:26:30 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.156.42 with HTTP; Mon, 4 Nov 2013 03:26:30 -0800 (PST)
Date: Mon, 4 Nov 2013 12:26:30 +0100
X-Google-Sender-Auth: LPCsa2OTMBs6yD37im-G_XrjIes
Message-ID: <CANEZrP3iYBdg3p7Ru4O-UENY_yyQDA8=9PGn=KDKGGTrZ-xkRw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=001a1133177c0605cf04ea5830bb
X-Spam-Score: -0.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
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
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: arxiv.org]
1.0 HTML_MESSAGE BODY: HTML included in message
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: 1VdIIl-0003Yq-Tx
Subject: [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 11:26:37 -0000
--001a1133177c0605cf04ea5830bb
Content-Type: text/plain; charset=UTF-8
W.R.T. this paper and the oft-discussed miner backbone,
http://arxiv.org/pdf/1311.0243v1.pdf
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?
This would have the effect of automatically linking all the major pools
together, with no administration overhead.
For bonus points, the IPs could be IPv6 and then the trick we use to pack
hidden services into IPv6 address space would allow nodes to be reached via
Tor. This might be useful in the case of pools that don't to reveal the
location of their bitcoin node[s], like for anti-DoS reasons.
It feels like this should be achievable with a few days of solid coding and
a couple of new command line flags, and the impact is much easier to reason
about than a fundamental rule change like the one proposed by the paper.
--001a1133177c0605cf04ea5830bb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">W.R.T. this paper and the oft-discussed miner backbone,<di=
v><br></div><div>=C2=A0=C2=A0<a href=3D"http://arxiv.org/pdf/1311.0243v1.pd=
f">http://arxiv.org/pdf/1311.0243v1.pdf</a><br></div><div><br></div><div>I&=
#39;m wondering about an alternative protocol change that perhaps has less =
subtle implications than their suggested change. Rather than address the pr=
oblem 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 automat=
ically build a miner backbone by having IP addresses of nodes embedded into=
coinbases, then having any bitcoind that is creating work automatically co=
nnect to IPs that appeared in enough recent blocks?=C2=A0</div>
<div><br></div><div>This would have the effect of automatically linking all=
the major pools together, with no administration overhead.</div><div><br><=
/div><div>For bonus points, the IPs could be IPv6 and then the trick we use=
to pack hidden services into IPv6 address space would allow nodes to be re=
ached via Tor. This might be useful in the case of pools that don't to =
reveal the location of their bitcoin node[s], like for anti-DoS reasons.</d=
iv>
<div><br></div><div>It feels like this should be achievable with a few days=
of solid coding and a couple of new command line flags, and the impact is =
much easier to reason about than a fundamental rule change like the one pro=
posed by the paper.</div>
</div>
--001a1133177c0605cf04ea5830bb--
|
