Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-18 Thread Wladimir J. van der Laan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


 This kind of thing always happens as projects become larger and more
 diverse.  Something that was once a small group turns into a big
 group of diverse stakeholders.  When it gets too big for the
 informal processes then some people get upset and defensive. Happens
 all the time but it is not really a good excuse to keep doing things
 in an inefficient manner.  The old ways just don't scale and if you
 ever worked on massive projects then you know these formal processes
 work better.

So then: make a proposal for a better process, post it to this list.

In practice there has been zero interest in improving the BIP process.

E.g. the BIP process was adapted from the Python Enhancement Proposals by Amir 
Taaki (in 2009 or so?). It hasn't really changed since then, apart from some 
spelling and grammar corrections. It is not specifically adapted to Bitcoin, 
and doesn't make a distinction between for example, consensus changes and 
non-consensus changes.

So that's up to someone to do. You seem to be enthousiastic about it, so go 
ahead.

Wladimir
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBCgAGBQJVgufFAAoJEHSBCwEjRsmmAmYIAI9ndrMoqEuoaP5t+7W42UuH
sh5qR7hojCCoZZl1N+rQ63UXcPBO/V4NUkUG97S3qpEFDzuoYSbOX2Eh+TRfK+s+
U+BpLhWteSexJ3N9aiFuR0q5jgesAzLZ9wtq1gCPI/Zu5/fgYBP4AVTiQGdXCZtv
m6ZDKCf+aB/fW/59/AiY44NkMDjVQieEVRiT1IPFJULWesOOdtv7UoqIpz0vDa/5
Jplm41j8IpTPioJKSwUi5qzSDrF7O39PC9LMXNRx/0FIuYfwqJpvF0Frc+vtPpjQ
llKE7945uMXz3FLSV0Orx26XPal/MuF5AYOPNk6pJfwYw7q91AUvQxVFepBa9vw=
=dMO9
-END PGP SIGNATURE-

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-18 Thread Wladimir J. van der Laan
On Thu, Jun 18, 2015 at 06:05:58PM +0200, Mike Hearn wrote:

 Once a draft BIP has been submitted to bitcoin-development for
 consideration, the Bitcoin Core maintainer will deliver a preliminary
 yes/no verdict within three weeks. This verdict may be informed by the
 debate that has taken part in the previous three weeks. If more time is
 required, the maintainer is required to request an extension from the BIP
 author, who may then elect to force an immediate decision (risking a no),
 or choosing to allow more time.

Again, for the last time: Bitcoin Core maintainer does not decide about 
protocol or consensus level changes.

This is not a role for me. Find someone else, if you think you need an arbiter. 
There was an idea about a Bitcoin Standards Body once, but as far as I know 
that's not actively being worked on.

BTW: for more exposure a proposal is better posted as a new thread, not as a 
deep reply to an existing topic.

Wladimir


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Is SourceForge still trustworthy enough to host this list?

2015-06-11 Thread Wladimir J. van der Laan
On Wed, Jun 10, 2015 at 09:36:23PM +0300, s7r wrote:
 The mail list is public, so it's not like the data on it is somehow
 sensitive. Sourcefoge is fine, it has a nice web UI where you can browse
 the message and sort/order them as you want, etc.
 
 Why would you want to move to a paid solution? And why would you want
 users to have to pay per message? This is the worst idea ever from my
 point of view. We want to encourage people to join the community, run
 full nodes, ask questions, come with solutions, ideas for improvements
 and so on. Everyone should read and write and contribute as much as
 possible with ideas in debates. You never know who can have bright ideas
 in some contexts.
 
 Bottom line is so far sourceforge handles the mail lists just fine. I
 don't see a single advantage another mail list provider / system could
 offer, except some headache and extra work for migration. The software
 distribution via sourcefoge was cancelled for obvious reasons which I
 fully understand and agree to, but it has nothing to do with the mail
 lists. We have way more important things to brainstorm about.

I completely agree here. I'm not against migration if a much better option 
comes along, but e.g. paying for another provider sounds like nonsense when 
sourceforge does this for free (with some minor annoyances - other providers 
will have their own).

Paying per message is far-fetched, something that could work in economic theory 
with perfectly spherical people in their perfectly efficient market. In 
practice the likely result would be a mailing list only used for advertisement 
and promotion, and technical discussion and release announcements would 
disappear.

BTW for people that *don't* like sourceforge's web archive UI there are some 
other options via gmane:

http://dir.gmane.org/gmane.comp.bitcoin.devel

Wladimir

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Is SourceForge still trustworthy enough to host this list?

2015-06-10 Thread Wladimir J. van der Laan
On Wed, Jun 10, 2015 at 10:25:12AM +0200, xor wrote:
 http://www.howtogeek.com/218764/warning-don%E2%80%99t-download-software-from-sourceforge-if-you-can-help-it/

All our downloads (even old ones) have recently been deleted from sourceforge, 
for this reason. They haven't been mentioned in Bitcon Core release 
announcements for a long time.

No opinion on the mailing list. Though I think it's less urgent. The issue of 
moving the mailinglist has come up before a few times and people can't agree 
where to move to.

Wladimir


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions

2015-06-06 Thread Wladimir J. van der Laan
On Fri, Jun 05, 2015 at 09:46:17PM -0700, Mark Friedenbach wrote:
 Rusty, this doesn't play well with SIGHASH_SINGLE which is used in
 assurance contracts among other things. Sometimes the ordering is set by
 the signing logic itself...

But in that case (unconstrained) randomization can't be used either. This is 
posed as an alternative to randomization. So in that regard, the proposal still 
makes sense.
I think this move to verifyable, deterministic methods where possible is good.

Wladimir

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Bitcoin core 0.11.0 release candidate 1 available

2015-06-05 Thread Wladimir J. van der Laan
Hello,

I've just uploaded Bitcoin Core 0.11.0rc1 executables to:

https://bitcoin.org/bin/bitcoin-core-0.11.0/test/

The source code can be found in the source tarball or in git under the tag 
'v0.11.0rc1'

Preliminary release notes can be found here:

https://github.com/bitcoin/bitcoin/blob/0.11/doc/release-notes.md

Thanks to everyone that participated in development or in the gitian build 
process,

Wladimir


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Bitcoin Core 0.9.5 released

2015-05-24 Thread Wladimir J. van der Laan
Bitcoin Core version 0.9.5 is now available from:

  https://bitcoin.org/bin/0.9.5/

This is a new minor version release, with the goal of backporting BIP66. There
are also a few bug fixes and updated translations. Upgrading to this release is
recommended.

Please report bugs using the issue tracker at github:

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

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

Notable changes


Mining and relay policy enhancements


Bitcoin Core's block templates are now for version 3 blocks only, and any mining
software relying on its `getblocktemplate` must be updated in parallel to use
libblkmaker either version 0.4.2 or any version from 0.5.1 onward.
If you are solo mining, this will affect you the moment you upgrade Bitcoin
Core, which must be done prior to BIP66 achieving its 951/1001 status.
If you are mining with the stratum mining protocol: this does not affect you.
If you are mining with the getblocktemplate protocol to a pool: this will affect
you at the pool operator's discretion, which must be no later than BIP66
achieving its 951/1001 status.

0.9.5 changelog


- `74f29c2` Check pindexBestForkBase for null
- `9cd1dd9` Fix priority calculation in CreateTransaction
- `6b4163b` Sanitize command strings before logging them.
- `3230b32` Raise version of created blocks, and enforce DERSIG in mempool
- `989d499` Backport of some of BIP66's tests
- `ab03660` Implement BIP 66 validation rules and switchover logic
- `8438074` build: fix dynamic boost check when --with-boost= is used

Credits


Thanks to who contributed to this release, at least:

- 21E14
- Alex Morcos
- Cory Fields
- Gregory Maxwell
- Pieter Wuille
- Wladimir J. van der Laan

As well as everyone that helped translating on 
[Transifex](https://www.transifex.com/projects/p/bitcoin/).


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Bitcoin Core 0.9.5 release candidate 1 tagged

2015-05-19 Thread Wladimir J. van der Laan
Hello,

I've just tagged release candidate 1 for 0.9.5 (tag `v0.9.5rc1`).

The reason for this backport release is to make BIP66 available on the 0.9 
branch. This has been requested by a few users, mostly miners.

Full (preliminary) release notes can be found at: 
https://github.com/bitcoin/bitcoin/blob/0.9/doc/release-notes.md

In contrast to 0.10.x releases it is unclear whether there will be enough 
gitian signatures for a binary release, any help with building is welcome.
See https://github.com/bitcoin/bitcoin/blob/0.9/doc/release-process.md
(many steps have changed since then, so the release process for 0.10 or master 
will not work)

Wladimir

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Bitcoin Core 0.10.2 released

2015-05-19 Thread Wladimir J. van der Laan


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Bitcoin Core 0.10.1 release candidate 2 available

2015-05-14 Thread Wladimir J. van der Laan

Binaries for bitcoin Core version 0.10.2rc1 are now available from:

  https://bitcoin.org/bin/0.10.2/test

Source code can be found on github under the signed tag

  https://github.com/bitcoin/bitcoin/tree/v0.10.2rc1

This is a release candidate for a minor version release, with mainly a fix for
a bug that affected Windows users with non-ASCII characters in the data 
directory.
The release also contains translation updates. 

If you experienced no issues with 0.10.1, there is no need to upgrade.

Preliminary release notes for the 0.10.2 release can be found here:

  https://github.com/bitcoin/bitcoin/blob/v0.10.2rc1/doc/release-notes.md

Release candidates are test runs for releases, when no critical
problems are found this release candidate will be tagged as 0.10.2.

Please report bugs using the issue tracker at github:

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


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Wladimir J. van der Laan
On Wed, May 06, 2015 at 10:12:14PM +, Matt Corallo wrote:

 Personally, I'm rather strongly against any commitment to a block size
 increase in the near future. Long-term incentive compatibility requires
 that there be some fee pressure, and that blocks be relatively
 consistently full or very nearly full. What we see today are
 transactions enjoying next-block confirmations with nearly zero pressure
 to include any fee at all (though many do because it makes wallet code
 simpler).

I'm weakly against a block size increase in the near future. Some arguments 
follow. For sake of brevity, this ignores the inherent practical and political 
issues in scheduling a hardfork.

Against:

1. The everyone-verifies-everything approach inherently doesn't scale well. 
Yes, it is possible to increase the capacity, within limits, without completely 
destroying the system, but if scaling turns out to be a success, even a 20-fold 
increase is just a drop in the bucket (this will not make a decentralized 
Changetip possible). The gain will always be linear, at a total cost that 
scales in the number of (full node) users times the block size. The whole idea 
of everyone verifying the whole world's bus tickets and coffee purchases seems 
ludicrous to me. For true scaling, as well as decentralized microtransactions, 
the community needs to work on non-centralized 'level 2' protocols for 
transactions, for example the Lightning network.

  I prefer not to rely on faith that 'Moore's law' - which isn't a physical law 
but a trend - will save us. And it doesn't so much apply to communication 
bandwidth as its techniques are more diverse. E.g. for Bitsat, 20MB blocks will 
push the limit.

2a. Pushing up bandwidth and CPU usage will, inevitably, push people at the 
lower end away from running their own full nodes. Mind you, the sheer number of 
full nodes is not the issue, but Bitcoin's security model is based on being 
able to verify the shared consensus on one's own. A lot of recent development 
effort went into making the node software less heavy. Yes, one could switch to 
SPV, but that is a serious privacy compromise. In the worst case people will 
feel forced to move to webwallets.

  That was about sustained bandwidth - syncing a new node from scratch through 
the internet will become unwieldy sooner - this can be worked around with UTXO 
snapshots, but doing this in a way that doesn't completely pull the rug under 
the security model needs research (I'm aware that this could be construed the 
other way, that such a solution will be needed eventually and fast block chain 
growth just accelerates it).

2b. The bandwidth bound for just downloading blocks is ~4GB per month now, it 
will be ~52GB per month. Behind Tor and other anonimity networks, nodes will 
reveal themselves by the sheer volume of data transferred even to only download 
the block chain. This may already be the case, but will become worse. It may 
even become harmful to Tor itself.

3a. The costs are effectively externalized to users. I, hence, don't like 
calling the costs trivial. I don't like making this decision for others, I'm 
not convinced that they are trivial for everyone. Besides, this will increase 
supply of block chain space, and thus push down transaction fees, but at cost 
to *all users*, even users that hardly do any transactions. Hence it favors 
those that generate lots of transactions (is that a perverse incentive? not 
sure, but it needs to be weighted in any decision).

3b. A mounting fee pressure, resulting in a true fee market where transactions 
compete to get into blocks, results in urgency to develop decentralized 
off-chain solutions. I'm afraid increasing the block size will kick this can 
down the road and let people (and the large Bitcoin companies) relax, until 
it's again time for a block chain increase, and then they'll rally Gavin again, 
never resulting in a smart, sustainable solution but eternal awkward 
discussions like this.

4. We haven't solved the problem of arbitrary data storage, and increasing the 
block size would compound that problem. More data storage more storage 
available for the same price - and up to 20x faster growth of the UTXO set, 
which is permanent (more externalization). More opportunity for pedonazis to 
insert double-plus ungood data, exposing users to possible legal ramifications.

For:

1. First, the obvious: It gives some breathing room in a year (or whenever the 
hard fork is planned). If necessary, it will allow more transactions to be 
on-chain for a while longer while other solutions are being implemented.

2. *Allowing* 20MB blocks does not mean miners will immediately start making 
them. Many of them aren't even filling up to the 1MB limit right now, probably 
due to latency/stale block issues. This makes objection 2 milder, which is 
about *worst case* bandwidth, as well as 4, as the end result may not be 20MB 
blocks filled with arbitrary junk.

3. Investment in off-chain solutions 

[Bitcoin-development] Bitcoin core 0.11 planning

2015-04-28 Thread Wladimir J. van der Laan
Hello all,

The release window for 0.11 is nearing, I'd propose the following schedule:

2015-05-01  Soft translation string freeze
Open Transifex translations for 0.11
Finalize and close translation for 0.9

2015-05-15  Feature freeze, string freeze

2015-06-01  Split off 0.11 branch
Tag and release 0.11.0rc1
Start merging for 0.12 on master branch 

2015-07-01  Release 0.11.0 final (aim)

In contrast to former releases, which were protracted for months, let's try to 
be more strict about the dates. Of course it is always possible for last-minute 
critical issues to interfere with the planning. The release will not be held up 
for features, though, and anything that will not make it to 0.11 will be 
postponed to next release scheduled for end of the year.

Wladimir

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Bitcoin Core 0.10.1 released

2015-04-27 Thread Wladimir J. van der Laan
` Initialization: set fallback locale as environment variable

Credits
===

Thanks to everyone who directly contributed to this release:

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

And all those who contributed additional code review and/or security research:
- 21E14
- Alison Kendler
- Aviv Zohar
- Ethan Heilman
- Evil-Knievel
- fanquake
- Jeff Garzik
- Jonas Nick
- Luke Dashjr
- Patrick Strateman
- Philip Kaufmann
- Sergio Demian Lerner
- Sharon Goldberg

As well as everyone that helped translating on 
[Transifex](https://www.transifex.com/projects/p/bitcoin/).


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Bitcoin Core 0.10.1 release candidate 3 available

2015-04-21 Thread Wladimir J. van der Laan

I've just uploaded Bitcoin Core 0.10.1rc3 executables to:

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

The source code can be found in git under the tag 'v0.10.1rc3' on the `0.10` 
branch.

New in this RC is another batch of bug fixes,

- `eae305f` Fix missing lock in submitblock
- `57d1f46` Fix CheckBlockIndex for reindex
- `bac6fca` Set nSequenceId when a block is fully linked
- `139cd81` Cap nAttempts penalty at 8 and switch to pow instead of a division 
loop
- `323de27` `7494e09` `df45564` Various initialization setup environment locale 
fixes

Full (preliminary) release notes for 0.10.1 can be found at 
https://github.com/bitcoin/bitcoin/blob/v0.10.1rc3/doc/release-notes.md 

Thanks to everyone that participated in development or in the gitian build 
process. I sincerely hope that this can be the final release candidate for 
0.10.1,

Wladimir


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Bitcoin Core 0.10.1 release candidate 1 available

2015-04-02 Thread Wladimir J. van der Laan
Binaries for bitcoin Core version 0.10.1rc1 are now available from:

  https://bitcoin.org/bin/0.10.1/test

Source code can be found in github under the tag

  https://github.com/bitcoin/bitcoin/tree/v0.10.1rc1

This is a release candidate for a minor version release, bringing bug fixes and
translation updates. Release candidates are test runs for releases, when no 
critical
problems are found the release candidate will be tagged as 0.10.1.

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

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

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)

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.

Credits
===

Thanks to everyone who contributed to this release:

- Alex Morcos
- Cory Fields
- dexX7
- fsb4000
- Gregory Maxwell
- Ivan Pustogarov
- Jonas Schnelli
- Pieter Wuille
- Ruben de Vries
- Suhas Daftuar
- Wladimir J. van der Laan

As well as everyone that helped translating on 
[Transifex](https://www.transifex.com/projects/p/bitcoin/).


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net