Core Development Status Report #2 - Discussion

[hazek]

Today Gavin released a Core Development Status Report #2:

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

Core Development Status Report #2

Gavin Andresen    Dec 21 2012

Since my last status update the core development team has continued to make steady progress. We have no spectacular new world-changing features to announce, but that should be expected– in my experience, the best way to be successful is to try to make steady progress towards your goals every day. But expect that reaching your goals almost always takes longer than you expect, because you always run into unexpected setbacks and detours.

It was a pretty good month for making steady progress on the reference code; the only setback was a little time taken to roll out a 0.7.2 minor bug-fix release (release notes and binary downloads at SourceForge).
..
..
..

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.

[1714999047]

1714999047

[1714999047]

1714999047

[1714999047]

1714999047

[1714999047]

1714999047

[Technomage]

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.

[gusti]

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.

[grue]

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.

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

[Peter Todd]

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"

[Gavin Andresen]

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"

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.

[hazek]

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.

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.

[phatsphere]

If you'd like I can come up with a few suggestions for how the clients page could be improved.

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

[Mike Hearn]

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.

[bg002h]

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).

[chriswilmer]

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"

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.

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.

[Gavin Andresen]

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.

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

[chriswilmer]

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.

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

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...

[notme]

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.

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

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...

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

[Mike Hearn]

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.

[chriswilmer]

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.

Thanks Mike! +tip 0.1btc