public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Stefan Thomas <moon@justmoon.de>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Double spend detection to speed up transaction trust
Date: Fri, 05 Aug 2011 02:14:31 +0200	[thread overview]
Message-ID: <4E3B35E7.1010409@justmoon.de> (raw)
In-Reply-To: <1312496173.3109.55.camel@Desktop666>

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.





  reply	other threads:[~2011-08-05  0:14 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-08-04 13:23 [Bitcoin-development] Double spend detection to speed up transaction trust Andy Parkins
2011-08-04 17:45 ` Matt Corallo
2011-08-04 18:22   ` Andy Parkins
2011-08-04 18:39     ` Matt Corallo
2011-08-04 19:42       ` Andy Parkins
2011-08-04 20:07         ` Andrew Schaaf
2011-08-04 20:38           ` Matt Corallo
2011-08-04 22:10             ` Stefan Thomas
2011-08-04 22:18               ` Gregory Maxwell
2011-08-04 22:21                 ` Matt Corallo
2011-08-05  0:07                   ` Gavin Andresen
2011-08-04 20:08         ` Gregory Maxwell
2011-08-04 20:33         ` Matt Corallo
2011-08-04 21:36         ` Mike Hearn
2011-08-04 22:16           ` Matt Corallo
2011-08-05  0:14             ` Stefan Thomas [this message]
2011-08-05 11:05               ` Mike Hearn
2011-08-05 11:58                 ` Andy Parkins
2011-08-05 12:06                   ` Matt Corallo
2011-08-05 13:03                     ` Andy Parkins
2011-08-05 21:23                       ` Gregory Maxwell
2011-08-05 21:30                       ` Matt Corallo
2011-08-05 12:00               ` Matt Corallo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4E3B35E7.1010409@justmoon.de \
    --to=moon@justmoon.de \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox