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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1VdIpT-00014I-Jf
for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 12:00:23 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.219.54 as permitted sender)
client-ip=209.85.219.54; envelope-from=mh.in.england@gmail.com;
helo=mail-oa0-f54.google.com;
Received: from mail-oa0-f54.google.com ([209.85.219.54])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VdIpR-0004mX-LX
for bitcoin-development@lists.sourceforge.net;
Mon, 04 Nov 2013 12:00:23 +0000
Received: by mail-oa0-f54.google.com with SMTP id o20so7092821oag.27
for <bitcoin-development@lists.sourceforge.net>;
Mon, 04 Nov 2013 04:00:16 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.71.82 with SMTP id s18mr14098679obu.9.1383566416254;
Mon, 04 Nov 2013 04:00:16 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.156.42 with HTTP; Mon, 4 Nov 2013 04:00:16 -0800 (PST)
In-Reply-To: <20131104115314.GA1013@savin>
References: <CANEZrP3iYBdg3p7Ru4O-UENY_yyQDA8=9PGn=KDKGGTrZ-xkRw@mail.gmail.com>
<20131104115314.GA1013@savin>
Date: Mon, 4 Nov 2013 13:00:16 +0100
X-Google-Sender-Auth: PGQBfhh9FgHDaC6gt5EozwJd8iE
Message-ID: <CANEZrP1uqee1UO=zb+50t9BNtv2voTHoCKQCTQExNyoL=Y0=PA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=e89a8fb1fde6c3a06504ea58a8ba
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
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]
-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
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: 1VdIpR-0004mX-LX
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 12:00:23 -0000
--e89a8fb1fde6c3a06504ea58a8ba
Content-Type: text/plain; charset=UTF-8
On Mon, Nov 4, 2013 at 12:53 PM, Peter Todd <pete@petertodd.org> wrote:
> I proposed this as a means of giving a mechanism for wallets to get
> non-sybilled peers as well.
>
Ah yes, good point.
> Doing so encourages pools to only bother connecting to other pools,
> which is a strong centralizing force.
>
They could already create such a setup, but we don't observe it in practice.
> On a technical level, the coinbase is limited in size, and people use it
> for other purposes, so lets define a standard ....
Given that IP address data is inherently transient, perhaps a better
solution is to define a short hash in the coinbase that commits to extra
data that is relayed along with block data (e.g. appended to the block
message). It can then be stored temporarily in the block db and erased
after some time, like a few months. It would therefore not really be a part
of the chain, but could be extended as we see fit with any other
semi-transient data required. A new "getextra" message would let nodes
query for it.
The hash can be short because it doesn't have to survive brute forcing
attacks longer than the expected validity period of the transient data
anyway. 80 bits would probably be overkill.
--e89a8fb1fde6c3a06504ea58a8ba
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Mon, Nov 4, 2013 at 12:53 PM, Peter Todd <span dir=3D"l=
tr"><<a href=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petert=
odd.org</a>></span> wrote:<br><div class=3D"gmail_extra"><div class=3D"g=
mail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im"><span style=3D"color:rgb(3=
4,34,34)">I proposed this as a means of giving a mechanism for wallets to g=
et</span><br>
</div>
non-sybilled peers as well.<br></blockquote><div><br></div><div>Ah yes, goo=
d point.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D"im"><span style=3D"color:rgb(34,34,34)">Doing so encourages p=
ools to only bother connecting to other pools,</span><br></div>
which is a strong centralizing force.<br></blockquote><div><br></div><div>T=
hey could already create such a setup, but we don't observe it in pract=
ice.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On a technical level, the coinbase is limited in size, and people use it<br=
>
for other purposes, so lets define a standard ....</blockquote><div><br></d=
iv><div>Given that IP address data is inherently transient, perhaps a bette=
r solution is to define a short hash in the coinbase that commits to extra =
data that is relayed along with block data (e.g. appended to the block mess=
age). It can then be stored temporarily in the block db and erased after so=
me time, like a few months. It would therefore not really be a part of the =
chain, but could be extended as we see fit with any other semi-transient da=
ta required. A new "getextra" message would let nodes query for i=
t.</div>
<div><br></div><div>The hash can be short because it doesn't have to su=
rvive brute forcing attacks longer than the expected validity period of the=
transient data anyway. 80 bits would probably be overkill.</div></div>
</div></div>
--e89a8fb1fde6c3a06504ea58a8ba--
|
