When you change a file, or crop part out of it, you invalidate the signature. It would be more worrying if that worked.

Where did you get those files? I think they are falsified! BE VERY CAREFUL and don't run it.

- My name is not "Wladimir J. van der lann" but "Wladimir J. van der Laan" (and my mail is not lannwj@gmail.com either)
- There is no "bitcoin-0.15.0.1-osx.dmg.asc". The only signed file in the distribution should be "SHA256SUMS.asc" which contains a list of SHA256 hashes, one for every file.

I followed the following steps on the command line to manually check the correctness of the release signing signature on 0.15.0.1:

Do not run any dmg or other binary until you get an output like this.

Absolutely. You can send transactions to yourself to consolidate the UTXO set. As an added bonus, this will reduce the number of unspent outputs in your wallet, thus simplify (and speed up) output selection on spend. It can also reduce the size of created transactions, thus reduce the total amount of fees paid.

There is a slight disadvantage to privacy as you'd be linking together outputs that might have stayed unlinked. But it could be done strategically for outputs that are known to be linked already (e.g. those zillions of small payouts).


This is not possible. Other nodes and miners do not (and should not!) know what UTXOs belong together. That would be a privacy breach. Also they cannot generate a new address for you to send it to.

This kind of consolidation is the responsibility of the wallet software, directed by the user.

The code as-in in git master is very close to what will be released as 0.10. There are no large merges pending anymore, or large blocker issues. The last few days have been mostly small bugfixes.

Issues and pulls still blocking the 0.10 release can be found here (but doesn't include all the small stuff):
https://github.com/bitcoin/bitcoin/milestones/0.10.0

You can help by testing the current master. It would be good if the current state got some testing before the first release candidate.

I'm waiting with the rc release until Cory gets back from holiday next week, to handle build system issues which will likely come up with the new release process and gitian.

It's probably for refunds. Just generate a new receiving address under 'Receive' tab and give that.

Although it makes things more difficult, you don't really need the P2P protocol. You can send block and transaction data over *any* medium. Some suggestions I've heard are to post them (at least the block headers + links) on forums, in pastebins, or host http servers that serve the data yourself. Other ways of transferring would be though faux-video streams in video chat services. Or given absence of the internet, even broadcasting the block chain through radio. Possibly using a satellite (see http://www.coindesk.com/jeff-garzik-announces-partnership-launch-bitcoin-satellites-space/). Or indeed, mesh networks.

Of course a client would have to be written that can collect the data this way, but it is no technical barrier.

I wouldn't say it is impossible to kill politically, i mean given global North-Korea levels of tyranny, like taking away all technology from the common people, could of course foil bitcoin pretty much. But if that happens we'll have other things to worry about than bitcoin.

That's strange indeed. Probably a database (either the UTXO database or the block index) was corrupted in a sneaky way. You had tried a reindex before?

Anyhow, great to hear that your problem is solved.

It will be incorporated when someone implements it. It's an open source project, so there is no saying who will pick this up. AFAIK no one is working on wallet features in Bitcoin Core at the moment. The core developers are focused on improving the node infrastructure. Maybe Cozz (who got Coin Control to a state where it could be merged) would be interested, given incentive.

Bitcoin Core version 0.9.3 is now available from:

  https://bitcoin.org/bin/0.9.3/

This is a new minor version release, bringing only 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

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

If you are upgrading from version 0.7.2 or earlier, the first time you run
0.9.3 your blockchain files will be re-indexed, which will take anywhere from
30 minutes to several hours, depending on the speed of your machine.

Downgrading warnings
--------------------

The 'chainstate' for this release is not always compatible with previous
releases, so if you run 0.9.x and then decide to switch back to a
0.8.x release you might get a blockchain validation error when starting the
old release (due to 'pruned outputs' being omitted from the index of
unspent transaction outputs).

Running the old release with the -reindex option will rebuild the chainstate
data structures and correct the problem.

Also, the first time you run a 0.8.x release on a 0.9 wallet it will rescan
the blockchain for missing spent coins, which will take a long time (tens
of minutes on a typical machine).

0.9.3 Release notes
=======================

RPC:
- Avoid a segfault on getblock if it can't read a block from disk
- Add paranoid return value checks in base58

Protocol and network code:
- Don't poll showmyip.com, it doesn't exist anymore
- Add a way to limit deserialized string lengths and use it
- Add a new checkpoint at block 295,000
- Increase IsStandard() scriptSig length
- Avoid querying DNS seeds, if we have open connections
- Remove a useless millisleep in socket handler
- Stricter memory limits on CNode
- Better orphan transaction handling
- Add `-maxorphantx=<n>` and `-maxorphanblocks=<n>` options for control over the maximum orphan transactions and blocks

Wallet:
- Check redeemScript size does not exceed 520 byte limit
- Ignore (and warn about) too-long redeemScripts while loading wallet

GUI:
- fix 'opens in testnet mode when presented with a BIP-72 link with no fallback'
- AvailableCoins: acquire cs_main mutex
- Fix unicode character display on MacOSX

Miscellaneous:
- key.cpp: fail with a friendlier message on missing ssl EC support
- Remove bignum dependency for scripts
- Upgrade OpenSSL to 1.0.1i (see https://www.openssl.org/news/secadv_20140806.txt - just to be sure, no critical issues for Bitcoin Core)
- Upgrade miniupnpc to 1.9.20140701
- Fix boost detection in build system on some platforms

Credits
--------

Thanks to everyone who contributed to this release:

- Andrew Poelstra
- Cory Fields
- Gavin Andresen
- Jeff Garzik
- Johnathan Corgan
- Julian Haight
- Michael Ford
- Pavel Vasin
- Peter Todd
- phantomcircuit
- Pieter Wuille
- Rose Toomey
- Ruben Dario Ponticelli
- shshshsh
- Trevin Hofmann
- Warren Togami
- Wladimir J. van der Laan
- Zak Wilcox

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

rc2 has been uploaded last weekend to https://bitcoin.org/bin/0.9.3/test/, with some further fixes in network and memory behaviour

Well, Bitcoin Core has a very simple format. You don't need any developer support to understand it:
Time format is ISO8601 (%Y-%m-%dT%H:%M:%SZ), key format is WIF (importprivkey format).

At a certain point the Android Bitcoin Wallet export format was the same except that it was encrypted with AES.

I actually agree with you though, it would be great if different wallets had a standard export format. The first step would be writing a BIP. If the proposal is sensible I don't think much is needed to get wallet authors to implement it, as the need for this is kind of a no-brainer.

For the different deterministic wallets this is more tricky as they (currently) use different ways to generate the keys. If they all used BIP32 it'd be a lot easier.

I've noticed this as well, collected some information here:
https://gist.github.com/laanwj/2a89da909bf161c7e4c2

* It appears that all the hosts are from Linode, and that they open multiple connections (about 5-6)
* They claim NODE_NETWORK, but none of them has a sync height, so they're not actually requesting blocks (and will probably also not respond to getblocks requests, although I haven't tried)
* I've enabled verbose logging for them, and from what I've seen they don't ever emit any commands apart from pong and version. They just listen for invs.
* They do not accept incoming connections at least on the standard ports.

Note that the universal wallet format does not need to equal the internal wallet format used by the software. Wallets can store their internal database in any way that is efficient (and secure) for them as long as there is a way to import/export the universal format.

Bitcoin Core supports the `dumpwallet` and `importwallet` RPC commands for going from/to an interchange wallet format. This is basically just a text file with a list of private keys with metadata.

BTW: in general, unless you have a very good reason to do otherwise, I'd recommend to generate new keys and transfer your coins when you switch to a new wallet. This is safer and better supported.

You don't get any kind of traceback or core dump from the OS either? We really need one to even start debugging this problem.
What is your usage scenario? Mining? A lot of RPC calls?
Does this happen in both bitcoin-qt and bitcoind?

Not really. 0.9.2.1 is still the latest stable version. This is a release candidate, so is meant for testing.

Not to this minor release, which has only a very small number of fixes. He did sign the DMG and MacOSX binaries. He certainly still contributes to the next major version (what is in git master).

Bitcoin Core version 0.9.3rc1 is now available from:

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

This is a release candidate (test version) for a new minor version release, bringing
only bug fixes and updated translations.

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

If you are upgrading from version 0.7.2 or earlier, the first time you run
0.9.3 your blockchain files will be re-indexed, which will take anywhere from
30 minutes to several hours, depending on the speed of your machine.

Downgrading warnings
--------------------

The 'chainstate' for this release is not always compatible with previous
releases, so if you run 0.9.x and then decide to switch back to a
0.8.x release you might get a blockchain validation error when starting the
old release (due to 'pruned outputs' being omitted from the index of
unspent transaction outputs).

Running the old release with the -reindex option will rebuild the chainstate
data structures and correct the problem.

Also, the first time you run a 0.8.x release on a 0.9 wallet it will rescan
the blockchain for missing spent coins, which will take a long time (tens
of minutes on a typical machine).

0.9.3 Release notes
=======================

RPC:
- Avoid a segfault on getblock if it can't read a block from disk
- Add paranoid return value checks in base58

Protocol and network code:
- Don't poll showmyip.com, it doesn't exist anymore
- Add a way to limit deserialized string lengths and use it
- Add a new checkpoint at block 295,000
- Increase IsStandard() scriptSig length
- Avoid querying DNS seeds, if we have open connections

Wallet:
- Check redeemScript size does not exceed 520 byte limit
- Ignore (and warn about) too-long redeemScripts while loading wallet

GUI:
- fix 'opens in testnet mode when presented with a BIP-72 link with no fallback'
- AvailableCoins: acquire cs_main mutex
- Fix unicode character display on MacOSX

Miscellaneous:
- key.cpp: fail with a friendlier message on missing ssl EC support
- Remove bignum dependency for scripts
- Upgrade OpenSSL to 1.0.1i (see https://www.openssl.org/news/secadv_20140806.txt - just to be sure, no critical issues for Bitcoin Core)
- Upgrade miniupnpc to 1.9.20140701
- Fix boost detection in build system on some platforms

Credits
--------

Thanks to everyone who contributed to this release:

- Andrew Poelstra
- Cory Fields
- Jeff Garzik
- Johnathan Corgan
- Julian Haight
- Michael Ford
- Pavel Vasin
- Peter Todd
- Pieter Wuille
- Rose Toomey
- Ruben Dario Ponticelli
- Trevin Hofmann
- Wladimir J. van der Laan
- Zak Wilcox

As well as everyone that helped translating on Transifex

It does nothing in bitcoind. Only in bitcoin-qt.

To be fair, the tech support for consumers for something like Windows or Microsoft Office is also non-existent. Only if you're part of a large enterprise and can apply pressure through account managers you have any hope of getting your issue solved in any realistic time-frame. So usually with Windows, if something fails, you just live with it or work around it (using some workaround that you found on the net).

For Bitcoin Core (and most open-source software) it's on an best-effort basis. If it's a serious problem that is possible to reproduce (or you make very detailed bug report) it usually gets resolved quickly. If it is just a minor annoyance, or something that can be worked around, this can take much longer - if it is no-one's pet project.

If something really bugs you, you could hire an consultant/programmer to fix it for you (or through the vendor with a "service contract"). This applies to both open source and closed source software.

In a community project you *may* find someone crazy enough to do it for you for free as a pet project (for example for the 'cred'), but do not take this for granted.

In this case, Qt is themeable and themes exist 'out there'. Either you can find a theme and have someone integrate it into Bitcoin-Qt (may not even require c++ programming). Or have someone design a theme for you from scratch (probably going to be expensive - like developers,  designers won't work for free unless it's their pet project, and designing Qt themes is a rare speciality).

The widget toolkit Qt is fully themable. By default Qt tries to look native (and boring), because it's commonly used for serious user interfaces such as for industrial systems. But you could use another Qt theme, or design one yourself. On at least Linux desktop environments based on GTK or Qt you can change the global theme of your desktop and Qt will pick that up.

As gmaxwell says there is a lot to designing a good GUI apart from it looking 'pretty'. Safety and usability is a first concern.

In general everything is possible. This is an open source project. If someone contributes towards making it look more "pretty" (and other people agree - I don't think a my little pony theme will be accepted as default), it will. It won't improve by just waiting, for any amount of time.

Edit: Also, going over the top with a 'pretty' interface means committing to redesign every two years, as the fashion trends change quickly and what looks exciting at one point looks ridiculous the next. Native widgets don't go out of style because they never were in style.

Anyone that suffers from the MacOSX 10.9 address display problem or the shutdown issue mentioned above can upgrade to 0.9.2.1 here which fixes these: https://bitcoin.org/bin/0.9.2.1/ . If you have no problems with 0.9.2 there is no reason to upgrade to 0.9.2.1.