Sure-- I've always liked the BitTorrent/W3C model because it is less centralized (lots of different implementations of the protocol, as opposed to a project like Perl, where essentially everybody runs the same code).  I consider Satoshi's code the "reference" client, though, not "proof-of-concept", since there is no formal specification.

(I've written a formal specification, and I think having a working reference implementation is better than An Officially Blessed Pile of Paper).

The upcoming 0.7 release will support running as a hidden service, and supports hidden services finding each other via the p2p and dnsseed peer-finding mechanisms; see
   https://github.com/bitcoin/bitcoin/blob/master/doc/Tor.txt  for information.

Relevant recent IRC discussion: http://bitcoinstats.com/irc/bitcoin-dev/logs/2012/07/11/6#l3981048

Bottom line: I think transaction replacement is important, but if we just enable it as-is then I think we open up the entire network to an easy DoS attack.

And I think the incentives for miners aren't right. I think the rule for what version of a transaction will be included in blocks has to be something like "the one that pays miners most OR the one that pays miners first (if there are several with the same fee)."

So I think a scheme where transaction fees are increased, or lock times are decreased, with every transaction replacement is the right way to go.

Mmm.  That's why if I were King I'd fast forward to a couple years from now when there were several mature bitcoin clients and bitcoin.org would not list any directly at all (see w3c.org for an example, you won't find a "Download a Web Browser Now!" link).

But I'm not King and unlike the Web there aren't a bunch of mature, well-funded bitcoin clients to choose from yet.

Yes, he ruffled a bunch of feathers by unilaterally changing bitcoin.org instead of submitting a pull request that could be tweaked and argued about.

You can see the discussion here:  http://sourceforge.net/mailarchive/forum.php?thread_name=4FFBF1DF.8070203%40justmoon.de&forum_name=bitcoin-development

RE: 101 or 103 unused keys in the keypool:  That's normal.  Here's the sequence of events that causes it:

+ You do something that requests a new key from the keypool. Several things do that (including the 'getinfo' RPC call -- it requests a key from the keypool so it can report the keypoololdest time).
+ The keypool automatically adds new keys so there are always at least 100 (by default)
+ The something you did returns the key back to the keypool, so now there are 100+1

I tend to have 104 keys in my keypools, because I do a lot of 4-core CPU mining on testnet-in-a-box setups, and the 4 miner threads each grab a keypool key that is released when bitcoind quits.

RE: better backup:  good idea. However, the keypool might not survive for much longer; they're likely to be replaced by Hierarchical Deterministic Wallets (see https://en.bitcoin.it/wiki/BIP_0032 ).

Yes.
As Pieter said, they don't count towards your wallet balance because you don't have ALL of the private keys in your wallet.

It is not clear which wallet those 1-of-2 coins belong to, since neither has exclusive control over them. So the code is conservative and doesn't add them to your balance unless you have ALL of the private keys.

The 0.7 release will have a set of RPC calls to create and sign transactions that spend from multisig inputs: see https://gist.github.com/2839617

In case you don't subscribe to the bitcoin-development mailing list, we've been talking about a new BIP:

"Bitcoin blocks and transactions are versioned binary structures. Both currently use version 1. This BIP introduces an upgrade path for versioned transactions and blocks. A unique value is added to newly produced coinbase transactions, and blocks are updated to version 2."

Full BIP: https://en.bitcoin.it/wiki/BIP_0034
Mailing list discussion:  http://sourceforge.net/mailarchive/message.php?msg_id=29505990
Pull request that implements BIP 34: https://github.com/bitcoin/bitcoin/pull/1526
BIP16 "Lessons learned" : https://gist.github.com/2355445

I'd like to keep most discussion on the bitcoin-development mailing and not here on the forums, although I do plan on posting to one of the mining boards to warn solo miners and pool operators that they will eventually need to upgrade (I expect it will take at least a year and probably two or more for 95% of hashing power to upgrade, which is the proposed timeframe for full BIP 34 support).

Depending on what you're doing, you should support BIP 13: https://en.bitcoin.it/wiki/BIP_0013

Also see: https://en.bitcoin.it/wiki/Base58Check_encoding  for pseudo-code.

Pieter is exactly right. The current code is extremely conservative with multisig addresses, only counting them as yours if the wallet contains all the private keys.

Loosening that to considering them yours if you have enough keys to spend might happen, although I am worried that might cause vulnerabilities for applications that make the implicit assumption that if they have the key necessary to spend that means nobody else can possibly spend those coins after 6 confirmations. If it is a 1of2 multisig that wouldn't be true.

I think Bitcoin is already perfectly capable of scaling up.  Here's one half-baked idea for how to do it:
  http://gavintech.blogspot.com/2012/07/off-chain-transactions.html  (pasted below to save you a click):

---

The problem: is there a safe and secure way to make Bitcoin transactions without relying on the block-chain but, instead, relying on some semi-trusted third-party?

If there is, then Bitcoin is more easily scalable; most transactions could happen off the block chain, with in-the-block-chain transactions happening every once in a while to "settle up" off-chain transactions.

So here is the half-baked idea:

Use multisignature transactions to split the ownership of some bitcoin value between a customer (lets call her Alice) and a transaction service (lets call it "Joe's UltraTransactions" -- Ultra for short).

Alice deposits 100 bitcoins into her Ultra wallet, and what actually happens behind the scenes is Alice's software generates a new keypair, gets a public key from Ultra, and coins are sent into a 2-of-2 transaction.

Alice withdrawing the bitcoins (getting them out of the UltraTransaction system) is the boring case-- she'd generate a transaction, sign her half, then ask Ultra to sign the other half (and there would be some sort of authentication check-- maybe Ultra sends Alice an SMS to approve the withdrawal).

Now Alice wants to pay Bob 10BTC, who also happens to be an UltraTransaction customer. This is where things could get interesting.

Instead of generating a block-chain transaction, Alice could just give Bob her private key. Both Alice and Bob would sign a message with the private key saying "Alice is sending 10 bitcoins to Bob; she's given him the private key that she generated."  Bob would send the message to Ultra, which would send Alice an SMS to make sure she approves, and then any withdrawal involving those 10 bitcoins associated with that private key would require Bob's authorization instead of Alice's.

Alice would still know the private key, but won't be able to spend what is now Bob's money (Ultra would only let her send/withdraw 90 of the 100 bitcoin tied up with that private key).

Ultra is only semi-trusted; it never has the private key, so can't spend the coins without either Alice or Bob's aproval. Joe can't decide to run off with everybody's coins when the Ultra wallet is worth a few million dollars.

Alice and Bob do have to trust that Ultra keeps track of who owns what accurately, and that Ultra will be around to sign it's half of the transaction when they want to withdraw some coin. And Bob has to trust that Alice did generate the private key, didn't share it with Ultra, and isn't actually Joe trying to trick him.

That's quite a lot of trust required, but the ability to instantly transfer value between Ultra customers with zero Bitcoin-block-chain transaction fees might outweigh the risks. And there are probably variations on this idea that would minimize trust in Ultra (maybe there's a semi-trusted service that Ultra pays to keep offline, "use-only-if-we-go-out-of-business" backups of their private keys).

And it scales beautifully; one UltraTransaction server cluster could easily handle hundreds or thousands of transactions per second, and you could imagine companies popping up all over the world, handling most transactions outside the blockchain.

{full public key} OP_CHECKSIG is a valid, standard transaction type, redeemed by providing just {signature}.

Several people have asked me privately via email what I think of Butterfly Labs and ASIC mining in general, so:

What do I think of ASICs hitting the "mining scene" ?

meh.

It shows that Bitcoin is considered stable enough for a company to invest a LOT of money on design and production on it, which is very good. ASICs were bound to happen if Bitcoin survived long enough.

The long-term outlook for mining is "mining will happen with very specialized hardware, in places where either electricity is free or generating lots of heat is a benefit and not a cost"  (and probably both; I still think Iceland will be a big mining hot-spot eventually).

I'm not worried about Butterfly Labs deciding to take over the blockchain with their superior hashpower. They'd be idiots to do something like try to mount a 51% attack-- they don't want to kill Bitcoin, they want it to get more successful so they sell more hardware.

And if they are successful they will very quickly have competitors.

Full disclosure:  I spent some of my bitcoins to pre-order their USB coffee-warmer doo-hickey.  It gets cold here in the winter.

See "Batch Mode" in the JSON 2.0 spec: http://www.jsonrpc.org/specification

Yes, you can request information about many unrelated transactions in one call.

I first heard about Bitcoin from this article:
  http://www.infoworld.com/d/open-source/open-source-innovation-the-cutting-edge-582?page=0,2

Excellent point. I use python, which just works with different types in arrays, and C++/json_spirit, which also just works, but I can that other languages would be painful.

I'll go through the raw transactions API and will replace any "Array of different types" with "Array of Objects".

Sounds kind of like youtipit, which is shutting down:
  http://blog.youtipit.org/?p=379

More discussions in IRC today prompted further tweaks to this API:

"get any transaction, even transactions that aren't in your wallet" functionality will be moved from gettransaction to a new 'getrawtransaction' API call, for two reasons:
1. It doesn't 'feel' right to mix the high-level info with the nitty-gritty low-level detail.
2. We think there's a potential for security vulnerabilities if there are existing services that assume that 'gettransaction txid' returns an error for any transaction not in the wallet (as it does in all previous releases).

So the new plan is to put the new functionality in a new RPC call:

getrawtransaction <txid> [verbose=0]   :  If verbose=0, returns a JSON string that is the hex-encoded, serialized transaction. That is the "machine readable, as concise as possible" use case.  If verbose=1, returns a JSON object with all the nitty-gritty details, to cover all the other use cases.

Also, Jeff already has a pull request for JSON-2.0 "batch" functionality, so if you need information about all transactions in a block or all of a transaction's parent transactions you can get it with one RPC round-trip.

Rereading my original post, I should make clear: the people I really have issues with are the people who think it is more fun to try to destroy something than to help build it.  My comment about "I wish people would find more constructive things to do with their time" was not meant to be aimed not at AlternaCoin creators.

I agree that there are some benefits to the alternate chains existing; I just wonder if the costs of all the duplicate infrastructure (exchanges and pools and faucets and...) is worth the benefits.

RE: privately disclosing exploits to AlternaCoin developers: well, to be frank, I have no idea if most AlternaCoin developers can be trusted with sensitive exploit information or even who is currently supporting which chain. The danger would be somebody emailing me claiming to be the lead developer for FooCoin, I tell them about the vulnerability, and then they turn out to NOT be the lead FooCoin developer but an attacker.  Or I tell FooCoin about the vulnerability and they decide to use it to launch an attack on their arch-enemy, BarCoin.

It is all drama and heartburn that I'd really rather not have (again, costs and benefits....)

1. Make sure the SHA256SUMS.asc file hasn't been modified:

2. See what file you SHOULD have downloaded:

3. Make sure the file you downloaded is exactly the same: