admin

Beware of what I call Pascal's scams: movements or belief systems that ask you to hope for or worry about very improbable outcomes that could have very large positive or negative consequences. (The name comes of course from the infinite-reward Wager proposed by Pascal: these days the large-but-finite versions are far more pernicious). Naive expected value reasoning implies that they are worth the effort: if the odds are 1 in 1,000 that I could win $1 billion, and I am risk and time neutral, then I should expend up to nearly $1 million dollars worth of effort to gain this boon. The problems with these beliefs tend to be at least threefold, all stemming from the general uncertainty, i.e. the poor information or lack of information, from which we abstracted the low probability estimate in the first place: because in the messy real world the low probability estimate is almost always due to low or poor evidence rather than being a lottery with well-defined odds: (1) there is usually no feasible way to distinguish between the very improbable (say, 1 in 1,000) and the extremely improbable (e.g., one in a billion). Poor evidence leads to what James Franklin calls "low-weight probabilities", which lack robustness to new evidence. When the evidence is poor, and thus robustness of probabilities is lacking, then it is likely that "a small amount of further evidence would substantially change the probability. " This new evidence is as likely to decrease the probability by a factor of X as increase it by a factor of X, and the poorer the original evidence, the greater X is. (Indeed, given the nature of human imagination and bias, it is more likely to decrease it, for reasons described below). (2) the uncertainties about the diversity and magnitudes of possible consequences, not just their probabilities, are also likely to be extremely high. Indeed, due to the overall poor information, it's easy to overlook negative consequences and recognize only positive ones, or vice-versa. The very acts you take to make it into utopia or avoid dystopia could easily send you to dystopia or make the dystopia worse. (3) The "unknown unknown" nature of the most uncertainty leads to unfalsifiablity: proponents of the proposition can't propose a clear experiment that would greatly lower the probability or magnitude of consequences of their proposition: or at least, such an experiment would be far too expensive to actually be run, or cannot be conducted until after the time which the believers have already decided that the long-odds bet is rational. So not only is there poor information in a Pascal scam, but in the more pernicious beliefs there is little ability to improve the information. The biggest problem with these schemes is that, the closer to infinitesimal probability, and thus usually to infinitesimal quality or quantity of evidence, one gets, the closer to infinity the possible extreme-consequence schemes one can dream up, Once some enterprising memetic innovator dreams up a Pascal's scam, the probabilities or consequences of these possible futures can be greatly exaggerated yet still seem plausible. "Yes, but what if?" the carrier of such a mind-virus incessantly demands. Furthermore, since more than a few disasters are indeed low probability events (e.g. 9/11), the plausibility and importance of dealing with such risks seems to grow in importance after they occur -- the occurrence of one improbable disaster leads to paranoia about a large number of others, and similarly for fortuitous windfalls and hopes. Humanity can dream up a near-infinity of Pascal's scams, or spend a near-infinity of time fruitlessly worrying about them or hoping for them. There are however far better ways to spend one's time -- for example in thinking about what has actually happened in the real world, rather than the vast number of things that might happen in the future but quite probably won't, or will likely cause consequences very differently than you expect. So how should we approach low probability hypotheses with potential high value (negative or positive) outcomes? Franklin et. al. suggest that "[t]he strongly quantitative style of education in statistics, valuable as it is, can lead to a neglect of the more qualitative, logical, legal and causal perspectives needed to understand data intelligently. That is especially so in extreme risk analysis, where there is a lack of large data sets to ground solidly quantitative conclusions, and correspondingly a need to supplement the data with outside information and with argument on individual data points." On the above quoted points I agree with Franklin, and add a more blunt suggestion: stop throwing around long odds and dreaming of big consequences as if you are onto something profound. If you can't gather the information needed to reduce the uncertainties, and if you can't suggest experiments to make the hope or worry falsifiable, stop nightmaring or daydreaming already. Also, shut up and stop trying to convince the rest of us to join you in wasting our time hoping or worrying about these fantasies. Try spending more time learning about what has actually happened in the real world. That study, too, has its uncertainties, but they are up to infinitely smaller. View the full article

Beware of what I call Pascal's scams: movements or belief systems that ask you to hope for or worry about very improbable outcomes that could have very large positive or negative consequences. (The name comes of course from the infinite-reward Wager proposed by Pascal: these days the large-but-finite versions are far more pernicious). Naive expected value reasoning implies that they are worth the effort: if the odds are 1 in 1,000 that I could win $1 billion, and I am risk and time neutral, then I should expend up to nearly $1 million dollars worth of effort to gain this boon. The problems with these beliefs tend to be at least threefold, all stemming from the general uncertainty, i.e. the poor information or lack of information, from which we abstracted the low probability estimate in the first place: because in the messy real world the low probability estimate is almost always due to low or poor evidence rather than being a lottery with well-defined odds: (1) there is usually no feasible way to distinguish between the very improbable (say, 1 in 1,000) and the extremely improbable (e.g., one in a billion). Poor evidence leads to what James Franklin calls "low-weight probabilities", which lack robustness to new evidence. When the evidence is poor, and thus robustness of probabilities is lacking, then it is likely that "a small amount of further evidence would substantially change the probability. " This new evidence is as likely to decrease the probability by a factor of X as increase it by a factor of X, and the poorer the original evidence, the greater X is. (Indeed, given the nature of human imagination and bias, it is more likely to decrease it, for reasons described below). (2) the uncertainties about the diversity and magnitudes of possible consequences, not just their probabilities, are also likely to be extremely high. Indeed, due to the overall poor information, it's easy to overlook negative consequences and recognize only positive ones, or vice-versa. The very acts you take to make it into utopia or avoid dystopia could easily send you to dystopia or make the dystopia worse. (3) The "unknown unknown" nature of the most uncertainty leads to unfalsifiablity: proponents of the proposition can't propose a clear experiment that would greatly lower the probability or magnitude of consequences of their proposition: or at least, such an experiment would be far too expensive to actually be run, or cannot be conducted until after the time which the believers have already decided that the long-odds bet is rational. So not only is there poor information in a Pascal scam, but in the more pernicious beliefs there is little ability to improve the information. The biggest problem with these schemes is that, the closer to infinitesimal probability, and thus usually to infinitesimal quality or quantity of evidence, one gets, the closer to infinity the possible extreme-consequence schemes one can dream up, Once some enterprising memetic innovator dreams up a Pascal's scam, the probabilities or consequences of these possible futures can be greatly exaggerated yet still seem plausible. "Yes, but what if?" the carrier of such a mind-virus incessantly demands. Furthermore, since more than a few disasters are indeed low probability events (e.g. 9/11), the plausibility and importance of dealing with such risks seems to grow in importance after they occur -- the occurrence of one improbable disaster leads to paranoia about a large number of others, and similarly for fortuitous windfalls and hopes. Humanity can dream up a near-infinity of Pascal's scams, or spend a near-infinity of time fruitlessly worrying about them or hoping for them. There are however far better ways to spend one's time -- for example in thinking about what has actually happened in the real world, rather than the vast number of things that might happen in the future but quite probably won't, or will likely cause consequences very differently than you expect. So how should we approach low probability hypotheses with potential high value (negative or positive) outcomes? Franklin et. al. suggest that "[t]he strongly quantitative style of education in statistics, valuable as it is, can lead to a neglect of the more qualitative, logical, legal and causal perspectives needed to understand data intelligently. That is especially so in extreme risk analysis, where there is a lack of large data sets to ground solidly quantitative conclusions, and correspondingly a need to supplement the data with outside information and with argument on individual data points." On the above quoted points I agree with Franklin, and add a more blunt suggestion: stop throwing around long odds and dreaming of big consequences as if you are onto something profound. If you can't gather the information needed to reduce the uncertainties, and if you can't suggest experiments to make the hope or worry falsifiable, stop nightmaring or daydreaming already. Also, shut up and stop trying to convince the rest of us to join you in wasting our time hoping or worrying about these fantasies. Try spending more time learning about what has actually happened in the real world. That study, too, has its uncertainties, but they are up to infinitely smaller. View the full article

Perhaps I should take up Twitter, but I already have this blog, and even my short takes tend to go a bit over 140 characters. So here goes: * The most important professions in the modern world may be the most reviled: advertiser, salesperson, lawyer, and financial trader. What these professions have in common is extending useful social interactions far beyond the tribe-sized groups we were evolved to inhabit (most often characterized by the Dunbar number). This commonly involves activities that fly in the face of our tribal moral instincts. * On a related note, much mistaken thinking about society could be eliminated by the most straightforward application of the pigeonhole principle: you can't fit more pigeons into your pigeon coop than you have holes to put them in. Even if you were telepathic, you could not learn all of what is going on in everybody's head because there is no room to fit all that information in yours. If I could completely scan 1,000 brains and had some machine to copy the contents of those into mine, I could only learn at most about a thousandth of the information stored in those brains, and then only at the cost of forgetting all else I had known. That's a theoretical optimum; any such real-world transfer process, such as reading and writing an e-mail or a book, or tutoring, or using or influencing a market price, will pick up only a small fraction of even the theoretically acquirable knowledge or preferences in the mind(s) at the other end of said process, or if you prefer of the information stored by those brain(s). Of course, one can argue that some kinds of knowledge -- like the kinds you and I know? -- are vastly more important than others, but such a claim is usually more snobbery than fact. Furthermore, a society with more such computational and mental diversity is more productive, because specialized algorithms, mental processes, and skills are generally far more productive than generalized ones. As Friedrich Hayek pointed out, our mutual inability to understand a very high fraction of what others know has profound implications for our economic and political institutions. * A big problem in the last few years has been the poor recording of transfers of ownership of mortgages (i.e. of the debt not the house). The issue of recording transfers of contractual rights is very interesting. I have a proposal for this, secure property titles. This should work just as well for mortgage securities and other kinds of transferable contractual rights as it does for the real estate itself or other kinds of property. Anytime you transfer rights to a contract it should be registered in such a secure and reliable public database in order to avoid the risk of not being able to prove ownership in court. * Not only should you disagree with others, but you should disagree with yourself. Totalitarian thought asks us to consider, much less accept, only one hypothesis at a time. By contrast quantum thought, as I call it -- although it already has a traditional name less recognizable to the modern ear, scholastic thought -- demands that we simultaneoulsy consider often mutually contradictory possibilities. Thinking about and presenting only one side's arguments gives one's thought and prose a false patina of consistency: a fallacy of thought and communications similar to false precision, but much more common and imporant. Like false precision, it can be a mental mistake or a misleading rhetorical habit. In quantum reality, by contrast, I can be both for and against a proposition because I am entertaining at least two significantly possible but inconsistent hypotheses, or because I favor some parts of a set of ideas and not others. If you are unable or unwilling to think in such a quantum or scholastic manner, it is much less likely that your thoughts are worthy of others' consideration. View the full article

Perhaps I should take up Twitter, but I already have this blog, and even my short takes tend to go a bit over 140 characters. So here goes: * The most important professions in the modern world may be the most reviled: advertiser, salesperson, lawyer, and financial trader. What these professions have in common is extending useful social interactions far beyond the tribe-sized groups we were evolved to inhabit (most often characterized by the Dunbar number). This commonly involves activities that fly in the face of our tribal moral instincts. * On a related note, much mistaken thinking about society could be eliminated by the most straightforward application of the pigeonhole principle: you can't fit more pigeons into your pigeon coop than you have holes to put them in. Even if you were telepathic, you could not learn all of what is going on in everybody's head because there is no room to fit all that information in yours. If I could completely scan 1,000 brains and had some machine to copy the contents of those into mine, I could only learn at most about a thousandth of the information stored in those brains, and then only at the cost of forgetting all else I had known. That's a theoretical optimum; any such real-world transfer process, such as reading and writing an e-mail or a book, or tutoring, or using or influencing a market price, will pick up only a small fraction of even the theoretically acquirable knowledge or preferences in the mind(s) at the other end of said process, or if you prefer of the information stored by those brain(s). Of course, one can argue that some kinds of knowledge -- like the kinds you and I know? -- are vastly more important than others, but such a claim is usually more snobbery than fact. Furthermore, a society with more such computational and mental diversity is more productive, because specialized algorithms, mental processes, and skills are generally far more productive than generalized ones. As Friedrich Hayek pointed out, our mutual inability to understand a very high fraction of what others know has profound implications for our economic and political institutions. * A big problem in the last few years has been the poor recording of transfers of ownership of mortgages (i.e. of the debt not the house). The issue of recording transfers of contractual rights is very interesting. I have a proposal for this, secure property titles. This should work just as well for mortgage securities and other kinds of transferable contractual rights as it does for the real estate itself or other kinds of property. Anytime you transfer rights to a contract it should be registered in such a secure and reliable public database in order to avoid the risk of not being able to prove ownership in court. * Not only should you disagree with others, but you should disagree with yourself. Totalitarian thought asks us to consider, much less accept, only one hypothesis at a time. By contrast quantum thought, as I call it -- although it already has a traditional name less recognizable to the modern ear, scholastic thought -- demands that we simultaneoulsy consider often mutually contradictory possibilities. Thinking about and presenting only one side's arguments gives one's thought and prose a false patina of consistency: a fallacy of thought and communications similar to false precision, but much more common and imporant. Like false precision, it can be a mental mistake or a misleading rhetorical habit. In quantum reality, by contrast, I can be both for and against a proposition because I am entertaining at least two significantly possible but inconsistent hypotheses, or because I favor some parts of a set of ideas and not others. If you are unable or unwilling to think in such a quantum or scholastic manner, it is much less likely that your thoughts are worthy of others' consideration. View the full article

Bitcoin-Qt version 0.6.3 is now available for download at: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.3/ This is a bug-fix release, with no new features. CHANGE SUMMARY Fixed a serious denial-of-service attack that could cause the bitcoin process to become unresponsive. Thanks to Sergio Lerner for finding and responsibly reporting the problem. (CVE-2012-3789) Optimized the process of checking transaction signatures, to speed up processing of new block messages and make propagating blocks across the network faster. Fixed an obscure bug that could cause the bitcoin process to get stuck on an invalid block-chain, if the invalid chain was hundreds of blocks long. Bitcoin-Qt no longer automatically selects the first address in the address book (Issue #1384). Fixed minimize-to-dock behavior of Bitcon-Qt on the Mac. Added a block checkpoint at block 185,333 to speed up initial blockchain download. Thanks to everybody who contributed to this release: Chris Moore Christian von Roques Fordy Gavin Andresen Jeff Garzik Luke Dashjr Matt Corallo Michael Hendricks Peter Todd Philip Kaufmann Pieter Wuille R E Broadley Sergio Lerner Wladimir J. van der Laan View the full article

Bitcoin-Qt version 0.6.2 is now available for download at: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.2/ This is a bug-fix and code-cleanup release, with no major new features. NOTABLE CHANGES Much faster shutdowns. However, the blkindex.dat file is no longer portable to different data directories by default. If you need a portable blkindex.dat file then run with the new -detachdb=1 option or the “Detach databases at shutdown” GUI preference. Fixed https://github.com/bitcoin/bitcoin/issues/1065, a bug that could cause long-running nodes to crash. Mac and Windows binaries are compiled against OpenSSL 1.0.1b (Linux binaries are dynamically linked to the version of OpenSSL on the system). CHANGE SUMMARY Use git shortlog --no-merges v0.6.0.. for a summary of this release. Source codebase changes: - Many source code cleanups and warnings fixes. Close to building with -Wall - Locking overhaul, and several minor locking fixes - Several source code portability fixes, e.g. FreeBSD JSON-RPC interface changes: - addmultisigaddress enabled for mainnet (previously only enabled for testnet) Network protocol changes: - protocol version 60001 - added nonce value to “ping” message (BIP 31) - added new “pong” message (BIP 31) Backend storage changes: - Less redundant database flushing, especially during initial block download - Shutdown improvements (see above) Qt user interface: - minor URI handling improvements - progressbar improvements - error handling improvements (show message box rather than console exception, etc.) - by popular request, make 4th bar of connection icon green Thanks to everybody who contributed to this release: Chris Moore Dwayne C. Litzenberger Gavin Andresen Jeff Garzik Luke Dashjr Matt Corallo Philip Kaufmann Pieter Wuille R E Broadley Timothy Redaelli Wladimir J. van der Laan cardpuncher freewil graingert sje397 View the full article

Bitcoin-Qt version 0.6.1 is now available for download at: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.1/ This is a bug-fix and code-cleanup release, with no major new features. NOTABLE CHANGES Much faster shutdowns. However, the blkindex.dat file is no longer portable to different data directories by default. If you need a portable blkindex.dat file then run with the new -detachdb=1 option or the “Detach databases at shutdown” GUI preference. Mac and Windows binaries are compiled against OpenSSL 1.0.1b (Linux binaries are dynamically linked to the version of OpenSSL on the system). CHANGE SUMMARY Use git shortlog --no-merges v0.6.0.. for a summary of this release. Source codebase changes: - Many source code cleanups and warnings fixes. Close to building with -Wall - Locking overhaul, and several minor locking fixes - Several source code portability fixes, e.g. FreeBSD JSON-RPC interface changes: - addmultisigaddress enabled for mainnet (previously only enabled for testnet) Network protocol changes: - protocol version 60001 - added nonce value to “ping” message (BIP 31) - added new “pong” message (BIP 31) Backend storage changes: - Less redundant database flushing, especially during initial block download - Shutdown improvements (see above) Qt user interface: - minor URI handling improvements - progressbar improvements - error handling improvements (show message box rather than console exception, etc.) - by popular request, make 4th bar of connection icon green Thanks to everybody who contributed to this release: Chris Moore Dwayne C. Litzenberger Gavin Andresen Jeff Garzik Luke Dashjr Matt Corallo Philip Kaufmann Pieter Wuille R E Broadley Timothy Redaelli Wladimir J. van der Laan cardpuncher freewil graingert sje397 View the full article

Bitcoin-Qt version 0.6.0 is now available for download at: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/ This release includes more than 20 language localizations. More translations are welcome; join the project at Transifex to help: https://www.transifex.net/projects/p/bitcoin/ Please report bugs using the issue tracker at github: https://github.com/bitcoin/bitcoin/issues Project source code is hosted at github; we are no longer distributing .tar.gz files here, you can get them directly from github: https://github.com/bitcoin/bitcoin/tarball/v0.6.0 # .tar.gz https://github.com/bitcoin/bitcoin/zipball/v0.6.0 # .zip For Ubuntu users, there is a ppa maintained by Matt Corallo which you can add to your system so that it will automatically keep bitcoin up-to-date. Just type sudo apt-add-repository ppa:bitcoin/bitcoin in your terminal, then install the bitcoin-qt package. KNOWN ISSUES Shutting down while synchronizing with the network (downloading the blockchain) can take more than a minute, because database writes are queued to speed up download time. NEW FEATURES SINCE BITCOIN VERSION 0.5 Initial network synchronization should be much faster (one or two hours on a typical machine instead of ten or more hours). Backup Wallet menu option. Bitcoin-Qt can display and save QR codes for sending and receiving addresses. New context menu on addresses to copy/edit/delete them. New Sign Message dialog that allows you to prove that you own a bitcoin address by creating a digital signature. New wallets created with this version will use 33-byte ‘compressed’ public keys instead of 65-byte public keys, resulting in smaller transactions and less traffic on the bitcoin network. The shorter keys are already supported by the network but wallet.dat files containing short keys are not compatible with earlier versions of Bitcoin-Qt/bitcoind. New command-line argument -blocknotify=<command> that will spawn a shell process to run <command> when a new block is accepted. New command-line argument -splash=0 to disable Bitcoin-Qt’s initial splash screen validateaddress JSON-RPC api command output includes two new fields for addresses in the wallet: pubkey : hexadecimal public key iscompressed : true if pubkey is a short 33-byte key New JSON-RPC api commands for dumping/importing private keys from the wallet (dumprivkey, importprivkey). New JSON-RPC api command for getting information about blocks (getblock, getblockhash). New JSON-RPC api command (getmininginfo) for getting extra information related to mining. The getinfo JSON-RPC command no longer includes mining-related information (generate/genproclimit/hashespersec). NOTABLE CHANGES BIP30 implemented (security fix for an attack involving duplicate “coinbase transactions”). The -nolisten, -noupnp and -nodnsseed command-line options were renamed to -listen, -upnp and -dnsseed, with a default value of 1. The old names are still supported for compatibility (so specifying -nolisten is automatically interpreted as -listen=0; every boolean argument can now be specified as either -foo or -nofoo). The -noirc command-line options was renamed to -irc, with a default value of 0. Run -irc=1 to get the old behavior. Three fill-up-available-memory denial-of-service attacks were fixed. NOT YET IMPLEMENTED FEATURES Support for clicking on bitcoin: URIs and opening/launching Bitcoin-Qt is available only on Linux, and only if you configure your desktop to launch Bitcoin-Qt. All platforms support dragging and dropping bitcoin: URIs onto the Bitcoin-Qt window to start payment. PRELIMINARY SUPPORT FOR MULTISIGNATURE TRANSACTIONS This release has preliminary support for multisignature transactions– transactions that require authorization from more than one person or device before they will be accepted by the bitcoin network. Prior to this release, multisignature transactions were considered ‘non-standard’ and were ignored; with this release multisignature transactions are considered standard and will start to be relayed and accepted into blocks. It is expected that future releases of Bitcoin-Qt will support the creation of multisignature transactions, once enough of the network has upgraded so relaying and validating them is robust. For this release, creation and testing of multisignature transactions is limited to the bitcoin test network using the “addmultisigaddress” JSON-RPC api call. Short multisignature address support is included in this release, as specified in BIP 13 and BIP 16. Thanks to everybody who contributed to this release: Alex B Alistair Buxton Chris Moore Clark Gaebel Daniel Folkinshteyn Dylan Noblesmith Forrest Voight Gavin Andresen Gregory Maxwell Janne Pulkkinen Joel Kaartinen Lars Rasmusson Luke Dashjr Matt Corallo Michael Ford Michael Hendricks Nick Bosma Nils Schneider Philip Kaufmann Pierre Pronchery Pieter Wuille Rune K Svendsen Wladimir J. van der Laan coderrr p2k sje397 Special thanks to Sergio Lerner and Matt Corallo for bringing potential denial-of-service attacks to our attention. View the full article

Bitcoin-Qt version 0.5.3.1 for Windows is now available for download at: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.3/ This is a bugfix-only release based on 0.5.1. Please report bugs using the issue tracker at GitHub: https://github.com/bitcoin/bitcoin/issues BUG FIXES Fixed a potentially critical security vulnerability in Windows versions of Bitcoin-Qt. View the full article

Bitcoin-Qt version 0.5.3 is now available for download at: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.3/ This is a bugfix-only release based on 0.5.1. It also includes a few protocol updates. Please report bugs using the issue tracker at GitHub: https://github.com/bitcoin/bitcoin/issues PROTOCOL UPDATES BIP 30: Introduce a new network rule: “a block is not valid if it contains a transaction whose hash already exists in the block chain, unless all that transaction’s outputs were already spent before said block” beginning on March 15, 2012, 00:00 UTC. On testnet, allow mining of min-difficulty blocks if 20 minutes have gone by without mining a regular-difficulty block. This is to make testing Bitcoin easier, and will not affect normal mode. BUG FIXES Limit the number of orphan transactions stored in memory, to prevent a potential denial-of-service attack by flooding orphan transactions. Also never store invalid transactions at all. Fix possible buffer overflow on systems with very long application data paths. This is not exploitable. Resolved multiple bugs preventing long-term unlocking of encrypted wallets (issue #922). Only send local IP in “version” messages if it is globally routable (ie, not private), and try to get such an IP from UPnP if applicable. Reannounce UPnP port forwards every 20 minutes, to workaround routers expiring old entries, and allow the -upnp option to override any stored setting. Skip splash screen when -min is used, and fix Minimize to Tray function. Do not blank “label” in Bitcoin-Qt “Send” tab, if the user has already entered something. Correct various labels and messages. Various memory leaks and potential null pointer deferences have been fixed. Handle invalid Bitcoin URIs using “bitcoin://” instead of “bitcoin:”. Several shutdown issues have been fixed. Revert to “global progress indication”, as starting from zero every time was considered too confusing for many users. Check that keys stored in the wallet are valid at startup, and if not, report corruption. Enable accessible widgets on Windows, so that people with screen readers such as NVDA can make sense of it. Various build fixes. If no password is specified to bitcoind, recommend a secure password. Automatically focus and scroll to new “Send coins” entries in Bitcoin-Qt. Show a message box for –help on Windows, for Bitcoin-Qt. Add missing “About Qt” menu option to show built-in Qt About dialog. Don’t show “-daemon” as an option for Bitcoin-Qt, since it isn’t available. Update hard-coded fallback seed nodes, choosing recent ones with long uptime and versions at least 0.4.0. Add checkpoint at block 168,000. View the full article

Bitcoin-Qt version 0.5.2 is now available for download at: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.2/ This is a bugfix-only release. Please report bugs using the issue tracker at GitHub: https://github.com/bitcoin/bitcoin/issues BUG FIXES Check all transactions in blocks after the last checkpoint (0.5.0 and 0.5.1 skipped checking ECDSA signatures during initial blockchain download; this was not a security vulnerability). Cease locking memory used by non-sensitive information (this caused a huge performance hit on some platforms, especially noticable during initial blockchain download). Fixed some address-handling deadlocks (client freezes). No longer accept inbound connections over the internet when Bitcoin is being used with Tor (identity leak). Re-enable SSL support for the JSON-RPC interface (it was unintentionally disabled for the 0.5.0 and 0.5.1 release Linux binaries). Use the correct base transaction fee of 0.0005 BTC for accepting transactions into mined blocks (since 0.4.0, it was incorrectly accepting 0.0001 BTC which was only meant to be relayed). Don’t show “IP” for transactions which are not necessarily IP transactions. Add new DNS seeds (maintained by Pieter Wuille and Luke Dashjr). View the full article

Bitcoin-Qt version 0.5.1 is now available for download at: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.1/ This is a bugfix-only release. This release includes 13 translations, including 5 new translations: Italian, Hungarian, Ukranian, Portuguese (Brazilian) and Simplified Chinese. More translations are welcome; join the project at Transifex if you can help: https://www.transifex.com/projects/p/bitcoin/ Please report bugs using the issue tracker at GitHub: https://github.com/bitcoin/bitcoin/issues For Ubuntu users, there is a new ppa maintained by Matt Corallo which you can add to your system so that it will automatically keep bitcoin up-to-date. Just type sudo apt-add-repository ppa:bitcoin/bitcoin in your terminal, then install the bitcoin-qt package. BUG FIXES Re-enable SSL support for the JSON-RPC interface (it was unintentionally disabled for the 0.5.0 release binaries). The code that finds peers via “dns seeds” no longer stops bitcoin startup if one of the dns seed machines is down. Tooltips on the transaction list view were rendering incorrectly (as black boxes or with a transparent background). Prevent a denial-of-service attack involving flooding a bitcoin node with orphan blocks. The wallet passphrase dialog now warns you if the caps lock key was pressed. Improved searching in addresses and labels in bitcoin-qt. View the full article

During my blog absence, I've been studying, designing, and implementing a style of programming I call temporal programming. It is useful for, among other things, implementing smart contracts. Meanwhile, I encourage readers interested in programming to check out Node.js. Temporal programming starts with event-oriented programming and takes it further. Temporal programming will give us control over when our instructions get executed: the plodding do this, then that, then the other, as if machine activities are only supposed to happen in one big long sequence and merely output some big long tape, will be relegated to secondary status. More to come. -------- Is Netflix management really stupid? To summarize Megan McCardle, no: under copyright law, DVDs are covered by the first sale rule -- once you buy a DVD, you can't make a copy, but you can sell, rent or give away the DVD itself. Streaming, on the other hand, essentially involves making a copy, and you can't do it legally without the copyright owner's permission. So to stream the most demanded content, you usually need the permission of owners, and thus have to pay what they demand. It thus makes complete sense that Netflix has to charge high prices for streaming -- because for the kind of content they want to stream (i.e. the copyrights that are so valuable that their owners bother to prevent the content from being distributed on YouTube), content owners are demanding revenues similar to what they are accustomed to via cable. I'd add that the first sale rule also explains why Netflix, contrary to its name, originally succeeded in out-competing a gaggle of Internet video streaming companies by the stone-age method of shipping DVDs by mail. The main thing Netflix may have done wrong was, after succeeding in pivoting from Internet streaming to mailing DVDs, going back to their original goal in a way that set false expectations about prices (i.e. that streaming prices would be closer to DVD rental prices than to cable TV). Probably what happened is that Netflix CEO Reed Hastings thought he could use his mail-order rental business as leverage to negotiate lower prices with copyright owners, but this strategy did not succeed. It also makes sense that Netflix (and their streaming competitors) lack licensed content due to copyright owners' long-standing aversion to Internet streaming. All this was happening to Netflix's video-streaming competitors long before Netflix's much more recent emphasis on that business. Netflix apparently hasn't, after all, solved the institutional problem that their DVD-shipping model worked around. --------- Bit gold and I make brief appearances in Wired's Bitcoin article. --------- Water remains fun. Digital fountains show how precisely drops can be located and timed: This one is a bit different, drops fall with uniform regularity but are used to display light: View the full article

Bitcoin-Qt version 0.5.0 is now available for download at: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.5.0/ The major change for this release is a completely new graphical that uses the Qt user interface toolkit. This release includes German, Spanish, Spanish-Castilian, Norwegian and Dutch translations. More translations are welcome; join the project at Transifex if you can help: https://www.transifex.com/projects/p/bitcoin/ Please report bugs using the issue tracker at GitHub: https://github.com/bitcoin/bitcoin/issues MAJOR BUG FIX (CVE-2011-4447) The wallet encryption feature introduced in Bitcoin version 0.4.0 did not sufficiently secure the private keys. An attacker who managed to get a copy of your encrypted wallet.dat file might be able to recover some or all of the unencrypted keys and steal the associated coins. If you have a previously encrypted wallet.dat, the first time you run bitcoin-qt or bitcoind the wallet will be rewritten, Bitcoin will shut down, and you will be prompted to restart it to run with the new, properly encrypted file. If you had a previously encrypted wallet.dat that might have been copied or stolen (for example, you backed it up to a public location) you should send all of your bitcoins to yourself using a new bitcoin address and stop using any previously generated addresses. Wallets encrypted with this version of Bitcoin are written properly. Technical note: the encrypted wallet’s ‘keypool’ will be regenerated the first time you request a new bitcoin address; to be certain that the new private keys are properly backed up you should: Run Bitcoin and let it rewrite the wallet.dat file Run it again, then ask it for a new bitcoin address. Bitcoin-Qt: Address Book, then New Address… bitcoind: run the walletpassphrase RPC command to unlock the wallet, then run the getnewaddress RPC command. If your encrypted wallet.dat may have been copied or stolen, send all of your bitcoins to the new bitcoin address. Shut down Bitcoin, then backup the wallet.dat file. IMPORTANT: be sure to request a new bitcoin address before backing up, so that the ‘keypool’ is regenerated and backed up. “Security in depth” is always a good idea, so choosing a secure location for the backup and/or encrypting the backup before uploading it is recommended. And as in previous releases, if your machine is infected by malware there are several ways an attacker might steal your bitcoins. Thanks to Alan Reiner (aka etotheipi) for finding and reporting this bug. MAJOR GUI CHANGES “Splash” graphics at startup that show address/wallet/blockchain loading progress. “Synchronizing with network” progress bar to show block-chain download progress. Icons at the bottom of the window that show how well connected you are to the network, with tooltips to display details. Drag and drop support for bitcoin: URIs on web pages. Export transactions as a .csv file. Many other GUI improvements, large and small. RPC CHANGES getmemorypool : new RPC command, provides everything needed to construct a block with a custom generation transaction and submit a solution listsinceblock : new RPC command, list transactions since given block signmessage/verifymessage : new RPC commands to sign a message with one of your private keys or verify that a message signed by the private key associated with a bitcoin address. GENERAL CHANGES Faster initial block download. View the full article

Full announcement (including signatures) Bitcoin version 0.4.0 is now available for download at: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.0/ The main feature in this release is wallet private key encryption; you can set a passphrase that must be entered before sending coins. See below for more information; if you decide to encrypt your wallet, WRITE DOWN YOUR PASSPHRASE AND PUT IT IN A SECURE LOCATION. If you forget or lose your wallet passphrase, you lose your bitcoins. Previous versions of bitcoin are unable to read encrypted wallets, and will crash on startup if the wallet is encrypted. Also note: bitcoin version 0.4 uses a newer version of Berkeley DB (bdb version 4.8) than previous versions (bdb 4.7). If you upgrade to version 0.4 and then revert back to an earlier version of bitcoin the it may be unable to start because bdb 4.7 cannot read bdb 4.8 “log” files. Notable bug fixes from version 0.3.24 Fix several bitcoin-becomes-unresponsive bugs due to multithreading deadlocks. Optimize database writes for large (lots of inputs) transactions (fixes a potential denial-of-service attack) Wallet Encryption Bitcoin supports native wallet encryption so that people who steal your wallet file don’t automatically get access to all of your Bitcoins. In order to enable this feature, chose “Encrypt Wallet” from the Options menu. You will be prompted to enter a passphrase, which will be used as the key to encrypt your wallet and will be needed every time you wish to send Bitcoins. If you lose this passphrase, you will lose access to spend all of the bitcoins in your wallet, no one, not even the Bitcoin developers can recover your Bitcoins. This means you are responsible for your own security, store your passphrase in a secure location and do not forget it. Remember that the encryption built into bitcoin only encrypts the actual keys which are required to send your bitcoins, not the full wallet. This means that someone who steals your wallet file will be able to see all the addresses which belong to you, as well as the relevant transactions, you are only protected from someone spending your coins. It is recommended that you backup your wallet file before you encrypt your wallet. To do this, close the Bitcoin client and copy the wallet.dat file from ~/.bitcoin/ on Linux, /Users/(user name)/Library/Application Support/Bitcoin/ on Mac OSX, and %APPDATA%/Bitcoin/ on Windows (that is /Users/(user name)/AppData/Roaming/Bitcoin on Windows Vista and 7 and /Documents and Settings/(user name)/Application Data/Bitcoin on Windows XP). Once you have copied that file to a safe location, reopen the Bitcoin client and Encrypt your wallet. If everything goes fine, delete the backup and enjoy your encrypted wallet. Note that once you encrypt your wallet, you will never be able to go back to a version of the Bitcoin client older than 0.4. Keep in mind that you are always responsible for your own security. All it takes is a slightly more advanced wallet-stealing trojan which installs a keylogger to steal your wallet passphrase as you enter it in addition to your wallet file and you have lost all your Bitcoins. Wallet encryption cannot keep you safe if you do not practice good security, such as running up-to-date antivirus software, only entering your wallet passphrase in the Bitcoin client and using the same passphrase only as your wallet passphrase. See the doc/README file in the bitcoin source for technical details of wallet encryption. View the full article

Full announcement (including signatures) Bitcoin v0.3.24 is now available for download at http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.24/ This is another bug fix release. We had hoped to have wallet encryption ready for release, but more urgent fixes for existing clients were needed – most notably block download problems were getting severe. Wallet encryption is ready for testing at https://github.com/bitcoin/bitcoin/pull/352 for the git-savvy, and hopefully will follow shortly in the next release, v0.4. Notable fixes in v0.3.24, and the main reasons for this release: Block downloads were failing or taking unreasonable amounts of time to complete, because the increased size of the block chain was bumping up against some earlier buffer-size DoS limits. Fix crash caused by loss/lack of network connection. Notable changes in v0.3.24: DNS seeding enabled by default. UPNP enabled by default in the GUI client. The percentage of bitcoin clients that accept incoming connections is quite small, and that is a problem. This should help. bitcoind, and unofficial builds, are unchanged (though we encourage use of “-upnp” to help the network!). Initial unit testing framework. Bitcoin sorely needs automated tests, and this is a beginning. Contributions welcome. Internal wallet code cleanup. While invisible to an end user, this change provides the basis for v0.4’s wallet encryption. View the full article

Win32, Linux, MacOSX and source releases for bitcoin v0.3.23 have been uploaded to http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.23/ This is another quick bugfix release, trying to deal with the influx of new bitcoin users. Priority for next version: wallet encryption Main items of note: P2P connect-to-node logic changed to reduce timeout a bit. The network saw a huge influx of new users, who do not permit incoming connections. This change is a short-term hack, to more quickly hunt for useful P2P connections. Better “leaf node” logic is in the works, but this should let us limp along until then. One may use -upnp to properly forward ports, and help the network. Transaction fee reduced to 0.0005 for new transactions (see note below) Client will relay transactions with fees as low as 0.0001 BTC (see note below) NOTE: There has been some fee confusion recently. Free transactions are supported and relayed as they always have been, according to special anti-spam rules. See https://en.bitcoin.it/wiki/Transaction_fees for details. There were no changes between -rc1 and -final. View the full article

Download URL: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.22/ This is largely a bugfix and TX fee schedule release. We also hope to make 0.3.23 a quick release, to fix problems that the network has seen due to explosive growth in the past week. Notable changes: Client will accept and relay TX’s with 0.0005 BTC fee schedule (users still pay 0.01 BTC per kb, until next version) Non-standard transactions accepted on testnet Source code tree reorganized (prep for autotools build) Remove “Generate Coins” option from GUI, and remove 4way SSE miner. Internal reference CPU miner remains available, but users are directed to external miners for best hash production. IRC is overflowing. Client now bootstraps to channels #bitcoin00 - #bitcoin99 DNS names now may be used with -addnode, -connect (requires -dns to enable) RPC changes: listtransactions adds from param, for range queries move may take account balances negative settxfee added, to manually set TX fee Recommendations: If you have trouble connecting to the network, try one or more of these techniques: -dnsseed -upnp, or forward port 8333 on your router View the full article

Binaries for Bitcoin version 0.3.21 are available at: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.21/ Changes and new features from the 0.3.20 release include: Universal Plug and Play support. Enable automatic opening of a port for incoming connections by running bitcoin or bitcoind with the -upnp=1 command line switch or using the Options dialog box. Support for full-precision bitcoin amounts. You can now send, and bitcoin will display, bitcoin amounts smaller than 0.01. However, sending fewer than 0.01 bitcoins still requires a 0.01 bitcoin fee (so you can send 1.0001 bitcoins without a fee, but you will be asked to pay a fee if you try to send 0.0001). A new method of finding bitcoin nodes to connect with, via DNS A records. Use the -dnsseed option to enable. For developers, changes to bitcoin’s remote-procedure-call API: New rpc command “sendmany” to send bitcoins to more than one address in a single transaction. Several bug fixes, including a serious intermittent bug that would sometimes cause bitcoind to stop accepting rpc requests. -logtimestamps option, to add a timestamp to each line in debug.log. Immature blocks (newly generated, under 120 confirmations) are now shown in listtransactions. View the full article