Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of mckay.com
	designates 37.1.88.131 as permitted sender)
	client-ip=37.1.88.131; envelope-from=robert@mckay.com;
	helo=mail.mckay.com; 
To: Mike Hearn <mike@plan99.net>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
Date: Wed, 15 Jan 2014 23:37:15 +0000
From: Robert McKay <robert@mckay.com>
In-Reply-To: <5747D5DF-879B-4A60-8BD6-18251E7D5F47@plan99.net>
References: <5747D5DF-879B-4A60-8BD6-18251E7D5F47@plan99.net>
Message-ID: <60844494f46e330ec38f9275bc33f30b@webmail.mckay.com>
User-Agent: Roundcube Webmail/0.5.3
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Tor / SPV
Precedence: list

On Wed, 15 Jan 2014 23:51:21 +0100, Mike Hearn wrote:
> The goal of all that is that we get to keep our existing IPv4 based
> anti-sybil heuristics, so we can’t possibly make anything worse,
> only better. Plus, we’ve now set things up so in future if/when we
> come up with a better anti-sybil system based on anonymous identities
> or other fancy crypto, we can take out the “connect via clearnet”
> step and go straight to using hidden services with only a very small
> set of code changes and no new protocol work.

I think it might be ok to use proof-of-stake on as an anti-sybil scheme 
on tor.. people would obviously not want to associate their wallet with 
their IP address, but is there any harm in associating it with a 
(temporary) tor service id (especially one that isn't used for anything 
other than relaying bitcoin transactions)? If each node you connect too 
can sign some challenge with a key that controls some BTC (and your 
client node verifies that the funds are different) then that might be 
useful.. even if it were only a small 0.01BTC stake that would be 
similar to the cost of obtaining another IP through a cheap VPS or VPN 
and significantly higher than the cost to an attacker who is able to 
MITM everything and operate on any IP anyway.

Rob