From: Mike Hearn <mike@plan99•net>
To: shadders.del@gmail•com
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Building a node crawler to map network
Date: Tue, 6 Sep 2011 16:52:20 +0200 [thread overview]
Message-ID: <CANEZrP2Wh82sqGjZDn_M=UPufBCU4fP9zEXV_K8JpgVF8O1FCw@mail.gmail.com> (raw)
In-Reply-To: <4E662B79.5090303@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2549 bytes --]
On Tue, Sep 6, 2011 at 4:17 PM, Steve <shadders.del@gmail•com> wrote:
> **
> I'm not really understanding the use case though. I believe most
> bitcoind's have a default max connections of 8. Is the goal to increase
> this without fundamentally altering the bitcoind concurrency model?
>
bitcoind already uses asynchronous IO. That's not the problem.
The issue came up in a conversation about scalability. If Bitcoins
popularity continues to grow, users are very likely to migrate away from
running full verifying nodes to lightweight clients, either a different mode
of the Satoshi client or different implementations like the Android Wallet
or MultiBit.
Lightweight clients cannot verify thus should not relay. And they'll be run
by users who just want to send/receive coins from time to time, so don't
leave the programs running 24/7. The result could be running out of sockets
(like we have had problems with recently). It's especially true because
lightweight clients cannot check transactions for themselves. If they want
to show transactions appearing immediately (and they do), they have to use
"heard from lots of nodes" as a proxy for validity. So lightweight clients
are likely to be socket intensive.
We could solve this by just hoping that lots of people run full nodes. The
problem is that a full node is quite an intensive thing already, it uses
lots of CPU and disk seeks, and will just get more expensive in future. And
as transaction traffic increases, that leaves less CPU time available to
service thousands of connected clients. The ROI of bringing up a new node
decreases at the same time as the userbase increases.
One traditional approach to solving this is frontend proxies. Jabber.com/org
used this technique many years ago, and Google has also used it to scale up the
lockservice<http://static.googleusercontent.com/external_content/untrusted_dlcp/labs.google.com/en/us/papers/chubby-osdi06.pdf>
(see
section 3.1). It's effective because often maintaining connections to
thousands of clients doesn't involve much brainwork, just shifting bytes
around. This is especially true of Bitcoin. So if somebody is running a full
node already they could increase their client capacity by just bringing up a
frontend proxy and having it handle things like outbound tx
broadcasts/deduping inbound broadcasts, connection setup, relaying recently
found blocks etc. A well written proxy could probably support tens of
thousands of simultaneous clients which frees up the bitcoinds time for
verification and wallet manipulation.
[-- Attachment #2: Type: text/html, Size: 3033 bytes --]
next prev parent reply other threads:[~2011-09-06 14:52 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-06 7:42 Steve
2011-09-06 8:29 ` Steve
2011-09-06 8:36 ` Christian Decker
2011-09-06 12:49 ` Mike Hearn
2011-09-06 13:27 ` Steve
2011-09-06 13:31 ` Mike Hearn
2011-09-06 14:17 ` Steve
2011-09-06 14:52 ` Mike Hearn [this message]
2011-09-06 15:25 ` Steve
2011-09-06 14:36 ` Rick Wesson
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='CANEZrP2Wh82sqGjZDn_M=UPufBCU4fP9zEXV_K8JpgVF8O1FCw@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=shadders.del@gmail$(echo .)com \
/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