-
Notifications
You must be signed in to change notification settings - Fork 35.7k
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
Comments
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 |
@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 |
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. |
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? |
Closing this as "wishing for ponies." Having an issue open about this does not help it get implemented any faster. |
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
The text was updated successfully, but these errors were encountered: