You know how I say "I make mistakes, don't trust me" ...

A bug in my code is dropping transaction fees from the block reward. Simple to fix, and obvious in hindsight; I will be personally reimbursing everybody who got bit by this bug by finding the blocks affected by this, figuring out what transaction fees the creators SHOULD have received, and sending that number of bitcoins to the block-award address.

Backports and the main git HEAD tree have been patched with the fix.

---

On a higher level:

There is obviously not going to be 50+% blockchain support for BIP 16 on Tuesday; I'm going to start conversations on how to move forward.

And there has obviously not been enough testing of the BIP 16 code. Getting people to thoroughly test things BEFORE code makes it into the main tree has been a chronic problem, I'd appreciate ideas on how to avoid this kind of annoying, time-wasting "it's ready"/"oops, found a bug"/"it's fixed"/"wait, no, somebody found another bug" thing in the future. I've been unsuccessful finding the kind of QA (quality assurance) person who can both do the QA and do the fundraising necessary so they get paid.

Yes, you will confuse the GUI if you send coins to 'change' addresses.

My advice would be "don't do that."

Thanks very much for helping to test, though, it is very appreciated!

Just FYI: I contacted the top ten mining pools (as listed in the stickied threads in the Mining Pools subforum) directly via email way back in October, copied the email to them in the Mining Pools forum, and kept them 'in the loop' on all of this.

I probably should have posted all of my followup emails to them in the Mining Pools forum, also; as I said, I'm terrible at that kind of "keep track of who you've told what and make sure you've got 'buy-in' from X Y and Z" thing.

I think my only really major blunder was being too stubborn about inserting some wording into BIP 16 that Luke wanted inserted; I let my emotions cloud my judgement.

A few of the big mining pools have started supporting BIP 16, and I feel pretty confident that they've shaken out any major bugs.

If you'd like to jump on the bandwagon, backported code for BIP 16 is available at:
  https://github.com/gavinandresen/bitcoin-git/
... in the "p2sh_backport" and "p2sh_backport_vinced" branches.

Backports are available for all releases from bitcoin version 0.3.19 forward; for example if you're running code forked from the 0.3.24 release you would:


The "vinced_mergedmine" tags are for if you are using Vince's 'getauxwork' patch/branch for merged mining (based on bitcoin version 0.3.24).

If you're running latest&greatest or are willing to upgrade to the latest&greatest, BIP 16 support is already in https://github.com/bitcoin/bitcoin/


Finally, if you do decide to support BIP 16, upgrade your code, and start mining with it, let me know and I'll be happy to thank you publicly in my signature  (offer good until I run into the 300-characters-in-the-signature forum limit).

(channelling my inner CoinHunter):

It is SIMPLE ECONOMICS, people!

price = function(supply,demand)

So to create more demand, just fix the price and the supply!  Easy-peasy!

(ok, done, back to reality)

<begin troll>

No it is not!  BIP 17 is bad for the network and will give you herpes!

<end troll>

Testing is actually one of the reasons I don't like BIP 17; it is harder to test, because it is much easier to steal BIP-17 transactions if the network hasn't yet upgraded (Luke has had to test BIP 17 on the main network instead of testnet because I wrote a BIP-17-stealing robot and ran it on testnet).

I've spent the last couple of days running "transaction fuzzing" tests against both the new BIP 16 code and old clients; so far it has turned up no problems. "Fuzzing" means throwing lots and lots of random inputs at a program and making sure it deals with them properly; it is another good way of finding the "what do you know, we didn't think of that..." bugs.

The fuzzing tool is here:
  https://github.com/gavinandresen/bitcoin-git/tree/fuzzer

Also RE: ghastly exploits:

Satoshi himself made changes to the way the scripting language works after a series of 'ghastly exploits' were discovered back in 2010 after the first slashdotting. I'm so stubbornly against BIP 17 because it basically reverts one of the changes he made (separating execution of scriptSig and scriptPubKey-- take that discussion to another thread in Dev&Tech if you want to argue more about it, please).

Yes, BIPs are based on PIPs and BEPs (for Python and BitTorrent).  See BIP 0001 for the process.

We all learn from our mistakes.

Would you be willing to write an "informational BIP" describing how to do a rollout right in the future?

I'm terrible at that kind of "first we'll need to get buy-in from groups X, Y, and Z by doing A, B, and C, then each of those groups will elect representatives who will have three days to agree to a schedule, which will be announced blah blah blah blah"

LOL!  I gotta stop shaving and start working on that nifty 'stash !

I apologize for coming across as harsh, it has been a hard couple of weeks.

And the reason it has been a hard couple of weeks is because I'm working really hard to try to get support for multisignature wallets... which would have prevented your loss (assuming you were using a multisignature-protected wallet).

The hacker would have been able to ask your bitcoind to send him your coins, but you would have got a confirmation on your cell phone (or SMS or email with a one-time-PIN or whatever) and realize immediately that you'd been hacked.

Or, in other words:  I've been working really hard trying to get a solution for the bigger problem of insecure computers, because I really do care about the "flock."

I apologize-- I did not mean to attack you, I thought I stated nothing but facts. I am also sorry I didn't speak up about some of the things that were said about you earlier in this thread (e.g. suggesting an attack on your pool is NOT cool) but I don't have time to read every forum post as soon as it is posted...

Did you read BIP 16?


So there is no manipulation allowed AT ALL.


A maximum of 1,000 "naked" OP_CHECKMULTISIG operations are allowed in the scriptSigs and scriptPubKeys of transactions in any given block.

We had a block earlier this month with 1,8000 scriptSigs, so I think we are uncomfortably close to that limit.

BIP 16 "hides" the CHECKMULTISIGS in the serialized script, so more of them are allowed.


At the very least BIP 17 is harder to test-- Luke had to test on the main network because I was naughty and wrote and ran a BIP-17-transaction-stealing bot (sorry, I couldn't resist).


I have zero commercial interest; I am not being paid by anybody for anything right now.

Like this one?

Let me count the ways:

1. You must explicitly choose a username and password; you must have enough tech know-how to find your bitcoin.conf directory or run with -rpcpasswrod= options.

2. If you choose a short password, then every failed access attempt DOES trigger a timeout.

3. You must explicitly tell bitcoin to listen for connections from IP addresses other than localhost, using the rpcallowip= option.

4. You must open a hole in your firewall that lets any arbitrary IP address through to your rpcport.

I'm sorry you lost 75 bitcoins, but you really made a LOT of mistakes. Adding more layers of protection to the RPC interface isn't high on the development priority list, but if anybody wants to volunteer to keep track of number of failed RPC authentication attempts over time then be my guest and write a patch. Just be sure it isn't vulnerable to denial-of-service attacks by people deliberately generating failed login attempts.

I just had a great discussion with a developer who urged me to write a "big picture" technical post about BIP 16.  So:

First, I think a good design approach is to be clear about what you are trying to accomplish and think about what the ideal solution, if there were no constraints like backwards compatibility, would look like.

The big picture goal has always been:  short, multisignature bitcoin addresses (BIP 13).

The ideal solution would be to split scriptSig/scriptPubKey into three parts:

signatures, redemption script, and redemption script hash.

The sender would just provide the script hash, the receiver would provide the script and signatures to sign them over to somebody else.

Ideally, the redemption script hash would be include a version or 'hash type' byte, so in the future if RIPEMD160(SHA256()) was ever considered insecure a smooth upgrade could happen.

That's the ideal solution. I think all bitcoin transactions should have been done that way from the start, but it is what it is. Now we have to compromise, because one of the design constraints is backwards compatibility-- we are not going to replace scriptSig/scriptPubKey with something else and require everybody to upgrade all at once.

OP_EVAL tried to do too much, in my opinion.  It enabled all sorts of nifty things, but we made the mistake of losing sight of what we were trying to accomplish.

BIP 16, in my view, meets the goal and (importantly!) does nothing more.  I think of it as implementing the ideal three-way split in as simple and safe way as possible:

signatures:   all the items except the last pushed onto the stack by the scriptSig
redemption script:  the last item pushed onto the stack by the scriptSig
redemption script hash:  the scriptPubKey

It is pretty darn close to what I think would be the ideal solution. It even has a byte at the beginning of the redemption script hash that specifies what hash type to use (OP_HASH160) !

---

That's all why I like BIP16 better than OP_EVAL.  I've written quite a lot here on the details of why I prefer BIP 16 to BIP 17, but, fundamentally, I believe that BIP 16 is a more conservative solution that is less likely to have an "darn, I didn't see that coming" bug.

I want to try to clear up two misconceptions:

1. The original implementation of OP_EVAL was not "exploitable", but it did have bugs.  

2. The Feb. 1 deadline was explicitly designed to be a "soft" deadline; here is what BIP 16 says about it:

I believe that without a deadline nothing would get done.

We could talk and argue and discuss for six months trying to find the perfect solution, and there would still be people saying that we need another six months to argue and discuss some more.

In fact, us developers HAVE been discussing and arguing about this for over six months now; this whole thing started with an impromptu brainstorming session at the first Bitcoin Conference in New York.

As for this upgrade being "secretive" : huh? It certainly isn't/wasn't a secret among the developers, and until the developers came to rough consensus (and I believe there IS rough consensus, despite what Luke claims) I didn't think non-developers would be interested in the technical details.

From some of the reactions in this thread, I think I was right-- most people don't care whether we use nails or screws or glue to build a better wallet.

RE: rumors that I'm doing this for some personal reason:  100% untrue. I want a solution because it will make Bitcoin better sooner.

Bitcoin addresses today correspond to one public key in your wallet.

Signatures enter the picture when you spend the bitcoins sent to an address; your private key is used to generate the right digital signature, proving that you actually have that key.

BIP 16/17 will enable bitcoin addresses that are associated with more than one public key. Your wallet will know both public keys, but will only know ONE of the private keys needed to spend the bitcoins (your phone or a "wallet protection service" will keep the other private key safe).

So when sending coins, your wallet will provide one signature for the private key that it knows, the other required signature must come from whatever device is holding the other private key.

The public keys aren't just strung together in a row, but are combined using a secure hashing algorithm (the same algorithm that is used to associate public keys with the bitcoin addresses we're all using today).

I suppose I could have posted to the general Bitcoin Talk, but I didn't think that kind of low-level "plumbing" would be of general interest, any more than the average bitcoin user would care or notice a bunch of other low-level "plumbing" changes that are being made (I've got a patch pending that a certain-somebody doesn't like because it tightens up the definition of a "standard" transaction; I expect that if I pull that patch he'll start screaming that I'm wrecking future network flexibility all because I'm a big old worry-wart).

I did post to the Mining/Pools forum a couple of months ago looking for feedback because miners/pool operators are the people who are "voting" on the original proposal:
  https://bitcointalk.org/index.php?topic=50707.msg604435#msg604435