Message-ID: <4E3B35E7.1010409@justmoon.de>
Date: Fri, 05 Aug 2011 02:14:31 +0200
From: Stefan Thomas <moon@justmoon.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
	rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <201108041423.14176.andyparkins@gmail.com>
	<201108041922.16956.andyparkins@gmail.com>
	<1312483196.3109.38.camel@Desktop666>
	<201108042042.55214.andyparkins@gmail.com>
	<CANEZrP3kEquEvqkqGqSh0iPRqoHhKLHoNgqc+9EORLoxpL7a=g@mail.gmail.com>
	<1312496173.3109.55.camel@Desktop666>
In-Reply-To: <1312496173.3109.55.camel@Desktop666>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Bitcoin-development] Double spend detection to speed up
 transaction trust
Precedence: list

On 8/5/2011 12:18 AM, Gregory Maxwell wrote:
> Except for the fact that such a party is a DOS attack on the network
> which is already short on functioning listeners.

To the transaction radar it doesn't much matter whether its connections 
are outgoing or incoming (assuming it can keep its nodes' IPs secret and 
it has reasonable uptime). So you could say that this is an argument 
*for* this kind of double spend protection if it means the creation of 
nodes/clusters accepting 10000+ incoming connections while making few 
outgoing connections. My point is, the amount of connections a node has 
has nothing to do with its effect on the in/out balance.

Some words on the shortage of listeners itself:

Could this be because the network right now consists largely of end 
users with residential type networks? With BitTorrent a lot of users go 
through the trouble of opening up ports in their router manually in 
order to get more peers and better download speeds - this is not (yet?) 
a widespread practice with Bitcoin. (I know Bitcoin has UPnP support, 
but I haven't found any numbers on how widely the IGD protocol is 
actually deployed. Wikipedia says that "some NAT routers" support it and 
that it's not an IETF standard. All routers I've actually seen in real 
life had it disabled by default.)

In the long term all the trends favor more clients allowing incoming 
connections: End users will tend to move towards lighter clients and the 
ones that stick with full nodes will tend to configure them better - 
meaning opening ports etc. - as documentation improves.

As for downright malicious nodes: It should be possible to come up with 
some sensible policies to temp ban nodes that don't relay any useful 
messages or try to flood you. This is an ongoing optimization problem in 
any peer-to-peer network and I expect us to make progress with this over 
time.


On 8/5/2011 12:16 AM, Matt Corallo wrote:
> This is exactly what I've been suggesting this whole time.

I had only seen you mention a "miner backbone" which is sort of a more 
long-term vision, whereas Transaction Radar exists today. I didn't read 
everything though, so if you mentioned this idea specifically, please 
just consider my post as further support for your position.