I've been very clear about my top development priorities:

1. Network stability: DoS threats, scaling-up issues, etc.
2. Wallet security/backup.

I see everything else as lower priority; I want users to be confident that their bitcoins can't get stolen even if they slip up and open an attachment in Outlook that the aughtn't have opened before I want a downloads-the-entire-blockchain-in-10-seconds client with all sorts of other bells and whistles.

Huh?  GIT HEAD bitcoind supports import private key functionality:

Whether or not that's ever supported by the GUI is a different issue, and there I think we SHOULD be more concerned about people using the GUI shooting themselves in their feet.

No, it really isn't.

Here's a possible future implementation of IsStandard():


I like the idea of a future IsStandard() that allows more transaction types, but only if they're under some (sane) resource limits.

That's non-trivial to implement; it seems to me that a conscious decision by the miners/pools to support or not support is less work and safer.

Luke proposed something similar earlier, though; I'm surprised his patches don't implement it.

I like whoever proposed that the string in the coinbase refer to the BIP, in the future that's the way it should be done.


RE: schedules:

Deadlines, as we've just seen, have a way of focusing attention.  OP_EVAL got, essentially, zero review/testing (aside from my own) until a month before the deadline.

It seems to me one-to-two months is about the right amount of time to get thorough review and testing of this type of backwards-compatible change. Longer deadlines just mean people get busy working on other things and ignore the issue.

So I'm trying to figure out why I'm so annoyed at I'm-sure-you-can-guess-who.

And I think I've figured it out-- I think it is because I feel like I bend over backwards to be completely honest and open about potential flaws or problems with my ideas, and I'm completely honest and open about the fact that I'm human and I make mistakes.

And it seems like that's being leveraged to create fear, uncertainty and doubt. I say something like "there is a small risk that...", but I NEVER EVER hear even a hint that the "other side's" proposal might be anything but perfect.

Maybe I'm just too naive, and aught to get with the program and say that everything I do comes perfect, straight from God. People do tend to suffer from The Wise Leader Fallacy; maybe I should stop fighting against human nature and be more of a politician.

Ok, enough venting.

Yes.

I'd love so see a bitcoin client with p2pool-technology built in; bring back the "generate coins" option!

But... that will take a while. If I was a pool operator, though, I'd be thinking about other bitcoin-related businesses where I could use my expertise (the pool operators deserve a lot of credit, they've had to deal with DOS attacks, keeping their wallets safe, servicing hundreds or thousands of customers banging on their servers constantly, etc).

Yes. Old solo mining clients will produce perfectly valid blocks, unless they've been hacked to mine "non-standard" transactions.

There is a small risk that somebody ELSE will produce an invalid block, old solo mining clients will think it is valid, and will try to mine on top of it.  But that's a small risk because we'll wait until a super-majority of the network supports p2sh before starting to reject any p2sh transactions.

So worst case scenario would be:

+ Somebody with a hacked bitcoind mines a block containing a valid-under-old-rules, invalid-under-new p2sh transaction.
+ Old miners try to build on it, but the majority of the network rejects it (there's a short block-chain split).

If an attacker could target just the p2sh-supporting nodes and denial-of-service enough of them to get p2sh support below 50%, then there could be a longer block-chain split. If you do the math, that's not as easy as it sounds (if p2sh support is at 80%, you'd have to knock out 60% of the supporting nodes-- 20% of the original network would support, 20% wouldn't...).


Don't do that, please. "Voting" with your coinbase should mean you actually do the extra validation required by p2sh, otherwise you're saying you support a feature when you really don't.

I try not to respond to trolls, but....

Quit spreading FUD. If you think BIP 16 is terrible, please give a rational reason, beyond "It is a special case," which I have repeatedly responded to.

BIP 16 explicitly states:
"Validation fails if there are any operations other than "push data" operations in the scriptSig."

Let me try again for why I think it is a bad idea to put anything besides "push data" in the scriptSig:

Bitcoin version 0.1 evaluated transactions by doing this:


That turned out to be a bad idea, because one person controls what is in the scriptPubKey and another the scriptSig.

Part of the fix was to change evaluation to:


That gives a potential attacker much less ability to leverage some bug or flaw in the scripting system.

Little known fact of bitcoin as it exists right now: you can insert extra "push data" opcodes at the beginning of the scriptsigs of transactions that don't belong to you, relay them, and the modified transaction (with a different transaction id!) may be mined.


Are you volunteering to make that happen? After working really hard for over four months now to get a backwards-compatible change done I'm not about to suggest an "entire network must upgrade" change...

By the way... if there is no fully-functional reference implementation yet, you really shouldn't be putting "CHV" in your coinbases yet. The string in the coinbase really aught to mean "this code is all ready to support this feature,"  because full support from a majority of hashing power is what we want to measure.


Imagine you're an early adopter.  You ask people to send you money into your spiffy new ultra-secure wallet.

With BIP 16, transactions TO you will take longer to get into a block because not everybody is supporting the new feature.

But transactions FROM you will look like regular transactions, so the people you are paying won't have to wait.

That is not a big difference, but it is an advantage of the BIP 16 approach.


No, they are not evaluated in the same way.  The bit of code in bitcoin transaction validation that makes me nervous is:
... in SignatureHash(), which is called from the CHECKSIG opcodes.  scriptCode is the scriptPubKey from the previous (funding) transaction, txTmp is the transaction being funded.

This is the "Copy the scriptPubKey into the scriptSig before computing the hash that is signed" part of what OP_CHECKSIG does.

I like BIP 16 better than OP_EVAL/BIP 17 because BIP 16 does two complete validations, once with the scriptPubKey set to HASH160 <hash> OP_EQUAL and then once again with the scriptPubKey set to (for example) <pubkey> OP_CHECKSIG.

BIP 16 essentially says "If we see a P2SH transaction, validate it, then treat it is a normal, standard transaction and validate it again."

BIP 17 will run OP_CHECKSIGs when it is executing the scriptSig part of the transaction, which is a completely different context from where they are executed for the standard transactions we have now.

Again, I can't see a way to exploit that but it makes me very nervous.

If you don't want to change you can just ignore the new feature(s). There is zero risk with the proposed changes for anybody running old, un-hacked versions of bitcoin.

(if you are solo mining and hacked your version of bitcoin to accept 'non-standard' transactions then you could shoot yourself in your foot, but even that is unlikely).

Nobody has written a Korean translation.  If/when somebody does (join https://www.transifex.net/projects/p/bitcoin/ if you want to help) you'd get the Korean translation.

An option to change the language in the GUI is a great idea.  Somebody should do that....

We need more Windows developers, by the way; if you know a lot about developing in C++ on Windows and want to (for example) create a Visual Studio project or resurrect makefile.vc or fix the build instructions if they're not right that'd be spiffy.

I haven't seen discussion of BIP 17 anywhere besides IRC, so I thought I'd start one.

I'll start by saying that I'm trying hard to put aside my biases and dispassionately evaluating the proposal on its merits (I'll just say that I'm not happy with the way BIP 17 came to be, but it is what it is).

Quick executive summary of BIP 17:

A new opcode is proposed, OP_CODEHASHVERIFY, that replaces OP_NOP2.

It is used in a new "standard" scriptPubKey that looks like:


... which is redeemed using a scriptSig like (for example, a 2-of-2 CHECKMULTISIG):



OP_CODEHASHVERIFY is defined to take the hash of everything in the scriptSig from the last OP_CODESEPARATOR and compare it to the top item on the stack. If the hashes match, then it is a no-op, otherwise script validation fails. (see the spec for all the details for what happens if there is no CODESEPARATOR or a CODEHASHVERIFY is put in the scriptSig)


BIP 17 is an alternative to BIP 16, which has a scriptPubKey:


... which is redeemed with:



I see the appeal of BIP 17 -- the redeeming opcodes aren't "hidden" as serialized bytes, they're right there in the scriptSig. That feels less like a hack.

However, there are a couple of practical reasons I like BIP 16 better:

• Old clients and miners count each OP_CHECKMULTISIG in a scriptSig or scriptPubKey as 20 "signature operations (sigops)."  And there is a maximum of 20,000 sigops per block.  That means a maximum of 1,000 BIP-17-style multisig inputs per block.  BIP 16 "hides" the CHECKMULTISIGs from old clients, and (for example) counts a 2-of-2 CHECKMULTISIG as 2 sigops instead of 20. Increasing the MAX_SIGOPS limit would require a 'hard' blockchain split; BIP 16 gives 5-10 times more room for transaction growth than BIP 17 before bumping into block limits.
• With BIP 17, both transaction outputs and inputs fail the old IsStandard() check, so old clients and miners will refuse to relay or mine both transactions that send coins into a multisignature transaction and transactions that spend multisignature transactions.  BIP 16 scriptSigs look like standard scriptSigs to old clients and miners. The practical effect is as long as less than 100% of the network is upgraded it will take longer for BIP 17 transactions to get confirmed compared to BIP 16 transactions.
• Old clients and miners will immediately accept ANY scriptSig for BIP 17 transactions as valid. That makes me nervous; if anybody messes up and sends coins into a BIP 17 transaction before 50% of hashing power supports it anybody can claim that output. An advantage of BIP 16 is the "half-validation" of transactions; old clients and miners will check the hash in the scriptPubKey.

I also have some theoretical, "just makes me feel uncomfortable" reasons for disliking BIP 17:

• OP_CHECKSIG feels like it was originally designed to be in the scriptPubKey-- "scriptSig is for signatures." Although I can't see any way to exploit an OP_CHECKSIG that appears in the scriptSig instead of the scriptPubKey, I'm much less confident that I might have missed something.  I'm much more confident that BIP 16 will do exactly what I think it will (because it is much more constrained, and executes the CHECKSIG exactly as if it appeared directly in the scriptPubKey).
• Changing from the scriptSig being just "push data onto the stack" to "do the bulk of verification" also makes me nervous, especially since nodes that relay transactions can add whatever they like to the beginning of the scriptSig before relaying the transaction. Again, I can't think of any way of leveraging that into an exploit, but the added complexity of code in the scriptSig and requiring OP_CODESEPARATORs in the right place makes me nervous.
• I've never liked OP_CODESEPARATOR-- it is not like the other opcodes, the way it isn't affected at all by OP_IF and the way it 'steps out' and causes the raw bytes of the transaction to be hashed.  Nobody has been able to figure out how to use it, and the best guess is it is like your appendix:  maybe useful in the past, but not useful now.  Safer to get rid of it entirely, in my opinion.

Once transactions are validated and buried "deep enough" in the blockchain you can forget their inputs, because the inputs are only needed for validation.

... although SOMEBODY on the network should remember them, in case I-don't-trust-anybody nodes want to validate the entire blockchain.

Good idea. Somebody should do that.

Just the bitcoind node.

Yes, the next step is to get miners and clients to recognize a new 'standard' transaction type that does multisig.  BIP 11 describes them, they're already supported in git HEAD and by the p2sh code, and old miners and clients will recognize and validate blocks that contain OP_CHECKMULTISIG transactions.

I did some work today that should be useful to stress-test transaction handling for alternative bitcoin implementations:
  https://github.com/gavinandresen/bitcoin-git/tree/fuzzer

From its README.md:

Hacked version of Bitcoin that adds a "relayfuzzed" command. Note: this only works on the testnet.

USING THIS CODE

First, create one or more transactions using the send* RPC commands, and remember their transaction IDs. This version of bitcoin is modified so 'original' wallet transactions are not announced to the network.

Then, you can generate as many "fuzzed" variations as you like using the relayfuzzed command, which takes a transaction ID and an integer to seed a random number generator.

Example usage from a bash prompt:

The result should be a long list of fuzzed transaction ids, almost all of which are actually bad, invalid transactions. And a lot of "ConnectInputs failed" in testnet-box/2/testnet/debug.log

THINGS TO BE AWARE OF

You will trigger the denial-of-service-prevention code using this. If you are running a "testnet-in-a-box" setup (see https://sourceforge.net/projects/bitcoin/files/Bitcoin/testnet-in-a-box/) then you don't have to worry, nodes running on localhost don't disconnect each other for bad behavior. Otherwise, you can run bitcoind with -banscore=999999 to avoid being disconnected.

Running the code being tested under Valgrind or Purify or another memory-corruption detection tool is a good idea.

Types of "high-level" fuzzing done:

Insert random opcodes at the front of the transactions's scriptSig(s)

Types of "low-level" fuzzing done:

Change bit in one of the transaction's bytes
Delete one or more bytes
Insert one or more random bytes

TODO:

Generate mostly-random scriptSig/scriptPubkey pairs that validate, and generate pairs/chains of valid transactions that spend them.

So what happens if I put two OP_P2SH's in a scriptPubKey?  What happens if I put one in a scriptSig? What if I put it inside an OP_IF ... OP_ENDIF ?

I think you're really just suggesting that the "magic" scriptPubKey be 24 bytes big instead of 23, and start with one of the NOP opcodes-- yes? In which case there is going to be a special case code path anyway.