Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ideas for increasing # of full nodes #3334

Closed
gdoteof opened this issue Nov 30, 2013 · 5 comments
Closed

Ideas for increasing # of full nodes #3334

gdoteof opened this issue Nov 30, 2013 · 5 comments

Comments

@gdoteof
Copy link

gdoteof commented Nov 30, 2013

  1. Would increasing block size significantly increase resources other than disk space and network throughput?
  2. Is there some basis other than intuition that the lack of full nodes is primarily a result of resource consumption?
  3. Are the number of full nodes really a potential / real problem?

My intuition, and small sample size study is that people don't choose the QT wallet not because of the resources--now that it is synced, it sits here running virtually unnoticed on my mid-grade laptop with mid-tier broadband--but rather the start up time to use it the first time.

People are lazy and prone to inertia. They want to use bitcoin for their first time; so they use electrum or blockchain.info because it works "right now" and never switch.

Has there been any type of proposal considered turning bitcoin-qt into a sort of hybrid wallet? Something that would allow bitcoin-qt and bitcoind nodes to communicate with each other about balances of certain addresses?

It seems to me this could be done in a very light manner; asking only for balances of the addresses used in transactions since syncing (for wallet importing) and for addresses displayed to the user in the 'Receive' tab (most important).

Perhaps I am underestimating?

I assume the bitcoin-qt doesn't allow spending until the blockchain has been fully synced as a way of discouraging double spends by amateurs. Perhaps there is another reason as well? That is, what would be the downside to letting the "local" bitcoin-qt be more lenient with transaction creation but perfectly strict with "other node" propagation?

I say all this for a couple reasons

  • I would like to see people encouraged away from online wallets.
  • I wonder if the resitance to increasing the blocksize is genuinely based in the reality of the user base.
  • It is super annoying to wait almost a full day, even using the bootstrap.dat torrent to use bitcoin-qt. And I myself have intertia and like to use it.
@darkhosis
Copy link

Obviously you'd want to try to keep the blocksize as small as possible... but I suspect there wouldn't be any "resistance" to increasing it if people payed meaningful fees. 0.0001, or 10 cents, isn't very meaningful to me. Perhaps it is to others.

I was already sending out somewhere in the vicinity of 6-8TB a month just from people downloading the blockchain... I dare say I wouldn't want to contribute to that bloat by allowing all these low fee transactions.

re: Increasing "full nodes". Most full nodes aren't very useful, since they have very limited upstream. Maybe you can convince some people to buy some kimsufis when they're available again. After all, any 'full node' that isn't related to a pool is a charity, I've wasted roughly $500 or so

@super3
Copy link
Contributor

super3 commented Dec 2, 2013

@sipa is already working on "Headers-First, parallel download chain sync". Basically the blockchain will download waaaaay faster when that is done. See: https://bitcoinfoundation.org/blog/?p=290

@laanwj
Copy link
Member

laanwj commented Dec 8, 2013

Another option would be to run another wallet (such as multibit or armory) with SPV mode on top of Bitcoin-Qt in disable-wallet mode. This could be made transparent to the user by shipping a daemon (I think armory already does this) that runs optionally in the background.

This would be pretty straightforward to do, in comparison with hacking the current wallet code.

My personal opinion of the future of the GUI of Bitcoin-Qt is as a GUI for power users and developers. Primarily a full node with a neat RPC console and statistics, and optional (albeit limited compared to other projects) wallet. There are some nice user friendly wallet projects out there and I don't see the point of competing with them for beginning users.

@super3
Copy link
Contributor

super3 commented Dec 9, 2013

Personally I would like a major overhaul for Bitcoin-Qt more focused on the end user. As long as we still have the full blockchain sync for regular use, don't think that will be an option.

At last count there were 200k+ nodes, so I don't we particularly have a problem with not enough nodes. I swear @luke-jr had some node version stats or something(or maybe someone else). Saw it on IRC once. Anyone know what that URL was?

@gavinandresen
Copy link
Contributor

Closing this as "wishing for ponies." Having an issue open about this does not help it get implemented any faster.

@bitcoin bitcoin locked as resolved and limited conversation to collaborators Sep 8, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants