This gives me warm fuzzies; a University of Chicago professor speculating about how a wildly successful Bitcoin might affect the International Monetary Fund!

I don't really care what is said, just the fact that Bitcoin is being talked about in the elite Ivory Towers is a very good thing.

Yes.  If you're feeling helpful, please create a wiki page or other document that organizes all of the pro/con arguments: economic and technical. And maybe another wiki page that organizes all of the various proposals for how to increase the block size.

I've been derailed the last week by a death in the family, and still need to finish up some payment protocol work.

I'm doing well this month, so far I've been called an "Angry Internet Troll", a "coward", and a "nazi".

Selling my Butterfly Labs BitForce 5 GH/s SC (aka Jalapeno) ASIC miner.

It has been reliably cranking out about 5 and a half GH/s at about 35 watts for
two weeks now; I'm selling it just so I have one less thing in my life to think about.

I paid 25.9 BTC for it; best offer over 26 BTC before 16:00 UTC Sunday, 9 June gets it.
I'll ship it UPS/USPS/Fedex on the 10'th or 11'th, you must pay shipping (e.g. if you
want it overnight, add shipping charges from Amherst, MA 01002 to your payment).

PGP signed version of the above, so you know this is really me and not a scammer who managed to hack my forum account:

No, absolutely not. The process for a hard fork looks like:

+ Get rough consensus that the change is necessary.
+ Write the code.
+ Get it reviewed and thoroughly tested.
+ Release software that will support it when X% of hashing power agrees

... where X is a super-majority (like 75% or more).  If 70% of hashing power disagrees, then it doesn't happen. Miners will express support by producing block.version=3 blocks (just like they are now producing block.version=2 blocks that MUST include the chain height in the coinbase transaction).

It is possible the X% threshold will never happen if 1MB is plenty big enough. It is possible it will only happen when transaction fees start going up and pressure increases on pools to make their blocks bigger (or maybe merchants tired of paying high fees figure out they'll save money by mining or operating pools themselves, will get X% of hashing power, and will increase the block size).

Again, I spent a lot of time at the conference talking with people about the block size issue, and there is definitely consensus that 1MB just won't be big enough eventually. That has nothing to do with microtransactions, normal growth in "macrotransactions" will bump up against the limit in a year or three.

Which "bigger powers" and which "people" ?

Is there some secret cabal out there I don't know about?

If you mean "Peter Todd has convinced some big mining pool operators not to increase the size of the blocks they create" -- then great!  That's the free market at work, big mining pools should be free to create blocks that are as large or as small as they like, and to accept or reject other's blocks for whatever reason they like.

Thanks!

PS:  I'm still giving away 10 BTC per month from those funds to the Minecraft Faucet (I committed 100BTC to the Minecraft Faucet folks before the EFF announced they'd accept Bitcoin donations again)...

The block size will be raised, that is the overwhelming consensus among the people who are actually writing code and using Bitcoin for products and services that it needs to happen.

And there is a tiny minority of people who will loudly proclaim that isn't true and that the core developer are going to destroy Bitcoin if the block size is raised.

If you want to be helpful, please organize a list of objections to raising the block size limit and responses to those objections.

I believe the last objection raised was that a higher block size limit would make it impossible to mine anonymously, but I think that has been debunked with the notion of "read the firehose of transactions non-anonymously, then broadcast just new block header + coinbase + listof(truncated transaction hashes) anonymously."

I'll soon be writing up a plan for how we can safely raise the block size limit.


RE: central planning:

No central planning is why I would like to eliminate the hard, upper blocksize limit entirely, and let the network decide "how big is too big."

RE: "the plan"  :   The plan from the beginning was to support huge blocks.  The 1MB hard limit was always a temporary denial-of-service prevention measure.

How do you prevent Sybil attacks-- somebody creating a gazillion n-client and/or hatching nodes, and voting themselves lots and lots of new currency?

And how does a node choose a "random" node-- does every node know about every other node?  If yes, then how do you avoid getting O(N^2) communication as the number of nodes (N) rises and every existing node must be told about every new node?

Security, yes (including potential for denial-of-service attacks of various sorts).

But demonstrate a spiffy, compelling use of new opcodes on testnet and we'll talk about making them standard.

I've started and then stopped writing about Zerocoin three or four times now; my thoughts about it are still muddled.

It adds a whole lot of complexity to transaction creation/verification to solve one problem:  how to mix coins/transactions with zero trust in the mixing process.  That's technically nifty, but I wonder if it is the best engineering solution.

I wonder if just using a couple of semi-trusted mixers would be a lot faster/smaller/simpler.

And then I start thinking about "tainted coins" in general. If we imagine a world with either mandatory or voluntary "taint tracking" (I have no idea whether or not that will ever happen), then it seems to me any mixing scheme that isn't "always on" is likely to fail in practice-- all coins coming out of the mix will be considered tainted.

Why? I assume that most users (if you are reading this are NOT "most users") don't care much about privacy/anonymity. So I would assume most people would choose the lowest cost, fastest, most convenient method for their transactions. Anybody using a mixer will be either a weirdo, principled privacy nut (like us) or a criminal. I don't see other "privacy first" projects taking over the world, but do see lots of big, successful "quick and easy and free" projects.

Then my thoughts get muddled, because "it is hopeless, just give up" is not an answer I'm willing to accept. But it feels to me like finding an essentially zero-cost way to increase transaction privacy that everybody uses by default is the best answer. Making your network connection more private is the other piece of the puzzle, though, and all of the solutions for that (either route through a couple of semi-trusted proxies or use Tor or i2p) add significant convenience/speed/financial costs.

Bitcoin-Qt version 0.8.2 is now available from:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.2/

This is a maintenance release that fixes many bugs and includes
a few small new features.

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

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

0.8.2 Release notes

Fee Policy changes

The default fee for low-priority transactions is lowered from 0.0005 BTC
(for each 1,000 bytes in the transaction; an average transaction is
about 500 bytes) to 0.0001 BTC.

Payments (transaction outputs) of 0.543 times the minimum relay fee
(0.00005430 BTC) are now considered 'non-standard', because storing them
costs the network more than they are worth and spending them will usually
cost their owner more in transaction fees than they are worth.

Non-standard transactions are not relayed across the network, are not included
in blocks by most miners, and will not show up in your wallet until they are
included in a block.

The default fee policy can be overridden using the -mintxfee and -minrelaytxfee
command-line options, but note that we intend to replace the hard-coded fees
with code that automatically calculates and suggests appropriate fees in the
0.9 release and note that if you set a fee policy significantly different from
the rest of the network your transactions may never confirm.

Bitcoin-Qt changes

* New icon and splash screen
* Improve reporting of synchronization process
* Remove hardcoded fee recommendations
* Improve metadata of executable on MacOSX and Windows
* Move export button to individual tabs instead of toolbar
* Add "send coins" command to context menu in address book
* Add "copy txid" command to copy transaction IDs from transaction overview
* Save & restore window size and position when showing & hiding window
* New translations: Arabic (ar), Bosnian (bs), Catalan (ca), Welsh (cy),
  Esperanto (eo), Interlingua (la), Latvian (lv) and many improvements
  to current translations

MacOSX:
* OSX support for click-to-pay (bitcoin:) links
* Fix GUI disappearing problem on MacOSX (issue #1522)

Linux/Unix:
* Copy addresses to middle-mouse-button clipboard


Command-line options

* -walletnotify will call a command on receiving transactions that affect the wallet.
* -alertnotify will call a command on receiving an alert from the network.
* -par now takes a negative number, to leave a certain amount of cores free.

JSON-RPC API changes

* fixed a getblocktemplate bug that caused excessive CPU creating blocks.
* listunspent now lists account and address infromation.
* getinfo now also returns the time adjustment estimated from your peers.
* getpeerinfo now returns bytessent, bytesrecv and syncnode.
* gettxoutsetinfo returns statistics about the unspent transaction output database.
* gettxout returns information about a specific unspent transaction output.


Networking changes

* Significant changes to the networking code, reducing latency and memory consumption.
* Avoid initial block download stalling.
* Remove IRC seeding support.
* Performance tweaks.
* Added testnet DNS seeds.

Wallet compatibility/rescuing

* Cases where wallets cannot be opened in another version/installation should be reduced.
* -salvagewallet now works for encrypted wallets.


Known Bugs

* Entering the 'getblocktemplate' or 'getwork' RPC commands into the Bitcoin-Qt debug
console will cause Bitcoin-Qt to crash. Run Bitcoin-Qt with the -server command-line
option to workaround.

Thanks to everybody who contributed to the 0.8.2 release!

APerson241
Andrew Poelstra
Calvin Owens
Chuck LeDuc Díaz
Colin Dean
David Griffith
David Serrano
Eric Lombrozo
Gavin Andresen
Gregory Maxwell
Jeff Garzik
Jonas Schnelli
Larry Gilbert
Luke Dashjr
Matt Corallo
Michael Ford
Mike Hearn
Patrick Brown
Peter Todd
Philip Kaufmann
Pieter Wuille
Richard Schwab
Roman Mindalev
Scott Howard
Tariq Bashir
Warren Togami
Wladimir J. van der Laan
freewil
gladoscc
kjj2
mb300sd
super3

latency of what? getblocktemplate?  getbalance?

0.8.2 rc2 never made it out the door; two crash-on-shutdown bugs and a bitcoin.ico file that made the windows gitian build non-reproducible made us jump to rc3 instead.

So:

Bitcoin-Qt version 0.8.2 release candidate 3 is now available from:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.2/test/

This is a maintenance release that fixes many bugs and includes
a few small new features.

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

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

0.8.2 Release notes
===================

Fee Policy changes
------------------

The default fee for low-priority transactions is lowered from 0.0005 BTC
(for each 1,000 bytes in the transaction; an average transaction is
about 500 bytes) to 0.0001 BTC.

Payments (transaction outputs) of 0.543 times the minimum relay fee
(0.00005430 BTC) are now considered 'non-standard', because storing them
costs the network more than they are worth and spending them will usually
cost their owner more in transaction fees than they are worth.

Non-standard transactions are not relayed across the network, are not included
in blocks by most miners, and will not show up in your wallet until they are
included in a block.

The default fee policy can be overridden using the -mintxfee and -minrelaytxfee
command-line options, but note that we intend to replace the hard-coded fees
with code that automatically calculates and suggests appropriate fees in the
0.9 release and note that if you set a fee policy significantly different from
the rest of the network your transactions may never confirm.

Bitcoin-Qt changes
------------------

* New icon and splash screen
* Improve reporting of synchronization process
* Remove hardcoded fee recommendations
* Improve metadata of executable on MacOSX and Windows
* Move export button to individual tabs instead of toolbar
* Add "send coins" command to context menu in address book
* Add "copy txid" command to copy transaction IDs from transaction overview
* Save & restore window size and position when showing & hiding window
* New translations: Arabic (ar), Bosnian (bs), Catalan (ca), Welsh (cy),
  Esperanto (eo), Interlingua (la), Latvian (lv) and many improvements
  to current translations

MacOSX:
* OSX support for click-to-pay (bitcoin:) links
* Fix GUI disappearing problem on MacOSX (issue #1522)

Linux/Unix:
* Copy addresses to middle-mouse-button clipboard


Command-line options
--------------------

* -walletnotify will call a command on receiving transactions that affect the wallet.
* -alertnotify will call a command on receiving an alert from the network.
* -par now takes a negative number, to leave a certain amount of cores free.

JSON-RPC API changes
--------------------

* fixed a getblocktemplate bug that caused excessive CPU creating blocks.
* listunspent now lists account and address infromation.
* getinfo now also returns the time adjustment estimated from your peers.
* getpeerinfo now returns bytessent, bytesrecv and syncnode.
* gettxoutsetinfo returns statistics about the unspent transaction output database.
* gettxout returns information about a specific unspent transaction output.


Networking changes
------------------

* Significant changes to the networking code, reducing latency and memory consumption.
* Avoid initial block download stalling.
* Remove IRC seeding support.
* Performance tweaks.
* Added testnet DNS seeds.

Wallet compatibility/rescuing
-----------------------------

* Cases where wallets cannot be opened in another version/installation should be reduced.
* -salvagewallet now works for encrypted wallets.


Thanks to everybody who contributed to the 0.8.2 release!
---------------------------------------------------------

APerson241
Andrew Poelstra
Calvin Owens
Chuck LeDuc Díaz
Colin Dean
David Griffith
David Serrano
Eric Lombrozo
Gavin Andresen
Gregory Maxwell
Jeff Garzik
Jonas Schnelli
Larry Gilbert
Luke Dashjr
Matt Corallo
Michael Ford
Mike Hearn
Patrick Brown
Peter Todd
Philip Kaufmann
Pieter Wuille
Richard Schwab
Roman Mindalev
Scott Howard
Tariq Bashir
Warren Togami
Wladimir J. van der Laan
freewil
gladoscc
kjj2
mb300sd
super3

Except they're not learning from Bitcoin's mistakes; how many alt coins have fixed the problems on Bitcoin's hard-fork wish list?

I received my pre-ordered (day 2, I think) Jalapeno today.

Yes, after NUMEQUALVERIFY the stack will be empty, and for a script to be valid it must leave a true value on the stack.

Use NUMEQUAL and it should work.

Couple years ago it was "Don't talk to the CIA! They're Evil, and will Destroy Bitcoin!"

Now it is "Don't get involved in DC lobbying! That's Evil, and will Destroy Bitcoin!"

In a few more years, I bet it'll be "Don't go to the United Nations! They're Evil, and will Destroy Bitcoin!"

I'll quote myself from a related thread on google+

You are wrong.  If Bitcoin was using (double) MD5 for its proof-of-work hashing algorithm, we'd be just fine.

If there is a longer fork with more work that your node thinks is invalid, you'll get this alert:

    Warning: Displayed transactions may not be correct! You may need to upgrade, or other nodes may need to upgrade.

(see the GetWarnings() function in main.cpp).

If you are on the fork with the most work... I suppose if the second-best chain was forked more than 6 blocks back and contained more than... oh,  5 blocks and the timestamp on the last block in that chain was less than ?an hour ago? that could trigger another alert.

All that might be tricky to implement-- either (or both) forks might themselves have forks.  Or, theoretically, there could be three or more active forks, some of which might have equal proof-of-work...