Advertise with us (we do not endorse any site advertised)

Author Topic: Core Development Update #3  (Read 2092 times)

0 Members and 1 Guest are viewing this topic.

Offline bitcoinforum.comTopic starter

  • Administrator
  • Legendary Member
  • *******
  • Joined: Nov 2011
  • Location:
  • Posts: 1497
  • Country: bz
  • Thanked: 52 times
  • Karma: +40/-1
  • Gender: Male
  • The Bitcoin genie is already out of the bottle.
    • View Profile
    • Core Development Update #3
« on: March 08, 2013, 05:36:20 PM »
Core Development Update #3
(Gavin Andresen Mar 08 2013)

Steady Progress

Looking back on what has happened since my last update, the big news was the 0.8 release. If you are using bitcoind or Bitcoin-Qt and you haven’t upgraded yet, you should: the new release is much faster and is more gentle on your disk drives. You can get it from SourceForge.

Steady progress is also being made on a project that, I’m happy to say, I had very little to do with: redesigning the website. Foundation member Saivann Carignan decided that he didn’t like the current homepage, but instead of doing what most people do (complain about it and ask when somebody else will fix it), he took a leap of faith and redesigned it himself. He has also been doing the hard work of getting rough consensus on what the design and content should be, starting with a very civilized conversation in the Foundation forums.

If you see some piece of common Bitcoin infrastructure that needs to be created or fixed, I hope you’ll feel inspired by Saivann and work to make it happen.

Scaling Up

Looking forward, scaling up to handle increased transaction traffic on the network is very high on the development priority list. Scaling up is painful, but I always remind other developers that scaling up problems are the best kind of problem– they mean people want to use your product.

This week transaction volume reached the voluntary, easy-to-change, 250,000 bytes-per-block limit — and that caused some pain for people. I got a few emails from people concerned that their transactions weren’t confirming after an hour or three, so I sent this email to a dozen or so of the big mining pool operators:

I’m writing to remind you of the bitcoin.conf settings that control the size of blocks created, and the transaction fee policies. I’m not going to recommend any particular settings– I really think we need to move beyond centralized decision making.

blockmaxsize=<n>      Set maximum block size in bytes (default: 250000)
blockprioritysize=<n>  Set maximum size of high-priority/low-fee transactions in bytes (default: 27000)
blockminsize=<n>       Set minimum block size in bytes (default: 0)

Related: I did some back-of-the-envelope, order-of-magnitude calculations on orphan rates and block sizes:

My conclusion is that creating larger blocks with transactions that follow the current default fee rules is the smart thing to do; I estimate you’ll earn more in fees than you will lose in a (very slightly) higher orphan rate.

And if you think that accepting more zero-fee transactions will help Bitcoin long-term, I estimate that 100K of free transactions costs you
 something like $1 for every block found.

At least a couple of the big pools have decided to increase the size of the blocks they create, but I suspect that hitting the “soft” limit will make some services using the block-chain start to increase the fees they pay. People creating lots of small-value transactions are affected most. To them, I’ll just say that scaling problems are good problems to have, and if you think something needs fixing then “I hope you’ll feel inspired by Saivann and will work to make it happen.”

One Megabyte

There is a non-voluntary, hard-to-change, 1,000,000-bytes-of-transactions-per-block limit that needs to be raised.
And there is… uhh, “vigorous”… debate over when and how to change it. There are always debates over changing things; after the huge kerfuffle last year over multisignature transactions I had to step back and take a break when it was all over, I was so burned out from trying to respond to all the fear, uncertainty, and doubt.

I think a consensus on what to do is starting to emerge; I expect by my next development update we’ll have a plan.
The good news is we all learned a lot from that experience, so I’m confident that raising the 1MB limit will be only slightly painful for most people– you’ll just have to upgrade old Bitcoin software (which you should be doing regularly anyway).
"Your keys, your Bitcoin. Not your keys, not your Bitcoin." (Andreas Antonopoulos)
Latest stable Bitcoin version
Latest stable Electrum version Foundation Quarterly Update

Started by

Replies: 0
Views: 2204
Last post January 09, 2013, 10:49:30 PM
by Bitcoin version 0.6.0 released

Started by

Replies: 1
Views: 97111
Last post March 31, 2012, 03:22:06 PM
by dodoking Bitcoin version 0.6.2 released

Started by

Replies: 0
Views: 11949
Last post May 12, 2012, 12:26:22 AM
by Bitcoin version 0.6.3 released

Started by

Replies: 0
Views: 11797
Last post June 26, 2012, 12:07:46 PM
This could be the next version of

Started by

Replies: 2
Views: 2634
Last post March 08, 2013, 05:16:27 AM
by iBits

your ads here