Topic: Core Development Status Report #2 - Discussion (Read 2378 times)

Thanks Mike! +tip 0.1btc

If Bitcoin grows very well and becomes a big/bigger success, then at some point we'll run up against the 1mb block size limit. If that happens, we'll need a hard-fork to switch to a new (probably floating) size limit and that will force the issue.

If Bitcoin never reaches that level of traffic (around 7tps) then all the reasons for a hard fork are pretty much nice-to-haves.

This implies that at least one more fork may be in the cards: https://en.bitcoin.it/wiki/Hardfork_Wishlist

Gotcha thanks. I know you're super busy, but if you (or someone) could entertain a related question, that would be super. My initial impression of the future of Bitcoin was that, over the next decade, there would probably be a few more hard forks (maybe just one more?) that ideally wouldn't split the userbase as one branch would take the vast majority of the userbase. Is my impression far off? Are we basically hoping to never have a hard fork again (which implies, for example, that we think the current blocksize might stand the test of time)?

-Chris

P.S. Apologies if this post shows up twice...

No fork required. The secure payment protocol stuff is all higher-level than the blockchain.

For less-savvy supporters like myself, could you tell us whether these are fork-required upgrades or no-fork-required upgrades? I'm referrring now to the secure payment protocol stuff.

The reference client is not intended to be the dominant client used by regular people...it is intended to show others how to implement the protocol in their own clients.

While there are major improvements needed in the protocol to help make a better general purpose client, this is a separate issue. Things like import /export of private keys is important in non-reference clients...whereas über long downloads are an issue with the protocol (and hence solutions should first be implemented in the reference client).

Bitcoin 0.8 is dramatically faster than 0.7 - so why not grab a testing build and help us get it out to users? And there are even bigger speed improvements to come.

The clients page is a lot better than the first versions that were proposed (that were just giant feature matrices!) but it's still not clear enough. I agree that we aren't directing users to something that works well, with clarity. The reason is as I mentioned on other threads - there are no clients that work well right now. Sad but just a fact.

The core Satoshi client has poor performance. SPV clients based on bitcoinj still lack some key features, though they are much faster than the regular client (and will get faster still once Matt finishes the bloom filtering work). Web based wallets like blockchain are probably the best user experience right now though their safety does depend a lot on you installing a verifier extension. The nice thing about the blockchain wallet is integrated purchasing of Bitcoins for fiat.

Gavin is working on the right things, IMHO - grungy, unsexy infrastructure that nobody else is doing. The fast Android and MultiBit clients are basically blocked on me at the moment, though Jim and Matt are doing some important work too. Having Gavin contribute could help a bit, but at the same time, all the things being worked on are necessary so it's just shuffling stuff around at some level.

I believe you have to fork this on github and prepare for long discussions on the development mailing list.

That would be great but also the client page could use some work because too many choices can likewise paralyze someone from downloading anything.. If you'd like I can come up with a few suggestions for how the clients page could be improved.

Exactly.

My priorities are:

+ Network Security
+ Network Scalability
+ Network Stability

After those Big Three:

+ Wallet Security

Usability of the reference implementation is not on my priority list. I believe the vast majority of users will (if they aren't already) use bitcoin via a web-based service or an app on their mobile phone.

RE: the bitcoin.org homepage:  I think replacing the links to Bitcoin-Qt on the hompage with just a link to the clients page is a good idea. Somebody should get the consensus to do that and submit a pull request.

It's nice to have decentralized node and wallet software that people use and keep the network going, but there are hard limits on how big blocks can get and those hard limits are such that even the non-ultraprune client will work fine on relatively modest hardware. I've still got a full node running 0.7.2 (pre-ultraprune) just fine on a Amazon EC2 Micro instance with just 600MiB of ram. Right now it's using just 230MiB of ram and the load average is 0.05, trivial.

Since satoshidice was introduced blockchain growth has been a very consistent and linear rate of 4GiB/year, or a bit more than 10x less than the hard maximum of 55GiB/year. I suspect what we're seeing is fees are crowding out the worthless transactions. In any case, running a full-node will be easy even without pruning for at least a few more years now, and with ultraprune and the leveldb enhancements planned to go into 0.8 syncing the first time is now limited by bandwith, not CPU, so with a decent connection it just takes a few hours.

Yes, with a heck of a lot of resources you might be able to pull off a DoS attack on the current thousands of full-nodes simultaneously. But the second you do that you'll find people switching to tor and other ways of getting the block chain data out, and for that matter, find out how many nodes you don't know about are already running on tor. Mining pools already have lots of experience dealing with DoS attacks, and those attacks haven't done any damage to Bitcoin as a whole. It's really, really hard to attack a flood-fill network that just needs few dozen KiB/s to operate.

On the other hand if we don't solve the secure payment problem we will see a lot of malware targetting bitcoin payments, and those hackers will cause much more damage to the average guy just trying to send a payment than having slightly less decentralization ever will. Similarly the fact that P2SH and Gavin's dream of robust multi-device-authorization wallets isn't ever implemented anywhere will again cause far more problems.

When you get down to it news reports saying "hackers try to DoS attack Bitcoin network, Bitcoin running a bit slow, counter-measures are being deployed, no coins lost" are far less damaging to credibility than "thousands lose their Bitcoins due to new sophisticated malware attack"

online wallets are very vulnerable to admin abuse (see blockchain.info scandal), not to mention the fact they completely kill anonymity.

What's the problem with alternative clients, or online wallets ? Is it only a matter of bitcoin.org redirection ?
I think the Qt version does it's job for more experienced users, no need to rush to compete with lite clients.

I agree that Bitcoin-Qt development is fairly important. Not only because many people have bad first experiences with Bitcoin thanks to it but the fact that we're going around that is not an entirely good thing either. Bitcoin-Qt is already losing a lot of users relative to other wallets. Webwallets such as the Blockchain wallet are getting a larger share of new users.

This is fine until the amount of full nodes gets small enough to make an attack on the network plausible. I'm eagerly waiting for 0.8 since I still run a full node occasionally and plan on doing so in the future as well. I know many others who want to support the network as well, but currently it's a pain in the ass!

The advancements in 0.8 will only be a temporary pain reliever, lots of work to be done for 1.0.

Today Gavin released a Core Development Status Report #2:

https://bitcoinfoundation.org/blog/?p=85


Continue at the link above.


While I'm happy that things are moving along I am personally very disappointed that he is saying he intends to spend a lot of time on something that other services as layers on top of Bitcoin like bitpay or paysius can easily solve instead of solving the number one issue that the majority of new people to Bitcoin have to deal with: the reference client.

bitcoin.org still primarily directs them to the full node reference client which means that even though this will get quite a bit better with 0.8.0 it's still a huge pain, especially for the mainstream "I want to use it right now!" userbase that I'm pretty sure we'd all like to see adopt Bitcoin ASAP. Not to mention it still has serious holes in wallet security that malware can easily abuse.

Gavin, do you not know it's better to focus and do one thing and do it great instead of spreading out your attention on many things and doing them marginally?


Unfortunately he isn't regulated by consumption i.e. his work does not depend on profit/loss incentives so I doubt he'll change his mind about his priorities. I strongly think I'm right about this issue and I just hope someone else will come a long willing to develop the reference client to do just one thing and do that spectacularly so it can start appealing to the masses.