Archive: March 6, 2016

<<< March 5, 2016

Home

March 7, 2016 >>>


Iditarod 2016

Sunday,  03/06/16  08:03 PM


For you #Iditarod fans out there, here's an index of all my 2016 Iditarod posts:

03/05/16 08:08 PM -

Iditarod: the ceremonial start

03/07/16 07:55 AM -

Iditarod: day one! ... and they're off

03/08/16 09:34 AM -

Iditarod: day 2 ... up the Alaska Range

03/09/16 08:11 AM -

Iditarod: through the heart of Alaska, taking 24s...

03/09/16 11:01 AM -

the Iditarod race flow tracker!

03/10/16 08:30 AM -

Iditarod: the 24s are over, let the racing begin!

03/11/16 09:15 AM -

Iditarod: to the Yukon, and beyond!

03/12/16 09:05 AM -

Iditarod: Brent Sass in the lead, crazed attack on Jeff King and Aliy Zirkle

03/13/16 11:39 AM -

Iditarod: Leaders reach Norton Sound, Seaveys one two

03/14/16 09:10 AM -

Iditarod: In the Nome stretch, Seaveys vs Sass

03/14/16 07:15 PM -

Iditarod: Seaveys and Sass, sprint to the finish

03/20/16 09:45 PM -

Iditarod wrap: Seaveys one two again, Sass 20th after 26 hour delay, DeeDee 44th!

Onward!


 

Bitcoin classic

Sunday,  03/06/16  08:30 PM

Have you been following the recent doings with Bitcoin?  It's pretty interesting. 

There's a technical challenge in the network architecture brought on by Bitcoin's maximum blocksize of 1MB.  Bitcoin is designed such that a new block is created every ten minutes.  This means the network can only process about seven transactions per second.  That's a lot, but it's not enough.  There have been various proposals for solutions, but one of the simplest is to simply double the blocksize to 2MB.  This doesn't solve the problem forever, but it neatly kicks the can down the road for a while, until the blocksize can be doubled again to 4MB or another solution is implemented.

The small group of developers who maintain Bitcoin ("the core team") have opposed this simple solution, on the grounds that it doesn't solve the problem permanently.  While they debate, the network has become steadily busier, to the point where the second-transactions-per-second limit has been reached several times.  So a few developers split from the core team and created a hard fork, a version of Bitcoin which implements 2MB, and does it in a backward-compatible fashion.  They've called their version Bitcoin classic.

The logic of Classic is to continue processing 1MB blocks until the number of nodes in the network which can support 2MB blocks reaches 75% of all nodes.  At that point, the network seamlessly switches to using 2MB nodes.  Any nodes running older code can continue to process transactions, but they can no longer mine new blocks; all blocks will be 2MB from that point on.

This seems like a pretty good solution, and in just a few months about 20% of the Bitcoin network now has nodes running Classic.  We'll see if and when the 75% threshold is reached, and/or if another solution comes forth and is adopted.  The beauty and inherent strength of Bitcoin is that nobody and no group can decide this on their own; there has to be a consensus for any change to take effect.

There are currently a little over 6,000 nodes in the network, spread all over the world.  Some of them are individual servers, like mine, others are huge arrays of powerful machines with dedicated hardware which do the vast majority of the mining.  (Many of them are in China.)  Below is a map of the Bitcoin network (note top "user agents" at the upper right):

I have of course converted my server to run the Classic code; my version is called Waterhouse [of course]:

It will be most interesting to watch this play out.  Pass the popcorn!

 

 
 

Return to the archive.