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 --]
next prev parent 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 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$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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