Source
r/Bitcoin•
harda

Bitcoin Core 0.10.1 Released

Bitcoin Core version 0.10.1 is now available from:

https://bitcoin.org/bin/bitcoin-core-0.10.1/

This is a new minor version release, bringing bug fixes and translation updates. If you are using 0.10.0, it is recommended to upgrade to this version.

Please report bugs using the issue tracker at github:

https://github.com/bitcoin/bitcoin/issues

Upgrading and downgrading

How to Upgrade

If you are running an older version, shut it down. Wait until it has completely shut down (which might take a few minutes for older versions), then run the installer (on Windows) or just copy over /Applications/Bitcoin-Qt (on Mac) or bitcoind/bitcoin-qt (on Linux).

Downgrade warning

Because release 0.10.0 and later makes use of headers-first synchronization and parallel block download (see further), the block files and databases are not backwards-compatible with pre-0.10 versions of Bitcoin Core or other software:

  • Blocks will be stored on disk out of order (in the order they are received, really), which makes it incompatible with some tools or other programs. Reindexing using earlier versions will also not work anymore as a result of this.

  • The block index database will now hold headers for which no block is stored on disk, which earlier versions won't support.

If you want to be able to downgrade smoothly, make a backup of your entire data directory. Without this your node will need start syncing (or importing from bootstrap.dat) anew afterwards. It is possible that the data from a completely synchronised 0.10 node may be usable in older versions as-is, but this is not supported and may break as soon as the older version attempts to reindex.

This does not affect wallet forward or backward compatibility.

Notable changes

This is a minor release and hence there are no notable changes. For the notable changes in 0.10, refer to the release notes for the 0.10.0 release at https://github.com/bitcoin/bitcoin/blob/v0.10.0/doc/release-notes.md

0.10.1 Change log

Detailed release notes follow. This overview includes changes that affect external behavior, not code moves, refactors or string updates.

RPC:

  • 7f502be fix crash: createmultisig and addmultisigaddress
  • eae305f Fix missing lock in submitblock

Block (database) and transaction handling:

  • 1d2cdd2 Fix InvalidateBlock to add chainActive.Tip to setBlockIndexCandidates
  • c91c660 fix InvalidateBlock to repopulate setBlockIndexCandidates
  • 002c8a2 fix possible block db breakage during re-index
  • a1f425b Add (optional) consistency check for the block chain data structures
  • 1c62e84 Keep mempool consistent during block-reorgs
  • 57d1f46 Fix CheckBlockIndex for reindex
  • bac6fca Set nSequenceId when a block is fully linked

P2P protocol and network code:

  • 78f64ef don't trickle for whitelisted nodes
  • ca301bf Reduce fingerprinting through timestamps in 'addr' messages.
  • 200f293 Ignore getaddr messages on Outbound connections.
  • d5d8998 Limit message sizes before transfer
  • aeb9279 Better fingerprinting protection for non-main-chain getdatas.
  • cf0218f Make addrman's bucket placement deterministic (countermeasure 1 against eclipse attacks, see http://cs-people.bu.edu/heilman/eclipse/)
  • 0c6f334 Always use a 50% chance to choose between tried and new entries (countermeasure 2 against eclipse attacks)
  • 214154e Do not bias outgoing connections towards fresh addresses (countermeasure 2 against eclipse attacks)
  • aa587d4 Scale up addrman (countermeasure 6 against eclipse attacks)
  • 139cd81 Cap nAttempts penalty at 8 and switch to pow instead of a division loop

Validation:

  • d148f62 Acquire CCheckQueue's lock to avoid race condition

Build system:

  • 8752b5c 0.10 fix for crashes on OSX 10.6

Wallet:

  • N/A

GUI:

  • 2c08406 some mac specifiy cleanup (memory handling, unnecessary code)
  • 81145a6 fix OSX dock icon window reopening
  • 786cf72 fix a issue where "command line options"-action overwrite "Preference"-action (on OSX)

Tests:

  • 1117378 add RPC test for InvalidateBlock

Miscellaneous:

  • c9e022b Initialization: set Boost path locale in main thread
  • 23126a0 Sanitize command strings before logging them.
  • 323de27 Initialization: setup environment before starting QT tests
  • 7494e09 Initialization: setup environment before starting tests
  • df45564 Initialization: set fallback locale as environment variable

Credits

Thanks to everyone who contributed to this release:

  • Alex Morcos
  • Cory Fields
  • dexX7
  • fsb4000
  • Gavin Andresen
  • Gregory Maxwell
  • Ivan Pustogarov
  • Jonas Nick
  • Jonas Schnelli
  • Matt Corallo
  • mrbandrews
  • Pieter Wuille
  • Ruben de Vries
  • Suhas Daftuar
  • Wladimir J. van der Laan

As well as everyone that helped translating on Transifex.

Posted Apr 27, 2015, 8:35 AM UTC

39261
hardaOP•

Other useful links:

  • Magnet link for anyone in a country (like Russia) that blocks Bitcoin.org:

      magnet:?xt=urn:btih:b6f8da60aaf2007cd6db631637951ae673e31044&dn=bitcoin-core-0.10.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.publicbt.com%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.ccc.de%3A80%2Fannounce&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Fopen.demonii.com%3A1337&ws=https%3A%2F%2Fbitcoin.org%2Fbin%2F

  • How to run a full node guide

  • Gitian build signatures are here with signatures (so far) from Wladimir van der Laan, Pieter Wuille, Luke Dashjr, Cory Fields, Jonas Schnelli, and several others. If you trust these people, this provides assurance that the binaries you download (and verify) match the code they have in their personal Bitcoin git repositories.

34
ABC_AlwaysBeCoding•

nice! Gonna help host that magnet just to get it out there

2
nicklerj•

I wrote a blog post explaining the issue behind

ca301bf Reduce fingerprinting through timestamps in 'addr' messages.

https://jonasnick.github.io/blog/2015/03/06/guessing-bitcoins-p2p-connections/

17
Jahus•

Question. Why is Bitcoin core still at version [major] 0?

12
gavinandresenGavin Andresen - Bitcoin Expert•

Because the p2p networking code isn't robust enough to call it "1.0" (it is an accreted set of hacks to mitigate DoS/Sybil attacks; it should keep track of resources used by each peer, and prioritize work so no peer can overwhelm CPU or bandwidth or disk usage).

And because the wallet code needs work to match best practices (use keys derived from a master seed, do NOT rely on BerkeleyDB).

60
TronicTonic•

Sounds like you know a thing or two about it.

14
dumptrucks•

Nah, clearly a bitcoin rookie.

8
Anen-o-me•

So the netcode has its own ledger to track and foil bad actors? Interesting.

2
hardaOP•

That's the preference of several of the Bitcoin Core developers. I'd guess it's because they set a very high bar for themselves.

7
[deleted]•

[deleted]

1
shemnon•

As true computer scientists they start counting from zero. Once there is a backwards incomparable change across the network (i.e. basically never) then expect a major version bump.

That or a marketing need to say "new and interesting!" in which case expect it to be "BitCoin Core 2018," "BitCoin NG," or "BitCoin for WorkGroups." And yes, the word BitCoin would be camel-cased by the marketing people because it will make it look more important. More capitals means more capital!

5
ABC_AlwaysBeCoding•

Once you hit 1.0 in software, you're expected to practically freeze your API. They might not be ready for that level of concretion yet.

4
hardaOP•

The RPC API and the P2P protocol are quite stable, although certainly not frozen. That is, they mostly add new features and rarely remove or change existing features.

Source: I write much of the documentation on Bitcoin.org, so every time the Bitcoin Core developers change something, I have to stop being lazy and document it. :-)

3
ABC_AlwaysBeCoding•

Do you think there'll ever be a refactor or rewrite, using the lessons they've learned so far? (Is it too dangerous at this point? sigh)

1
hardaOP•

I'm pretty sure they'd like to throw out the RPC-JSON interface and start over from scratch with something different (probably not JSON). However, pretty much every programmer dreams of throwing out their old, complicated system with something new and simple---so I don't know how much they intend to actually do.

I don't think they're going to mess much with the P2P system. I think they're hoping to develop a new system that will operate in parallel with the old system before they even think about replacing the old system. (Sort of like BlueMatt's current block relay network, but more advanced.)

Note: these are just weak guesses from my occasional monitoring of #bitcoin-dev. I could be totally off base.

2
PoliticalDissidents•

Because Bitcoin is still beta software.

2
cap2002•

You guys are the best!

1 beer u/changetip

10
changetip•

The Bitcoin tip for 1 beer (15,876 bits/$3.50) has been collected by harda.

--

^^what ^^is ^^ChangeTip?

3
MrBeardyMan•

1 beer (15,876 bits/$3.50)

$3.50 for one beer? damn I get fed up with London prices ...

1
Hannott•

You mean that's expensive? Try 15$ here in Norway

3
IronVape•

OK, This time I really mean it. I'll never drink (in Norway) again.

1
BeefSupreme2•

Thanks to all.

While I worry about my baby's future and make plans, you all are changing its diapers and feeding the little sucker.

10
itisike•

r/nocontext

1
TotesMessenger•

This thread has been linked to from another place on reddit.

^(If you follow any of the above links, respect the rules of reddit and don't vote.) ^(Info ^/ ^Contact)

1
drupalnomad•

Someone update the sidebar.

9
StarMagedMOD•

The moderation team here needs to verify the integrity of the new build via Gitian before that happens. This is an additional line of defense on top of the verifications performed by the bitcoin.org maintainers, just in case that team is compromised.

With real money on the line, you can never be too careful.

2
hardaOP•

I applaud your effort to verify the binaries, but I don't think this adds any real security since anyone with access to the server can change the binaries at any time after you verify them. (Not that anyone with legitimate server access would do that.)

The important step is the one that is listed in the sidebar: verify the integrity of the release -- but that is a step each user must perform for themselves.

3
TotesMessenger•

This thread has been linked to from another place on reddit.

  • [/r/bitcointechnology] [Bitcoin Core 0.10.1 released [x-post from r/bitcoin]](//np.reddit.com/r/BitcoinTechnology/comments/340et5/bitcoin_core_0101_released_xpost_from_rbitcoin/)

^(If you follow any of the above links, respect the rules of reddit and don't vote.) ^(Info ^/ ^Contact)

7
MagicalBux•

Quick question: will https://launchpad.net/~bitcoin/+archive/ubuntu/bitcoin get updated?

I notice it's lagging behind a bit: besides the (understandable) lack of 10.1, there was not even a package of Bitcoin 10.0 for the latest Ubuntu (15.04)

7
statoshi•

That's up to core dev Matt Corallo; he maintains the PPA. You can bug him at [email protected]

9
rodeopenguin•

I wish I could understand all this gibber jabber.

5
slowmoon•

So it goes to 1.0.0 after 0.9.9? Or do we go to 0.9.9.0? I don't know how software version go.

4
TheAwer•

It's not like normal numbers - it is just as likely to go from 0.5.0 to 1.0.0 as from 0.9.0 to 0.10.0 or even from 0.12345678.0 to 0.12345679.0. Just get the normal decimal system out of your head - this has to do with how big and important updates.

6
hardaOP•

Open source software in particular has a weird tradition of going from 0.9 to 0.10. Everyone thinks it's weird, and people actually have to write special code for package managers to handle it (e.g. dictionary sort not numerical sort), but it's what you do when you have a major upgrade to 0.9 that isn't quite ready to be 1.0. Sorry for any confusion.

5
jesset77•

Just think of the period like it's more of a comma than a decimal point.

Instead of "one's place, decimal point, tenths, (another decimal point?) hundredths"

What you are really looking at is:

An integer, that might be more than one digit. Period. Another integer, that might be more than one digit (repeat 1 or two more times).

2
ryno55•

The typical standard for 'semantic versioning' goes:

[major version number - major leaps, incompatibilities]
.[feature version number - new features, small incompatiblities]
.[minor version number - bug fixes, backwards compatible]
4
TypoNinja•

Also it's worth to note that until version 1.0 of a software is released there are no promises of backwards compatibility. In other words backwards-incompatible changes could be introduced before 1.0 without having to increase the major version number.

1
[deleted]•

[deleted]

0
natmccoy•

Stupid question but...I've been using multibit, it syncs much faster but I've been experiencing some minor issues with it. Can I download this to use for primary storage while continuing to use multibit for fast transactions without interference between the two? With altcoins I've experienced interference issues when downloading wallet updates without deleting the old files.

3
hardaOP•

Yes, you absolutely can use Multibit. If you use the beta Multibit HD and run it on the same computer as Bitcoin Core, Multibit will do all of its communication with your local Bitcoin Core, so you get the security and privacy benefits of Bitcoin Core along with whatever features you like from Multibit.

Do note that Bitcoin Core 0.10.1 requires downloading and storing (for now) about 40GB of data, so it's not an almost-instantly-usable option like Multibit.

5
FreshGrindsCoffee•

thanks for the update

3
boristheboris•

Thanks for the update

2
JuliusCaesar108•

Syncing now for the first time. Hope my old mid 2009 MacBook Pro with upgraded computer parts can contribute to the Bitcoin experience.

2
hardaOP•

Awesome! I'm sure your MacBook Pro will do fine---I'm on a 2005 Lenovo PC laptop (using Linux) and it took me about 4 hours to sync and about 2 minutes to catch up every morning when I turn it back on. Otherwise, Bitcoin Core doesn't get in the way at all.

1
Onetallnerd•

Do you have some sort of QoS so it doesn't eat all your bandwidth?

1
hardaOP•

No; it doesn't use that much bandwidth (think one 1 MB block every 10 minutes download plus a modest amount of relay).

My node has been for 9 hours now and here's what the getnettotals RPC says:

{
    "totalbytesrecv" : 73593572,
    "totalbytessent" : 419854478,
    "timemillis" : 1430160558925
}

In human-readable numbers, that's 73MB downloaded and 419MB uploaded. Divided by 9 hours, that's about 8MB/hour download and 46MB/hour uploaded. My connection is much faster than that, so I don't notice it at all.

1
litecoin-p2pool•

For reference, the master commit includes a linux script for QoS for those that want to control (outgoing) peer bandwidth:

https://github.com/bitcoin/bitcoin/blob/master/contrib/qos/tc.sh

1
itisike•

So pruning will wait till the next version?

2
hardaOP•

Yes. Pruning is currently available in the unreleased Bitcoin Core master branch and is strongly expected to be included in the 0.11 release scheduled for July. (Note: security software like Bitcoin Core only uses schedules for planning; obviously, you don't release until it's been well tested.)

3
[deleted]•

[deleted]

1
[deleted]•

[deleted]

1
[deleted]•

[deleted]

1
[deleted]•

[deleted]

1
lambecolin•

Where is Gavin now? Move to MIT/

1