public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Double spend detection to speed up transaction trust
Date: Fri, 5 Aug 2011 14:03:05 +0100	[thread overview]
Message-ID: <201108051403.05506.andyparkins@gmail.com> (raw)
In-Reply-To: <1312545969.4516.8.camel@BMThinkPad.lan.bluematt.me>

[-- Attachment #1: Type: Text/Plain, Size: 2133 bytes --]

On 2011 August 05 Friday, Matt Corallo wrote:
> On Fri, 2011-08-05 at 12:58 +0100, Andy Parkins wrote:
> > I don't really see that "number of connections" is the relevant metric.
> 
> Number of connections is something that needs serious thought.  Too many
> and you fill everyone's connection slots and no one can make
> connections.  Too few and you don't have a network but just a bunch of
> islands which would also cause serious problems.
> If you aren't relaying, each connection takes almost no bandwidth, so
> the question is how many do you need to be considered secure.

I'm arguing that "number of connection slots" isn't the best metric; so that 
wouldn't matter.  Just keep accepting incoming connections (with some sanity 
limit of course) until you've allocated your bandwidth, not your number of 
connections.

If I connect to a thousand nodes and never send anything, I'm not using up 
very much of their resources.  If _they_ want to use up resources by relaying, 
then that is their choice, but again they can do that based on bandwidth 
calculations rather than connection counts.  If I am sending, then that adds 
to their bandwidth and gets included in whatever limit they've chosen.

For example: the client could simply maintain an average bandwidth over all 
connections.  If that average is less than threshold0, then make new outgoing 
connections.  If that average exceeds threshold1, then stop accepting incoming 
connections.  If it exceeds threshold2, start dropping established incoming 
connections.  If it exceeds theshold3, start dropping established outgoing 
connections.

The actual rules don't matter so much; I'm just saying bandwidth is a better 
metric than connection count.  If you limit by connection count, then you'll 
just end up filled with non-relaying listeners, since they (in the future) 
will be the most commonplace.  You'll have no incoming relays, and therefore 
nothing to forward, so your bandwidth will be zero, but your connection count 
at maximum -- you've locked yourself out.



Andy
-- 
Dr Andy Parkins
andyparkins@gmail.com

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

  reply	other threads:[~2011-08-05 13:03 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
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 [this message]
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=201108051403.05506.andyparkins@gmail.com \
    --to=andyparkins@gmail.com \
    --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