From: "theymos" <theymos@mm•st>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Protocol extensions
Date: Sat, 17 Dec 2011 15:49:18 -0600 [thread overview]
Message-ID: <1324158558.26106.140661012932641@webmail.messagingengine.com> (raw)
In-Reply-To: <CABsx9T06-GA5+KNdr_XzP_M4Av8nEsnMXL29tk078wooZg=RZw@mail.gmail.com>
On Sat, Dec 17, 2011, at 02:06 PM, Gavin Andresen wrote:
> Although I do also wonder if we'll ever run into a problem with full
> nodes refusing to answer requests from lightweight nodes (there might
> be a tragedy-of-the-commons problem lurking there).
This seems likely. Also, even if many full nodes are willing to donate
resources, there may simply be too few full nodes to handle the load.
My preferred solution for handling scalability in the future is to
have lightweight clients download only headers and Merkle trees (which
are both small and easy to distribute), and then require senders to
contact recipients directly in order to transmit their transactions.
Then lightweight clients never need full blocks to build their
balances, and full nodes don't have to handle expensive queries from
lightweight clients.
Under this scheme, the current broadcast system could be used among full
nodes for a long time. Since clients wouldn't ever need to talk to full
nodes, they could form a separate network with less reliable
broadcasting and perhaps a fancier network architecture. Members of the
full network would connect to the most reliable members of the client
network in order to broadcast headers and Merkle trees and receive
transactions. Full nodes would *not* answer any client queries, so
dealing with the client network would not require many resources, and
miners would probably have an incentive to do it. (Creating a "separate"
network like this can be done by using the services field.)
I don't think requiring senders to email some data to the recipient
would be too burdensome, though it's probably also possible to design a
system where even offline recipients can receive transactions through
the Bitcoin network.
next prev parent reply other threads:[~2011-12-17 21:49 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-17 7:41 Eric Lombrozo
2011-12-17 13:13 ` Michael Grønager
2011-12-17 13:37 ` Christian Decker
[not found] ` <CABsx9T0puk3CWH1cfNHMSVEoCPaLJJWNJ+H5ObCERZrzMbrTyA@mail.gmail.com>
2011-12-17 19:06 ` Gavin Andresen
2011-12-17 21:49 ` theymos [this message]
2011-12-18 0:44 ` Jordan Mack
2011-12-18 1:07 ` Jeff Garzik
2011-12-18 1:27 ` Jordan Mack
2011-12-18 14:16 ` Andy Parkins
2011-12-18 17:09 ` theymos
2011-12-18 18:06 ` Alan Reiner
2011-12-18 18:47 ` Amir Taaki
2011-12-18 19:37 ` Jorge Timón
2011-12-17 19:28 ` Gregory Maxwell
2011-12-17 20:34 ` Christian Decker
2011-12-18 21:19 ` Stefan Thomas
2011-12-19 21:43 ` Jordan Mack
2011-12-20 9:10 ` Wladimir
2011-12-20 10:44 ` Nicolas Fischer
2011-12-21 0:47 ` Kyle Henderson
2011-12-21 8:50 ` Michael Grønager
2011-12-21 11:42 ` Eric Lombrozo
2011-12-21 12:41 ` Michael Grønager
2011-12-21 16:10 ` Christian Decker
2011-12-22 9:18 ` Michael Grønager
2011-12-22 10:12 ` Andy Parkins
2011-12-22 10:27 ` Michael Grønager
2011-12-22 11:52 ` Andy Parkins
2011-12-22 12:14 ` Joel Joonatan Kaartinen
2011-12-22 12:26 ` Christian Decker
2011-12-22 12:42 ` Michael Grønager
2011-12-22 14:46 ` Andy Parkins
2011-12-25 2:55 ` Zell Faze
2011-12-21 17:17 ` Jordan Mack
2011-12-22 9:19 ` Michael Grønager
2011-12-21 6:19 Eric Lombrozo
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=1324158558.26106.140661012932641@webmail.messagingengine.com \
--to=theymos@mm$(echo .)st \
--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