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; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
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
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
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Auto-generated miner backbone
Precedence: list

--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">&lt;<a href=3D"mailto:pete@petertodd.org" target=3D"_blank">pete@petert=
odd.org</a>&gt;</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&#39;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 &quot;getextra&quot; message would let nodes query for i=
t.</div>
<div><br></div><div>The hash can be short because it doesn&#39;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--