Tomorrow at 21:00 UTC on #bitcoin-dev I'd like to talk about:

Status of BIP 16 support (progress towards 50% hashing power).

Protocol change: checksum in version messages coming up Feb. 20.

Duplicate coinbase issue (and requiring block height in the coinbase as a solution).

I've got about $12 USD in my TradeHill account:  Jered, please keep it, you deserve it, I know how hard you've worked and how hard a fight it is to interface with our designed-in-the-1960's-duct-tape-and-bailing-wire rats-nest-of-regulations banking/finance system.

If you've got a great business model and funding for a much better bitcoin client, more power to you!

If you're planning on defacing one of the web servers that I haven't been keeping up-to-date (because I'm busy doing Bitcoin-related things) or hacking my gmail account to prove that I'm not The World's Best Security Expert... then I'll save you the trouble:

I am not the World's Best Security Expert.
I am not the World's Best Programmer.
I am not a cryptographer.
I am not an expert on finance or banking or monetary systems.
I am not an expert on leading open source projects.

And I hope someday I get replaced as the technical lead for this project. I'm sure there are lots of people better qualified than me, I'm just doing the best I can to try to help make Bitcoin a success.

I hope they find and prosecute the bastards; DDoSing somebody because you disagree with them is never OK.

In fact, I think there is never a situation where DDoSing is OK, even if you're trying to accomplish something good (philosophical discussions about ends justifying the means should move to off-topic...)

Don't panic.

roconnor has been experimenting with spending "duplicate coinbase transactions" on the testnet.  Block explorer is confused, and isn't seeing the 50 bitcoins generated to that address in testnet block 45,442 (because the generation transaction has the same ID as the generation transaction in block 45,333).

Expect code changes before the 0.6 release is final to discourage and eventually prohibit accepting blocks with duplicate coinbase transactions; although we can't see a way to exploit this weirdness to cheat anybody (it is easy to cheat yourself out of bitcoins using duplicate coinbase transactions that cannot be spent), it's definitely not a good thing.

You are the Quality Assurance department.  A test plan is an excellent idea, could you write one up and post it on the wiki and ask for volunteers to help test?


I don't know, the GUI for multisignature transactions hasn't been designed yet. But I imagine it will be simpler to always produce P2SH transactions, just as the client always produces OP_HASH160 transactions and has no option to produce plain OP_CHECKSIG transactions.

I assume that both forms will be supported for multisig payments into your wallet (but detailed discussion on how to support multisig in the GUI should happen somewhere other than this thread).

Yes, thanks for reminding me:  I just uploaded gitian signatures for the win32 and linux 0.6rc1 builds to:
  https://github.com/bitcoin/gitian.sigs

The win32 build was not deterministic, though.  There's a pull request to fix that.

The OSX binary is not gitian-built.

Re-posted from the bitcoin-development mailing list:


I'd like version 0.6 to get lots of review, "soak time" and testing, so
please download and run release candidate 1 from:
 http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.6.0/test/

You can review the code changes using github's compare feature:
 https://github.com/bitcoin/bitcoin/compare/v0.5.2...v0.6.0rc1

Please report bugs using the github issue tracker.


Release notes:

NEW FEATURES SINCE BITCOIN VERSION 0.5
--------------------------------------
Bitcoin-Qt can display and save QR codes for sending
and receiving addresses.

New context menu on addresses to copy/edit/delete them.

New Sign Message dialog that allows you to prove that you
own a bitcoin address by creating a digital
signature.

Wallets created with this version of bitcoin will
use 33-byte 'compressed' public keys instead of
65-byte public keys, resulting in smaller
transactions and less traffic on the bitcoin
network. The shorter keys are completely
compatible with older versions.

New command-line argument -blocknotify=<command>
that will spawn a shell process to run <command>
when a new block is accepted.

validateaddress JSON-RPC api command output includes
two new fields for addresses in the wallet:
 pubkey : hexadecimal public key
 iscompressed : true if pubkey is a short 33-byte key

New JSON-RPC api commands for dumping/importing
private keys from the wallet (dumprivkey, importprivkey).

New JSON-RPC api command for getting information about
blocks (getblock, getblockhash).

New JSON-RPC api command for getting extra information
related to mining (getmininginfo).


NOTABLE CHANGES
---------------

The -nolisten, -noupnp and -nodnsseed command-line
options were renamed to -listen, -upnp and -dnsseed,
with a default value of 1. The old names are still
supported for compatibility (so specifying -nolisten
is automatically interpreted as -listen=0; every
boolean argument can now be specified as either
-foo or -nofoo).

The -noirc command-line options was renamed to
-irc, with a default value of 0. Run -irc=1 to
get the old behavior.


PRELIMINARY SUPPORT FOR MULTISIGNATURE TRANSACTIONS
---------------------------------------------------

This release has preliminary support for multisignature
transactions-- transactions that require authorization
from more than one person or device before they
will be accepted by the bitcoin network.

Prior to this release, multisignature transactions
were considered 'non-standard' and were ignored;
with this release multisignature transactions are
considered standard and will start to be relayed
and accepted into blocks.

It is expected that future releases of Bitcoin-Qt
will support the creation of multisignature transactions,
once enough of the network has upgraded so relaying
and validating them is robust.

For this release, creation and testing of multisignature
transactions is limited to the bitcoin test network using
the "addmultisigaddress" JSON-RPC api call.

Short multisignature address support is included in this
release, as specified in BIP 16. Run with -bip16=0 to
turn off support for BIP 16.

But what if somebody hacked into your server and modified the code that decides which addresses get paid out?

If they were smart, they'd shave just a little bit from everybody's payout and insert a payout to themselves... I imagine it could take quite a while before anybody noticed.

I used my Phone-a-Friend and Ask the Audience, and I'm locking in BIP 16 as my Final Answer (follow the link if you don't get the stale pop culture reference).

Good idea. Who wants to volunteer to do the fundraising and organize this, and let me know how I can help?

No, bitcoind is solid as a rock, both with and without the BIP 16 patches applied.

RE: lightweight versus heavyweight clients:

First: lightweight clients (like Multibit) that don't store the entire blockchain must rely on the rest of the network to confirm that transactions are valid.  They can't check for themselves (this is true today, and BIP 16 doesn't change that at all).

Full clients do check, but it is still not safe for them to accept 0- or 1-confirmation transactions; an attacker might be sending them an attempted double-spend (and the network might be still be trying to figure out which 'side' of the double-spend will win).  That is also true today.

"Backwards compatibility" means that all valid transactions created by the new software will be accepted as valid transactions by the old software.

But, after BIP 16 is supported by a majority of the network, there could exist transactions that the old software considers valid but the new software rejects as invalid.

So... does BIP 16 make things riskier for people running old software?  Yes, a tiny bit, in the very particular case of 1-confirmation transactions. And that particular attack requires that the attacker manage to mine a block that they know will be found invalid (which is expensive). Again, if you get bitcoins from somebody you do not trust then you should wait until they have 3 or more (6 if you want to be extremely safe) confirmations before considering the payment final.

If you want all the technical details of why BIP 16 does NOT increase the risk for 0-confirmation transactions but does for 1-confirmation transactions... ask me another day (it has to do with how the old software recognizes "Standard" transactions and won't even show you transactions it doesn't recognize).

They just keep running the code they've been running.   It will reject the 'bad' blockchain being produced by 95% of the miners, and accept the 'good' chain being produced by the other 5%.

No, bad idea, two chains cannot peacefully coexist for more than a few dozen blocks, they would eventually make a complete mess out of users' wallets.

No, you don't have to upgrade your client to receive coins from somebody using a BIP 16 multisignature wallet.

I apologize for the shouting, it's been a hard couple of weeks.  And thanks for the support.

Very quickly, the problem with any chain split is double spends.  An attacker can spend his bitcoins twice, once using CHECKSIGEX and some script instead of a public key.  They can wait for the coins to confirm on the "new" chain, and then they can spend the coins again, using CHECKSIG, on the old chain.

The result would be massive confusion and chaos as those "old" users slowly upgraded and then found their wallets had NEGATIVE balances after the upgrade.

OK, it has been a couple of days and the general consensus seems to be a 'rolling' two-week window, with no "below 20%" rule.

I don't think there is any need for a two-week email discussion period among those familiar with the guts of Bitcoin, we've already spent months discussing the options and the consensus for BIP 16 is clear (see the tally here).

It is time to call it settled and move on to bigger and better things, like what protocol to use when a client needs to gather signatures (REST? JSON? http? https? something else?).

STOP IT.  JUST STOP IT.

BIP 16 has overwhelming support, it will be the solution.

Casascius:  please read BIP 0001 for the process to get assigned a BIP number.  The process is not "create a page on the wiki."

As for the proposal itself:  No.

You are proposing a non-backwards-compatible change, which would mean a "hard" blockchain split. Everybody agrees that is a bad idea. The confusion and potential for hacks if a significant fraction of bitcoin users were on a separate chain is massive; you gloss over all of that in your proposal.

I moved Casascius' proposal ("BIP 22") to the Dev&Tech forum, I will respond there.