Once.

(it is actually once every couple of months, but that's a secret and might change so don't tell anybody that)

Sipa has been busy implementing IPv6 support and much better support for running bitcoin as a Tor hidden service. Both of those should help make the network more robust and resistant to attack. If a lot of people decide to run only inside Tor then it will look like even fewer nodes are listening, though.

Use one of the send commands to send to the multisig address several times and you will create several multisig transactions.

addmultisigaddress does not create a transaction, it just creates a place for future transactions to go.

There will be 2.1 quadrillion satoshis.

There are approximately 770 trillion pennies in the US M2 money supply.

We've got a VERY VERY long way to go before bitcoins are as popular as dollars, and there are much higher priority things to work on right now than adding more divisibility for a problem that is pretty likely to never actually be a problem.

etotheipi:

Sorry, I was responding to the original proposal, not yours, I should have made that clear.

Better protocol support for lightweight clients is a Good Idea.

And in two years maybe anybody who can afford to buy an asic-mining-space-heater for their house can mine.  And in ten years maybe new houses will come pre-equipped with asic-mining-baseboard-electric-heaters.

Or maybe not.  Nobody knows what is going to happen, which is why I keep repeating BITCOIN IS AN EXPERIMENT IN PROGRESS.  If you can't handle uncertainty and the very real possibility that the experiment will fail, then don't get involved (but don't come back whining that you missed out if the experiment turns out to be a huge success).

No, I don't think it is a problem, any more than the relatively small number of "backbone" routers are a problem for the Internet. The bitcoin network is evolving in roughly the direction I expected it would (lots of lightweight clients connecting to a smaller number of heavyweight "backbone" nodes).

All of the incentives are for merchants, exchanges, and big mining pools to accept lots of connections, relay only valid transactions and blocks, and be as DoS-resistant as they can afford. Merchants and exchanges want transactions to be validated quickly, the big mining pools want their payouts to be processed quickly and want their blocks propagated quickly, and they all want to be reliable.  The big exchanges and mining pools have ALREADY implemented DDoS countermeasures because they have ALREADY been attacked. And the network keeps chugging away, processing transactions....

Chaining not-yet-signed transactions is impossible because transaction inputs are identified by the previous transaction's hash, and the transaction's hash includes everything about the transaction, including the signatures.

A multisignature transaction taking funds from #1 and paying them to #4 that requires signatures from #1, #2, and #3 should accomplish the same thing, though.

So code up a prototype:

+ Implement code that computes and publishes 'balance blocks' and 'balance block hashes'. Convince a couple people with extra download bandwidth to run it.
+ Modify one of the bitcoin implementations to download the latest 'balance block' from some trusted place at startup, and use it if transactions/blocks can't be found in the traditional block database.
+ Extra credit/paranoia : query a couple of trusted places for the balance block hash, and make sure it matches the hash you got.
+ OR: randomly spot-check the balance block by requesting blocks in the traditional way, and make sure the balance block doesn't list any outputs as unspent that are actually spent.

You don't want bitcoin address balances, there are no addresses way down deep inside. You need to know which transaction outputs have not yet been spent, and the value of those outputs.

I'm not excited about this proposal, because I think it is solving a problem that doesn't need solving yet, and my priorities for bitcoin continue to be wallet security and network stability, not making it quicker for newbie solo miners to get a full blockchain so they can start validating transactions/blocks.

The format is a list of pairs, where the first item is the scriptSig required to spend and the second is the scriptPubKey. The third item is ignored (useful for comments).

script_valid.json contains only valid scriptSig/scriptPubKey pairs.
script_invalid.json contains only invalid scriptSig/scriptPubKey pairs.

valid/invalid are defined by the rules of transaction validation, and the unit test actually constructs transactions and runs the verification routine on them to make sure that they succeed or fail, as expected.

Your unit tests look like they'll miss lots of edge cases.

I've been working on cross-implementation unit tests for Script, and am actually working on more tests today (and am working on a testnet reset that will embed the "should validate" tests into the testnet block chain).

JSON format tests are here:
  https://github.com/bitcoin/bitcoin/tree/master/src/test/data

(read by https://github.com/bitcoin/bitcoin/blob/master/src/test/script_tests.cpp )

Works in a Terminal on my Mac, returns:... which validates as:I don't know enough about Windows CLI quoting rules to get ["...","...","..."] passed un-modified to bitcoind.exe.  

No. Bitcoin connections are TCP, so you can't forge the IP address.

I've also implemented denial-of-service checks that automatically ban misbehaving peers to make network disruption attacks more difficult. Trying to anticipate future DoS attacks is hidden engineering work that you will never notice if we get it right.

The Bitcoin Faucet's wallet was stolen a couple of months ago:
  http://gavintech.blogspot.com/2012/03/bitcoin-faucet-hacked.html

Gather (or generate) 3 bitcoin addresses, on whichever machines will be participating, using getnewaddress or getaccountaddress  RPC commands (or copy and paste from the GUI).

Get their public keys using the validateaddress RPC command 3 times.

Then create a 2-of-3 multisig address using addmultisigaddress; e.g.

addmultisigaddress returns the multisignature address. Be a little careful, the public keys are raw hexadecimal and don't contain checksums like bitcoin addresses do.

You can then send funds into that 2-of-3 transaction using the normal sendtoaddress/sendmany RPC commands, or the GUI (or anything that's been updated to recognize multisig addresses).

That will create a multi signature transaction.

If you want to then SPEND the funds sent in that 2-of-3 transaction... that isn't implemented yet (well, if bitcoin has all 3 private keys in it's wallet then the funds will show up in the wallet's total balance and it may be selected to be spent like any other funds received by the wallet). "We" need to implement RPC calls to implement BIP 10 or something like it.

What Pieter said. BIPs are intended to make it easier for different implementations of Bitcoin to inter-operate with each other. The existing network protocol is just one piece of that.

Bitcoind doesn't run on ppc-- and minimum supported osx version is 10.5.

And Armory depends on bitcoind, right?

We have been quietly notifying the largest exchanges, merchant service providers and mining pools about this issue, and waited until they upgraded or patched their code to go public with this:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

CVE-2012-2459: Critical Vulnerability

A denial-of-service vulnerability that affects all versions of
bitcoind and Bitcoin-Qt has been reported and fixed. An attacker
could isolate a victim's node and cause the creation of blockchain
forks.

Because this bug could be exploited to severely disrupt the Bitcoin
network we consider this a critical vulnerability, and encourage
everybody to upgrade to the latest version: 0.6.2.

Backports for older releases (0.5.5 and 0.4.6) are also available if
you cannot upgrade to version 0.6.2.

Full technical details are being withheld to give people the
opportunity to upgrade.

Thanks to Forrest Voight for discovering and reporting the vulnerability.


Questions that might be frequently asked:

How would I know if I am the victim of this attack?

Your bitcoin process would stop processing blocks and would have a
different block count from the rest of the network (you can see the
current block count at websites like blockexplorer.com or
blockchain.info).  Eventually it would display the message:

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

(note that this message is displayed whenever your bitcoin process
detects that the rest of the network seems to have a different
block count, which can happen for several reasons unrelated to
this vulnerability).


Could this bug be used to steal my wallet?

No.


Could this bug be used to install malware on my system?

No.


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)

iQIcBAEBCgAGBQJPsTpaAAoJECnZ7msfxzDB76cQALBqcEb40dQOtopbsk7vHDuL
FL4xd56B1/s3idyHGeCuwJX5bgxGD9b3svayXhDiLo9O+5E3sxsLY1HehTXnU8KV
BGpIQ7I+XLDcmarGYrDLMNMDLFOp/1hTipi08X3cr6oHNdYOxGbdtqCQR8xxtdfh
Mmo07ReYYWamlF+QbwoXIJQOEka2UVeWWgmk1C+WW1phI3P3Of5EvWvkmOurZsY1
zew7G3sk0Lu8glxSt8qq1SKlDXOaSqTBPxs+2FtgkUplNrAIyufu0vCTsnC44oie
ndJD6XZAaG6cYr3adGQKmUjRR+oyZarMtBdDHBvYHkrQI4uQclL1aS7DhkLtH8kp
fBRHdqmbBJpmpWOcs+OZeaQCzrArKihuVVZqP4HYbHgGHLV3Ls1bebyWm5eLZH6Z
C5l3B4Hz/lp50gJpVsIZI291l3KWfoBW2qGyQv51U4uByLU8tPzgr5bdyo6YCo4N
XQZHveNInMDI8jSimGyHg7WNm0YjkSAM8PEIJhQuL+RaHKgN/ghLPR+1K1YZnMjq
BPdJZVDpP2bgClyj6P+UkhAplEoenxZUsjyRmcs9EWjHZo3UUI9MLZW96vkR0Wlv
UBgq0/jSNQ6s3U3YwKM8CDFJ4OB7Mu1Ln6sn+Tu5sl3xtPyapARA5K67FYSpvqVX
GNIME8aiNjICQmtIFiuX
=9L8G
-----END PGP SIGNATURE-----

I'm definitely not in the "speculators are evil" camp.  Speculation for the right reasons (hedging risk, for example) is a very good thing.

I personally think speculation for the thrill of gambling is not a good thing, but I'm also not in the "Every Bad Thing (where I get to decide what Bad and Good is) Should Be Illegal" camp. If you want to gamble you should be free to do so; I think it is stupid that we let rich people on Wall Street gamble with other people's money and yet have laws that make it illegal for not-so-rich people to gamble with their own money.

From his post, Tong thought about Bitcoinica and decided that he could be more effective at making the world a better place by working on something else that is more obviously positive-sum. Good for him!

It seems I touched a nerve when I said that getting better at playing a zero-sum game isn't a good way to make the world a better place.

I was thinking of day-traders at the time; people who don't care what asset they're buying and selling but just try to buy low and sell high to make a profit. Or high-frequency traders who try to be just a tiny bit faster executing transactions to take advantage of tiny inefficiencies in markets.

Probably I don't have a deep enough understanding of the value of liquidity in asset markets or a deep enough appreciation for their role in creating market prices, but it seems to me the world would get along just fine without them spending all their time and effort competing against each other.

I wasn't thinking of competition in general as being a zero-sum game, because in general it is not.  Competition drives efficiency, and efficiency (creating more by using less) is what makes the world a better place -- assuming that the thing you're making more efficient has a positive effect on the world.  Competing to build the most efficient bomb or assault rifle is not a world-improving activity.

To bring it back to Bitcoin: competition between Bitcoin miners is a zero-sum game for the miners, but if you think that Bitcoin will make the world a better place (I do) then the competition to be more efficient at mining is a net positive for the world as a whole.

Good luck-- I share your view that coming up with better ways of playing zero-sum games is not the way to make the world a better place.