From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Qp83s-0005GT-DW for bitcoin-development@lists.sourceforge.net; Fri, 05 Aug 2011 00:14:48 +0000 X-ACL-Warn: Received: from sulfur.webpack.hosteurope.de ([217.115.142.104]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1Qp83q-0005qC-Vv for bitcoin-development@lists.sourceforge.net; Fri, 05 Aug 2011 00:14:48 +0000 Received: from 84-72-69-153.dclient.hispeed.ch ([84.72.69.153] helo=[192.168.0.21]); authenticated by sulfur.webpack.hosteurope.de running ExIM with esmtpsa (TLSv1:AES256-SHA:256) id 1Qp83k-0000xY-R3; Fri, 05 Aug 2011 02:14:40 +0200 Message-ID: <4E3B35E7.1010409@justmoon.de> Date: Fri, 05 Aug 2011 02:14:31 +0200 From: Stefan Thomas 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> <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 X-bounce-key: webpack.hosteurope.de;moon@justmoon.de;1312503287;541078bc; X-Spam-Score: 0.0 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. X-Headers-End: 1Qp83q-0005qC-Vv Subject: Re: [Bitcoin-development] Double spend detection to speed up transaction trust X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Aug 2011 00:14:48 -0000 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.