📅 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.
theymos [ARCHIVE] /
npub10v…mper0
2023-06-07 02:51:07
in reply to nevent1q…ckxt
Author Public Key
npub10vt6y7m6shn8hfuj83zjlwcga4fky38kv73qz6xlcvtj4q7fjt0sqmper0Seen on
wss://relay.nostr.bandPublished at
2023-06-07 02:51:07Event JSON
{
"id": "cbec97248124782976c199588250d5a884836a3b1ae6c256108bcc58165a02e2",
"pubkey": "7b17a27b7a85e67ba7923c452fbb08ed536244f667a20168dfc3172a83c992df",
"created_at": 1686106267,
"kind": 1,
"tags": [
[
"e",
"4af0205fae641367dcfd78e02a7a0b6f75f880a1f702affe5d70f7b792eb8207",
"",
"root"
],
[
"e",
"461f09b68b3813fd42f45ff45736539df96333c0dad637239c394d6c677ffecd",
"",
"reply"
],
[
"p",
"857f2f78dc1639e711f5ea703a9fc978e22ebd279abdea1861b7daa833512ee4"
]
],
"content": "📅 Original date posted:2011-12-17\n🗒️ 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.\n📝 Original message:On Sat, Dec 17, 2011, at 02:06 PM, Gavin Andresen wrote:\n\u003e Although I do also wonder if we'll ever run into a problem with full\n\u003e nodes refusing to answer requests from lightweight nodes (there might\n\u003e be a tragedy-of-the-commons problem lurking there).\n\nThis seems likely. Also, even if many full nodes are willing to donate\nresources, there may simply be too few full nodes to handle the load.\n\nMy preferred solution for handling scalability in the future is to\nhave lightweight clients download only headers and Merkle trees (which\nare both small and easy to distribute), and then require senders to\ncontact recipients directly in order to transmit their transactions.\nThen lightweight clients never need full blocks to build their\nbalances, and full nodes don't have to handle expensive queries from\nlightweight clients.\n\nUnder this scheme, the current broadcast system could be used among full\nnodes for a long time. Since clients wouldn't ever need to talk to full\nnodes, they could form a separate network with less reliable\nbroadcasting and perhaps a fancier network architecture. Members of the\nfull network would connect to the most reliable members of the client\nnetwork in order to broadcast headers and Merkle trees and receive\ntransactions. Full nodes would *not* answer any client queries, so\ndealing with the client network would not require many resources, and\nminers would probably have an incentive to do it. (Creating a \"separate\"\nnetwork like this can be done by using the services field.)\n\nI don't think requiring senders to email some data to the recipient\nwould be too burdensome, though it's probably also possible to design a\nsystem where even offline recipients can receive transactions through\nthe Bitcoin network.",
"sig": "73fe0172f2c49307197b8edb03e1dcb772ba2586d964f31d80db9fc5f0fe8c92e96eddc6289adb08ee335e459e127f10089a0d5a39f260b85a95d9d7282e9aa6"
}