BIP 16 switchover date pushed to April 1

[Gavin Andresen]

Reposting from the bitcoin-development mailing list:

Mining support for BIP 16 is still under 50%, and won't possibly be over 50% by March 1.  Which means we need a new evaluation/switchover date:

Re-evaluate support: March 15'th
Target switchover: April 1

If you're already supporting BIP16, restart bitcoind with the argument:
  -paytoscripthashtime=1333238400

... to delay switchover until April 1.

Hopefully this will be the last delay; Tycho has told me that the deepbit pool will support BIP16 as soon as he's able to merge and test the changes, which will put support at well over 55%.

If you are a solo or p2pool miner you are strongly encouraged to upgrade bitcoind/Bitcoin-Qt in the next month; if you don't, you risk creating orphan blocks that the rest of the network will reject (and that risk will rapidly become greater over time as BIP16 transactions start to appear in the main block chain and get relayed across the network).

[1714805535]

1714805535

[1714805535]

1714805535

[os2sam]

... to delay switchover until April 1.

Hmm, I wonder if there is a hidden meaning in that date?
Sam

[cbeast]

... to delay switchover until April 1.

Hmm, I wonder if there is a hidden meaning in that date?
Sam

Or maybe it would be safer to push it back to the second Friday in April on the 13th. 

[jetmine]

If you are a solo or p2pool miner you are strongly encouraged to upgrade bitcoind/Bitcoin-Qt in the next month; if you don't, you risk creating orphan blocks that the rest of the network will reject (and that risk will rapidly become greater over time as BIP16 transactions start to appear in the main block chain and get relayed across the network).

I have asked about this specifically, and your answer was: Old solo mining clients will produce perfectly valid blocks (*)

Now you are saying the opposite.  Was your answer wrong?

Or are you now trying to "encourage" solo miners to update without factual need (ie. FUD)?

Please clarify, and may protocol changes be delayed at least until the community can understand the implications.  Not everyone dedicates full-time to bitcoin, yet may be affected.

(*) see: https://bitcointalk.org/index.php?topic=60950.msg711055#msg711055

[eleuthria]

If you are a solo or p2pool miner you are strongly encouraged to upgrade bitcoind/Bitcoin-Qt in the next month; if you don't, you risk creating orphan blocks that the rest of the network will reject (and that risk will rapidly become greater over time as BIP16 transactions start to appear in the main block chain and get relayed across the network).

I have asked about this specifically, and your answer was: Old solo mining clients will produce perfectly valid blocks (*)

Now you are saying the opposite.  Was your answer wrong?

Or are you now trying to "encourage" solo miners to update without factual need (ie. FUD)?

Please clarify, and may protocol changes be delayed at least until the community can understand the implications.  Not everyone dedicates full-time to bitcoin, yet may be affected.

(*) see: https://bitcointalk.org/index.php?topic=60950.msg711055#msg711055

The problem [as I understand it] is if somebody purposely creates a transaction that is valid under the old rules, invalid under the new ones.  If an old client creates a block with that transaction, the majority of the network will not acknowledge it because of the invalid transaction, so eventually the network will orphan that block with one that does not contain the invalid transaction.

It's not so much a chain-fork where we end up with two separate chains, but if somebody was determined to hurt old miners, they could create this temporary chain split by making a transaction like that.  Old miners would then be working on a chain that will eventually be orphaned once the majority of the network has created a longer chain.

EDIT:  If I'm wrong with the above, please delete this comment!  But the above is my understanding based on the lengthy BIP16/17 threads, but something may have been stated by someone in those threads that was later determined to be inaccurate.

[Gavin Andresen]

eleuthria is right.

The bad-for-not-upgraded-miners scenario is:

+ Somebody gets a valid BIP16 transaction into the chain.

+ They then spend that transaction by broadcasting a 'standard', non-BIP16 transaction, BUT they create a signature for the BIP16 part that old miners consider valid, new miners consider invalid.

+ The old miners will add that 'poisonous' transaction to their memory pool and if they include it in the blocks they mine then those blocks will be rejected by most of the network.

makomk pointed out a while ago that I hadn't noticed that old miners will accept spends of half-valid BIP16 transactions, because the old code doesn't check to see if a transaction is spending a non-standard input. He's right; one of the changes in the 0.6 release is an AreInputsStandard() method, to make upgrading smoother next time.

Executive summary:  if you are a p2pool or solo miner you should upgrade before the switchover date (April 1, if all goes well)  or there is a good chance you'll produce nothing but orphan blocks.  I welcome suggestions on how to effectively get that message out to the community.

[cbeast]

I wouldn't worry about getting the word out to the community. The lack of enthusiasm about upgrading to BIP 16 after it has been agreed upon may cause a lack of confidence in the Bitcoin community. Progress is vital to the survival of Bitcoin. At the risk of speculating, I think if the price drops enough, then the risk to upgrade will be mitigated. If the new client is nearly ready for release as well, you might prepare a press release to time them together.

[Technomage]

This is really good news! It's about time we get P2SH into the protocol.

The other good thing is that there is plenty of time for miners to wake up and upgrade. In best case the switch happens the first of April so there is no hurry.

[DeepBit]

Why the percentage of BIP16-supporters stopped growing ?

[jetmine]

makomk pointed out a while ago that I hadn't noticed that old miners will accept spends of half-valid BIP16 transactions, because the old code doesn't check to see if a transaction is spending a non-standard input. He's right; one of the changes in the 0.6 release is an AreInputsStandard() method, to make upgrading smoother next time.

Let me summarize:

• In the last ~4 weeks you learned that the change (that was scheduled for tomorrow) will open up older clients to a major security hole (DoS).
  
  
• Instead of modifying or dropping the change, somebody decided that it should still be deployed as is.
  
  
• The community has not been informed about this problem.  The information didn't get to me for example, although I specifically asked for it.  Nobody bothered to update my thread.  I had to ask again and nail you down to get this piece of information.
  

Don't you think that more time is needed, for the community to adjust to the upcoming changes, to come up with better variants (that have less sideeffects), and to further analyse the security implications?  If such a big problem was identified just a few days ago, what else could surface tomorrow?

Also keep in mind, that on some systems it is very difficult to compile the latest client. It's easier to modify the old client to not process any transactions. This might not be good for the community, but it successfully dodges the threat created by the change.  Not processing transactions can be considered a "hot fix" for old clients.

[Technomage]

Why the percentage of BIP16-supporters stopped growing ?

That was to be expected honestly. The mining community has only so many miners and pool owners who care for Bitcoin itself at all. It doesn't matter if it's BIP 16 or BIP 139, or what they do, a certain percentage of miners simply do not care. I'm personally very happy that there is 36% support now, which amounts to over 55% with Deepbit excluded. With Deepbit adding support the total support would be around 70% percent.

I really don't think that there are many pools or miners left who care one way or another, one of the exceptions is Eligius. That pool is actually voting against P2SH because of silly implementational debates. From all of this I've come to the conclusion that this issue is one of the biggest problems for Bitcoin. If another large change is required in the future, I'm not at all certain if it can be done. This will leave Bitcoin vulnerable to competition from newer cryptocurrencies that have no such problem.

Then again I feel that this process of basically "forced upgrade" will wake up many miners. They need to fucking wake up because we're part of a technology in development, not something that will just stay the way it is for forever and ever. People who want it to stay like this forever have no clue about anything.

One future issue I think could require big upgrades is the scalability of Bitcoin and I think this whole P2SH issue could work as something that prepares people for that. Regardless, it's really important for Bitcoin that P2SH is implemented smoothly and securely, further issues with getting miner support would be catastrophic, I for one would be very skeptical of the possibilities of any bigger developments in the future.

This is not even about the users, it's about the backbone of the whole network. It's an added feature, users do not need to upgrade and they can continue to use Bitcoin as they do now, if they wish. Miners need to get used to the fact that they might need to upgrade from time to time.

[Technomage]

Let me summarize:

• In the last ~4 weeks you learned that the change (that was scheduled for tomorrow) will open up older clients to a major security hole (DoS).
  
  
• Instead of modifying or dropping the change, somebody decided that it should still be deployed as is.
  
  
• The community has not been informed about this problem.  The information didn't get to me for example, although I specifically asked for it.  Nobody bothered to update my thread.  I had to ask again and nail you down to get this piece of information.
  

Don't you think that more time is needed, for the community to adjust to the upcoming changes, to come up with better variants (that have less sideeffects), and to further analyse the security implications?  If such a big problem was identified just a few days ago, what else could surface tomorrow?

Also keep in mind, that on some systems it is very difficult to compile the latest client. It's easier to modify the old client to not process any transactions. This might not be good for the community, but it successfully dodges the threat created by the change.  Not processing transactions can be considered a "hot fix" for old clients.

Let me summarize for you:

The issue that was found was NOT a big problem. Backwards compatability for miners was never a requirement for P2SH. Regular users do not need to upgrade but miners do, that is not a problem. Miners need to get used to the fact they might need to upgrade from time to time. Even users do but for them it should be different, slower. For example the 3.x Bitcoin clients don't work anymore. I expect that the 4.x clients will work for a while yet.

There is plenty of time for miners to upgrade, in best case there is still over a month to the switchover date. This is a good amount of time to do more testing with BIP 16 as well.

[memvola]

They need to fucking wake up because we're part of a technology in development, not something that will just stay the way it is for forever and ever.

I know of a few solo/p2p miners whom I think I need to wake up, but it doesn't seem very straightforward to do so switch. Does the main branch now support BIP 16?

[os2sam]

If another large change is required in the future, I'm not at all certain if it can be done. This will leave Bitcoin vulnerable to competition from newer cryptocurrencies that have no such problem.

When a change is *required* I'm sure the Bitcoin community will be behind it.  I'm also sure there will probably be allot of debate on how to implement a required change as well, but that is a good thing.
Sam

[gmaxwell]

Let me summarize:

Your summary is not very accurate or useful.

The information didn't get to me for example, although I specifically asked for it.  Nobody bothered to update my thread.  I had to ask again and nail you down to get this piece of information.

None of the development is going on in secret. The discussions are out in the public and are fairly transparent. If you don't have the time to follow and understand all of it, then thats a tradeoff you're choosing to make.  If there are reasonable ways to improve the transparency then I'm sure offers to help improve communications would be appreciated by all.

Or what do you expect? Certified mail on every commit?  You don't get to demand personal service.

(and frankly— a bit of unsolicited advice: the screeching bold faced text from an account with 25 posts just screams sockpuppet/troll — you might want to consider moderating your tone before you get written off as someone who's just trying to create controversy for fun)

[finway]

Hope this time we'll get through.

[Glasswalker]

Executive summary:  if you are a p2pool or solo miner you should upgrade before the switchover date (April 1, if all goes well)  or there is a good chance you'll produce nothing but orphan blocks.  I welcome suggestions on how to effectively get that message out to the community.

Quick clarification on this, Solo miners need only upgrade the bitcoin client they are mining through in order to ensure generated blocks are "clean".

But, with P2Pool, because it's peer to peer. Would not EVERY P2Pool miner need to upgrade their clients or else the entire pool could be affected? (example being I'm mining against P2Pool, I'm using an updated client, but joebob is also mining on P2Pool with an old client. If his client happens to be the one that finds the block, even though I've contributed shares towards said block, and he includes the invalid tx, the whole block, and all contributing miners to that block get screwed correct?)

If this is the case, that's a pretty big problem for P2Pool miners. Because there is no way for us to know if the rest of the pool is updated. (and it essentially opens up P2Pool to a DOS attack vector. Anyone looking to take down P2Pool can join up with bogus clients and mine to start injecting bad blocks into the mining results for the whole pool... Sure it would only be proportional to the mining power brought to the table by the "attacker" relative to the rest of P2Pool, but it's still an attack vector).

Also what classifies as "upgraded". (ie: I'm running the latest official client from bitcoin.org, but not a dev branch. Do I need a dev branch? if so which version specifically)

Thanks!

[memvola]

Also what classifies as "upgraded". (ie: I'm running the latest official client from bitcoin.org, but not a dev branch. Do I need a dev branch? if so which version specifically)

The main development branch (0.6.0-beta) supports the -bip16 parameter and as far as I could detect has the necessary code.

[os2sam]

Executive summary:  if you are a p2pool or solo miner you should upgrade before the switchover date (April 1, if all goes well)  or there is a good chance you'll produce nothing but orphan blocks.  I welcome suggestions on how to effectively get that message out to the community.

Quick clarification on this, Solo miners need only upgrade the bitcoin client they are mining through in order to ensure generated blocks are "clean".

But, with P2Pool, because it's peer to peer. Would not EVERY P2Pool miner need to upgrade their clients or else the entire pool could be affected? (example being I'm mining against P2Pool, I'm using an updated client, but joebob is also mining on P2Pool with an old client. If his client happens to be the one that finds the block, even though I've contributed shares towards said block, and he includes the invalid tx, the whole block, and all contributing miners to that block get screwed correct?)

If this is the case, that's a pretty big problem for P2Pool miners. Because there is no way for us to know if the rest of the pool is updated. (and it essentially opens up P2Pool to a DOS attack vector. Anyone looking to take down P2Pool can join up with bogus clients and mine to start injecting bad blocks into the mining results for the whole pool... Sure it would only be proportional to the mining power brought to the table by the "attacker" relative to the rest of P2Pool, but it's still an attack vector).

Also what classifies as "upgraded". (ie: I'm running the latest official client from bitcoin.org, but not a dev branch. Do I need a dev branch? if so which version specifically)

Thanks!

Well, I'm assuming the non-upgraded miner's shares would not be valid to the rest of P2Pool if they are not valid as a block, so they would effectively be harming only themselves. Valid shares will be paid for and potentially be a block on the Bitcoin network. Non-valid shares will not be paid for and will not be a block on the Bitcoin network. So, legitimate P2Pool miners will not be affected in the slightest.

But don't take my word for it, find someone with actual technical knowledge on the subject. I'm sure someone will see this thread eventually, but if you want a quick answer, ask it in the P2Pool thread.

If you do as Doc suggests please post the answer back here too.
Thanks,
Sam

[Glasswalker]

Response from forrestv at: https://bitcointalk.org/index.php?topic=18313.0

Since P2Pool is Peer to Peer, if say half the miners have updated clients, and half are using older clients. I assume that the client who ultimately finds the block is the one that submits it to the network and handles validation of transactions? If so, 50% of the time would we be vulnerable to this flaw with BIP16?

In other words, do we require 100% of P2Pool users to upgrade their bitcoin clients to be BIP16 compliant to totally avoid this issue?

And if the answer to the above is yes, that's a huge vulnerability for P2Pool (because someone could maliciously join the pool and mine using an old client, to invalidate a percentage of blocks mined by the miners on P2Pool).

All P2Pool users will definitely need to upgrade bitcoind before April 1st because of this issue. The question is of how to prevent people from not upgrading, which can be done by changing the rules of the P2Pool protocol.

This could be as simple as a new version of P2Pool that checks bitcoind's version and refuses to work with older versions, combined with a protocol change on April 1st that requires miners to use the new client. Of course, this is vulnerable to people patching out the version check, but P2Pool (along with all other pools) is already vulnerable to malicious block invalidating attacks, so that's not a problem.