What stops an attacker from pre-generating tens or hundreds of thousands of alert messages (for tens or hundreds of thousands of their own transactions that the previously put into the chain) and then sending them to the network all at once?

Goal would be to keep the network busy checking the alert signatures.

First: I think it is extremely unlikely that somebody would spend a million dollars on an attack that takes months to pull off, doesn't benefit the attacker at all, is easy to fix, and that would be easy for the network to recover from.

Good idea, and easy to do.

I've got a half-finished "user-defined checkpoint" patch in my personal git tree, so users, merchants, and big mining pools can decide for themselves to add checkpoints on-the-fly (via an 'addcheckpoint' RPC command) to protect against this type of attack.

Good point. I assume that miners will choose to mine the version of a transaction with the highest fee-per-kilobyte, since that will give them the best profit, but actually changing the code to implement that policy has been controversial when I've brought it up before.

To fight transaction spam, I think the relaying logic will need to get smarter, too.  A large, expensive-to-verify double-spend should be way down on the "stuff that should be relayed when there is enough bandwidth" list.


That's a different issue, and a new feature. I think the best way to implement that feature is "child pays for parent" (see https://github.com/bitcoin/bitcoin/pull/1647 for a proposed implementation), and then the user can broadcast a high-fee pay-to-self child transaction to get the parent accepted into a block.

Bitcoin version 0.7.0 release candidate 3 is now available for download at:
  http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.7.0/test/

Unless another critical bug is found, this should be the final 0.7.0 release.

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 were running on Linux with a version that might have been compiled
with a different version of Berkeley DB (for example, if you were using an
Ubuntu PPA version), then run the old version again with the -detachdb
argument and shut it down; if you do not, then the new version will not
be able to read the database files and will exit with an error.

Incompatible Changes
--------------------
* Replaced the 'getmemorypool' RPC command with 'getblocktemplate/submitblock'
  and 'getrawmempool' commands.
* Remove deprecated RPC 'getblocknumber'

Bitcoin Improvement Proposals implemented
-----------------------------------------
BIP 22 - 'getblocktemplate', 'submitblock' RPCs
BIP 34 - block version 2, height in coinbase
BIP 35 - 'mempool' message, extended 'getdata' message behavior


Core bitcoin handling and blockchain database
---------------------------------------------
* Reduced CPU usage, by eliminating some redundant hash calculations
* Cache signature verifications, to eliminate redundant signature checks
* Transactions with zero-value outputs are considered non-standard
* Mining: when creating new blocks, sort 'paid' area by fee-per-kb
* Database: better validation of on-disk stored data
* Database: minor optimizations and reliability improvements
* -loadblock=FILE will import an external block file
* Additional DoS (denial-of-service) prevention measures
* New blockchain checkpoint at block 193,000


JSON-RPC API
------------
* Internal HTTP server is now thread-per-connection, rather than
  a single-threaded queue that would stall on network I/O.
* Internal HTTP server supports HTTP/1.1, pipelined requests and
  connection keep-alive.
* Support JSON-RPC 2.0 batches, to encapsulate multiple JSON-RPC requests
  within a single HTTP request.
* IPv6 support
* Added raw transaction API.  See https://gist.github.com/2839617
* Added 'getrawmempool', to list contents of TX memory pool
* Added 'getpeerinfo', to list data about each connected network peer
* Added 'listaddressgroupings' for better coin control
* Rework gettransaction, getblock calls. 'gettransaction' responds for
  non-wallet TXs now.
* Remove deprecated RPC 'getblocknumber'
* Remove superceded RPC 'getmemorypool' (see BIP 22, above)
* listtransactions output now displays "smart" times for transactions,
  and 'blocktime' and 'timereceived' fields were added


P2P networking
--------------
* IPv6 support
* Tor hidden service support (see doc/Tor.txt)
* Attempts to fix "stuck blockchain download" problems
* Replace BDB database "addr.dat" with internally-managed "peers.dat"
  file containing peer address data.
* Lower default send buffer from 10MB to 1MB
* proxy: SOCKS5 by default
* Support connecting by hostnames passed to proxy
* Add -seednode connections, and use this instead of DNS seeds when proxied
* Added -externalip and -discover
* Add -onlynet to connect only to a given network (IPv4, IPv6, or Tor)
* Separate listening sockets, -bind=<addr>


Qt GUI
------
* Add UI RPC console / debug window
* Re-Enable URI handling on Windows, add safety checks and tray-notifications
* Harmonize the use of ellipsis ("...") to be used in menus, but not on buttons
* Add 2 labels to the overviewpage that display Wallet and Transaction status (obsolete or current)
* Extend the optionsdialog (e.g. language selection) and re-work it to a tabbed UI
* Merge sign/verify message into a single window with tabbed UI
* Ensure a changed bitcoin unit immediately updates all GUI elements that use units
* Update QR Code dialog
* Improve error reporting at startup
* Fine-grained UI updates for a much smoother UI during block downloads
* Remove autocorrection of 0/i in addresses in UI
* Reorganize tray icon menu into more logical order
* Persistently poll for balance change when number of blocks changed
* Much better translations
* Override progress bar design on platforms with segmented progress bars to assist with readability
* Added 'immature balance' display on the overview page
* (Windows only): enable ASLR and DEP for bitcoin-qt.exe
* (Windows only): add meta-data to bitcoin-qt.exe (e.g. description)

Internal codebase
-----------------
* Additional unit tests
* Compile warning fixes


Miscellaneous
-------------
* Reopen debug.log upon SIGHUP
* Bash programmable completion for bitcoind(1)
* On supported OS's, each thread is given a useful name

Right, you do have to remember them for at least a little while...  Replace "relay but don't remember" with "relay and forget as soon as possible."

Sergio:

Is a new type of message necessary?

How about just making the transaction relay rules:

1) If the transaction has inputs that conflict with one already in the best blockchain, drop it.
2) If the transaction has inputs that conflict with another transaction in the memory pool, and it is the first such conflicting transaction, check the new transaction's signatures and if they're OK mark the memory pool transaction as "saw a double spend". Then relay the conflicting transaction (but don't otherwise remember it).

Rule (1) is to prevent an attacker from taking a bunch of her old, already-in-the-blockchain outputs and trying to generate a "double spend alert storm" by sending bogus double-spend attempts for them.

Rule (2) is to limit the amount of network traffic / signature checks an attacker can create to be twice what they can generate today (attackers can, and do, try to flood the network with transactions, but transaction fees and the free transaction relay policy keeps them in check).

The GUI/RPC should definitely show attempted-double-spend memory pool (0-conf) transactions as "BEWARE".

I think those rules will flood the network with the double-spend attempt, alerting merchants/users that something odd is happening. Without making it possible for an attacker to get the network flooded with gazillions of double-spend alert messages.

"Hey, I've got this fantastic idea!"

"Really!  Tell me all about it!"

"We're going to blah blah blah."

"Uhh... did you talk to a lawyer about that? That might be illegal."

"Uhh... really? no."

"And where will you get the money to do it?"

"Uhhh... haven't figured that out yet."

"And if I want to participate, what should I do?"

"Uhh... I dunno, we don't really have a process for that yet..."

I made the mistake of asking a reporter when her deadline was, because if it was far enough away I could tell her about the neat idea. I should have kept my mouth shut or sworn her to secrecy.

Announcing a half-baked idea is counterproductive; you'll just get a gazillion questions that you can't answer, or, even worse, people will assume they know the answers and then be disappointed when it turns out the idea they thought they heard you describe isn't the same idea they thought they heard.

Announcing a fully-baked idea and then modifying it based on what everybody thinks and how it works out in practice is the right way to do things, in my humble opinion.

I've said that I think the download-and-install-software-on-your-PC is a mostly-dead way of using software, and that the vast majority of people using Bitcoin in a year or three will be using it via a web application or on their smart phone. That's half of the reason why I don't think improving the UI is a high priority right now (the other half is because I think solving wallet security and backup issues is critical).

RE: 2112 and GAAP:  "patches welcome."  I don't know nuthin about GAAP, so if you're complaining that the reference implementation doesn't adhere to them then I'm not surprised. Feel free to fix that, or write a detailed proposal on what's wrong, why it'll cause problems, and how it ought to be fixed.

RE: funding development: funding open source software projects is tricky; if done poorly you end up with a couple of paid developers and lots of disappointed unpaid former contributors who decide "I'm not gonna work if I'm not gonna get paid."

That said... stay tuned, and I'll say more when I can.

You're missing the point of Bitcoin if you feel left out. You can be as involved as you want to be, just go make something happen-- find something you think needs doing, recruit some people to help if you need help, and do it. Are you waiting for an invitation or permission from somebody?

Yes, please don't create lots of unspendable scriptPubKeys. There are more prunable ways of embedding messages into transactions. And there are even better ways of associating messages with transactions, so only people involved with the transaction can read the message (if that's desired).

In other words, lets figure out how to do this the right way. The way you're doing it now will stop working as soon as the network upgrades anyway (0-value outputs are nonstandard as of the 0.7 release).

From "Operator Imprecision and Scaling of Shor's Algorithm" (2008):

I don't see any published rebuttals in a quick Google Scholar search. Maybe there will be a breakthrough (or already has been... any QC wizards listening here?) in handling the fuzziness of quantum calculations as you scale up the number of qbits, but 256-bit ECDSA looks pretty darn secure to me right now.

I'd like bitcointalk.org to be in the spirit of the Internet's original ".org" -- For Non-Commercial Use Only.

But... it is hard to figure out what is Commercial Use and what isn't (e.g. some mining pools are non-profit, some for-profit, and I'm sure there are some in the fuzzy middle), which is why there really aren't any rules for .org any more.

I'm leaning towards extending the 2nd argument, to give previous inputs and, if the previous inputs are P2SH, previous inputs scripts.

Along with a new 'rawmultisigaddress' that is just like addmultisigaddress, but doesn't add the redemption script to the wallet but instead returns it.

addmultisigaddress added the P2SH scripts to the wallet.

RE: when can you expect a fix:

It is too late to add new RPC features to the 0.7 release, so no fix until the next release.

Bug. I never tested the combination of signing a pay-to-script-hash transaction with non-wallet private keys.

I'm not 100% sure how to fix it, though. The problem is private keys, public keys, and P2SH scripts are all stored in a "keystore." When you give the third argument to signrawtransaction, it creates a keystore that contains just the private keys (and the corresponding public keys) that you give, and uses that to sign the transaction.

There's currently no way to give it the P2SH script that corresponds to 34y6HmY6zTH51KTC9vd36HasNL4kLKcisC, but the transaction signing code needs that information.

I think the right fix is to give signrawtransaction both the private key(s) and any P2SH information needed...

I was sent a personal message by somebody saying that the burden of proof that something is a scam should be on the person accusing the scammer.  If they can't PROVE it, then they should shut up.

I disagree. I think the burden of proof is on people "guaranteeing" high returns.

Here's how I think of it:

Imagine you see somebody claiming they have invented a perpetual motion machine.

You claim bullshit, because that's against the laws of physics and all previous experience.

Now they send you an email, saying "... before making such accusations you need to PROVE that it cannot work."

Foolproof schemes to make high interest at low risk are the financial world's perpetual motion machines. They do not exist.

Perpetual motion machines may not be scams; there are misguided people who really do believe that they've violated the laws of physics and will prove all of those pesky scientists wrong. I'm sure there are people who truly believe that they've invented foolproof methods of investing lots of money with no risk, too, but I'm equally sure they're delusional.

Yeah, don't do that, you'll annoy some of us moderators.

I think Micon is doing the moral thing, warning people of what he thinks are scams.

I think they're scams, too. It is impossible to get risk-free 1.5% weekly interest, I don't care how good you are at "playing the market" or "choosing who to lend to."

Does valgrind really not work on Mountain Lion?  Good reason for me not to upgrade... (runs great on Snow Leopard).

Securities scares me because in the USA there are strict laws with even TALKING about securities.

I know, I know, Congress is supposed to make no law abridging freedom of speech. I worry that won't stop the SEC from seizing the bitcointalk.org domain name for promoting unlicensed securities.

I think a separate top-level domain for everything under the Marketplace heading would be the right thing to do.

I agree with Micon. I'm embarrassed by 'Long Term Offers' and scared by 'Securities'.

You address it by explaining where the bitcoins come from for the 'guaranteed' payouts.

Credit cards make money by charging merchants a fee, charging interest on late payments, etc. And they mitigate their risk by running credit reports on borrowers.

Legitimate lenders do something similar.

So, I'll ask again: what is your business model?  How will you make the money to payback the people who are sending you X bitcoins and expecting to get X+Y back in a day?