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
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1VdIin-0001H2-Fw
for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 11:53:29 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.154 as permitted sender)
client-ip=62.13.148.154; envelope-from=pete@petertodd.org;
helo=outmail148154.authsmtp.co.uk;
Received: from outmail148154.authsmtp.co.uk ([62.13.148.154])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VdIim-0004y9-4x for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 11:53:29 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt6.authsmtp.com (8.14.2/8.14.2) with ESMTP id rA4BrLZs057493;
Mon, 4 Nov 2013 11:53:21 GMT
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rA4BrFEw081380
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Mon, 4 Nov 2013 11:53:17 GMT
Date: Mon, 4 Nov 2013 06:53:14 -0500
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20131104115314.GA1013@savin>
References: <CANEZrP3iYBdg3p7Ru4O-UENY_yyQDA8=9PGn=KDKGGTrZ-xkRw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9"
Content-Disposition: inline
In-Reply-To: <CANEZrP3iYBdg3p7Ru4O-UENY_yyQDA8=9PGn=KDKGGTrZ-xkRw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: b20b14e8-4547-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdgYUFloCAgsB AmUbWlVeVV57WGs7 bAxPbAVDY01GQQRq
WVdMSlVNFUsqcBhz RGhrFRl6dgZOeDBx ZkRqXz4JXkQodEIo
SlNQEGkBeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4iAyI7 Ah8PGzg1FFEIS202
LhorMBYWFU0SOEI0 PDMA
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
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 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: petertodd.org]
X-Headers-End: 1VdIim-0004y9-4x
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 11:53:29 -0000
--PEIAKu/WMn1b1Hv9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Nov 04, 2013 at 12:26:30PM +0100, Mike Hearn wrote:
> W.R.T. this paper and the oft-discussed miner backbone,
>=20
> http://arxiv.org/pdf/1311.0243v1.pdf
>=20
> 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?
I proposed this as a means of giving a mechanism for wallets to get
non-sybilled peers as well.
> This would have the effect of automatically linking all the major pools
> together, with no administration overhead.
>=20
> 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 v=
ia
> 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.
>=20
> It feels like this should be achievable with a few days of solid coding a=
nd
> a couple of new command line flags, and the impact is much easier to reas=
on
> about than a fundamental rule change like the one proposed by the paper.
Doing so encourages pools to only bother connecting to other pools,
which is a strong centralizing force. But given the nasty incentives
present anyway - it's in your advantage to distribute your blocks to no
more than a majority of hashing power if you can do so consistently -
I'm unconvinced that this won't happen anyway.
The maximal benefit would be if two sets of addresses were published:
public and private. The issue with publishing addresses is DoS attacks,
but publishing Tor addresses doesn't stop attacks. What would discourage
attacks however would be to encrypt that data such that only the
creators of specific prior blocks could decrypt it. This limits the
audience to those with incentives not to commit a DoS attack. (DoS
attack the IP, and you'll no longer get preferential peering)
Say what you want about centralization, but for the pools involved it's
a good idea.
On a technical level, the coinbase is limited in size, and people use it
for other purposes, so lets define a standard where this data is stored
in an OP_RETURN txout of the form:
OP_RETURN <key> <value> <key> <value> ...
Multiple values with the same key should be allowed. This data should be
placed in the last txout so that SPV nodes can eventually be given it
with a SHA256 midstate.
--=20
'peter'[:-1]@petertodd.org
00000000000000080e395c361bdf9db583d5f4c0e144f476c229285b15eae59c
--PEIAKu/WMn1b1Hv9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQGrBAEBCACVBQJSd4qqXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMGE2ZGQ5NmM1NTFlY2E3Mjk5NDYzZTRlNTIzNDYyNzk4YTAw
NjUzNWY0MTJiNTE5YzcvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfurmQf/SQOlv6xWFDlco0Kc6PeawDJF
eJ39EqKZ5rqxkIVMspJtBXrg30+aF/ZeU2fQIfRRSi5iED1exTm+y+a5trXhrm2A
PUNMLBEhztemzC+7B8HOZ983Pm7YHMO57xiuDHXDjbwdRPeq0cxkLG4PqxUnzMzB
jNII1PXLjpD9z9M3PAHVugcEboqiuaXgKvoP5gMMjliFrjwT14V5Ojai/tjfb4YS
sZKH5xWYQlGSPZFW4Qp0TDOUuQXmo8gDlkTZHUs3q4pvri6HKEOPQv4TlUNijxhV
iEwfEmy4wBk3QMEjl8M1RTMREN7r/CqsfKey9xc/fMU8ViQzBmXvN2xtZajIBw==
=6FFl
-----END PGP SIGNATURE-----
--PEIAKu/WMn1b1Hv9--
|
