theymos [ARCHIVE] on Nostr: 📅 Original date posted:2011-12-17 🗒️ Summary of this message: The scalability ...
📅 Original date posted:2011-12-17
🗒️ Summary of this message: The scalability issue in Bitcoin can be solved by having lightweight clients download only headers and Merkle trees, and requiring senders to contact recipients directly to transmit transactions. Full nodes would not answer any client queries, and a separate network could be formed for clients.
📝 Original message: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.
🗒️ Summary of this message: The scalability issue in Bitcoin can be solved by having lightweight clients download only headers and Merkle trees, and requiring senders to contact recipients directly to transmit transactions. Full nodes would not answer any client queries, and a separate network could be formed for clients.
📝 Original message: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.