Okey dokey.

Have you contributed any patches to p2pool to make it more efficient / easier to install / etc? If not, why not if you're so worried about centralization?

(honest question, I don't keep up with p2pool development because I'm personally not terribly worried about mining centralization)

Who gets to decide how slow is too slow?

Mining these days requires investing in ASIC hardware. Solo mining or running a pool will very soon require investing in a reasonably fast network connection and a machine with at least a few gigabytes of memory.

Knocking the slowest N% of solo miners/pools off the network every year (where N is less than 20 or so) is not a crisis. That is the way free-market competition works.

Bitcoin-Qt version 0.8.2 release candidate 1 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

* 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
Wladimir J. van der Laan
freewil
gladoscc
kjj2
mb300sd

+1

I think this is a terrible idea.

If it was "higher fee with superset of outputs of first spend" then that'd be fine.

Zero-confirmation transactions will never be safe because of potential Finney attacks. But we don't need (and, in my opinion, shouldn't) make them less safe by encouraging anti-social behavior via default mining policy.

... hire a lawyer.

Nah, I'm not in the underground facility any more. I packed up the hookers and blow and we're all living the sweet life in a penthouse suite now.

+1

Knock yourselves out, no fork needed, just add this to your bitcoin.conf and convince a few big miners or mining pools to do the same:

    minrelaytxfee=0

Awww, that is cheating!

You really have no business creating your own block chain if you don't understand the code well enough to figure out how to mine a new genesis block without somebody else's help.

Ummm... it is a wiki.  They should just update it themselves (after asking questions if they have any), it is much more efficient.

Yes, please, feedback from re-implementors is very helpful.

Yes.

If you want to get geeky about it, it sends an ECDSA signature derived from the private key and the transaction data, and the full public key that corresponds to your bitcoin address (the address is a shorter version of it).

Sure. That's one of the reasons why I'm reluctant to upgrade the distro/dependencies for the deterministic build process, and generally prefer to use older dependencies rather than the "latest and greatest" of everything. But there's a tradeoff between "risk that an Evil Maintainer slipped something in" and "risk that we ship with an upatched bug" -- e.g. we tend to be on the latest version of OpenSSL, but a few releases behind of Qt4.

PS: if you really want to be completely paranoid, you should only run bitcoin on old hardware/OS manufactured before 2009 so you can be sure the  hardware/firmware/OS doesn't have any wallet-stealing circuits/code lurking....

RE: NODE_RELAYCOST :

I'm generally against any "take my word for it" settings.  What would stop somebody Up To No Good from setting NODE_RELAYCOST and then lying about what they will relay?  Miners might decide to try to increase fees by Sybil-attacking the network and lying about NODE_RELAYCOST....

Minimum transaction output is (conservatively) calculated from the minimum relay fee setting.  It did exist before, it was just set to '1 satoshi'.

We made 0-satoshi outputs non-standard a couple of releases ago, but consensus is that was a mistake-- 1-satoshi is not the right number, because the marginal cost of spending a 1-satoshi output is greater than its value.

Again, eventually it might be economical to spend 1-satoshi outputs. When it is, the minimum relay fee will be on the order of a satoshi or two, and this code will do the right thing.

Bitcoin Foundation uses CloudFlare to protect bitcoinfoundation.org from distributed denial of service attacks.

As the message says, either your computer or a computer on the same network / ISP as yours was sending lots of spammy requests to CloudFlare. So they ask you to solve a CAPTCHA to prove that you're not part of the bad guy's botnet.

A transaction is final if:

All of its sequence numbers are INT_MAX
  OR
lockTime has passed.

I'm still of the opinion that non-final transactions shouldn't be broadcast over the p2p network; I think the parties negotiating using them should keep them to themselves until they are final, and broadcast then.

Y'all read the pull request, yes?

So: if you have a better suggestion for fixing the problem of new users wasting lots of time gathering tiny drips and drabs of bitcoins, and then getting upset when they can't spend them (because it costs more in fees that they are worth), I'm open to suggestions.

RE: "what about when bitcoins are worth a million dollars apiece"

Umm, that's what the "un-hardcode TX_FEE constants" part is all about?

RE: trolling about Foundation setting the fee:

Go back under your rock, please. This pull request is the first step towards a market between miners (who want higher fees) and merchants/users (who want lower fees, but also want their transactions confirmed). Miners can already control what fees they accept, this pull lets users control (very clumsily, improvements on the road map) the fee they are willing to pay.

Network bandwidth is currently growing about 20% per year, or roughly doubling every four years.

Satoshi's original code had a 32MB block size limit, which he dropped to 1MB as part of a bunch of band-aid fixes to make denial-of-service attacks harder.

RE: density of full nodes:  In my opinion, if it is affordable to run a full node (less than, say, $100 per month in server costs-- that is a trivial monthly cost for most businesses and some individuals) then we'll continue to see tens of thousands of full nodes.

Median cost of a dedicated server with lots of bandwidth, disk and CPU is under $100/month these days, which would support a block size at least ten times the current maximum.

And all of THAT is before even starting to think about possible optimizations (e.g. figure out how to mitigate the "insert malicious data" problem-- maybe Peter Todd's security bonds would be helpful-- and a shared DHT storing all valid transactions combined with bloom filters on connections could make it cheap for any one machine to be a fully validating node).

Please, don't listen to all of the FUD being thrown around about raising the block size even before there is any solid proposal for what should be done.

My reaction:  stop spreading FUD.

"small mining pools will go out of business" -- give me a break! My back-of-the-envelope calculations say that anybody willing to spend a few hundred dollars a year on a dedicated server with a high-bandwidth connection can support a MUCH, MUCH larger block size.

The block size will be raised. Your video will just make a lot of people worried about nothing, in exactly the same way Luke-Jr's BIP17 proposal last year (and his hyperbolic rhetoric about BIP16) did nothing but cause a tempest in a teapot.