Gavin Andresen



Offline



Activity: 1652

Merit: 1066





Chief Scientist







LegendaryActivity: 1652Merit: 1066Chief Scientist IMPORTANT: April 1 deadline for BIP16 support March 21, 2012, 04:29:15 PM #1



To all pool operators, solo miners and p2pool miners; I have an announcement.



As everyone well remembers, we are upgrading the block-validity rule of Bitcoin to support short multisignature addresses. We realize that upgrading the code that you've been using for a long time is at least inconvenient and, for some of you, even painful or scary. But in the case of BIP30, which went into effect with the appropriately safe network support on March 15, it was necessary and in the case of this announcement the long-term benefits will far outweigh the short-term costs of this transition.



Therefore I'd like to announce that support for BIP16 has acquired a majority of mining support needed to prevent a potential permanent fork and will be activated on April 1st as previously planned.



This chart shows support over the last week:



So if you are a pool operator, solo miner, or p2pool miner you need to upgrade your Bitcoin-Qt/bitcoind before April 1st. Running a version of bitcoind earlier than 0.6 release candidate 3 past this date means running the risk of potentially wasting your hashing power mining invalid blocks since earlier versions will accept invalid spends of BIP16 transactions into their memory pools and will put them into blocks considered invalid by the majority.



p2pool users will also need to upgrade to the latest version of p2pool.



If you are a miner connecting to a mining pool, you can ignore this message.



For non-miners: version 0.6 also contains several important bug and denial-of-service fixes, so if you can, upgrade.



Backports of the BIP16 code to earlier releases

I'm posting this to both this and the Mining Pools subforum:To all pool operators, solo miners and p2pool miners; I have an announcement.As everyone well remembers, we are upgrading the block-validity rule of Bitcoin to support short multisignature addresses. We realize that upgrading the code that you've been using for a long time is at least inconvenient and, for some of you, even painful or scary. But in the case of BIP30, which went into effect with the appropriately safe network support on March 15, it was necessary and in the case of this announcement the long-term benefits will far outweigh the short-term costs of this transition.Therefore I'd like to announce that support for BIP16 has acquired a majority of mining support needed to prevent a potential permanent fork and will be activated on April 1st as previously planned.This chart shows support over the last week: http://blockchain.info/P2SH . Support is well over 70%.So if you are a pool operator, solo miner, or p2pool miner you need to upgrade your Bitcoin-Qt/bitcoind before April 1st. Running a version of bitcoind earlier than 0.6 release candidate 3 past this date means running the risk of potentially wasting your hashing power mining invalid blocks since earlier versions will accept invalid spends of BIP16 transactions into their memory pools and will put them into blocks considered invalid by the majority.p2pool users will also need to upgrade to the latest version of p2pool.If you are a miner connecting to a mining pool, you can ignore this message.For non-miners: version 0.6 also contains several important bug and denial-of-service fixes, so if you can, upgrade.Backports of the BIP16 code to earlier releases are available if you are running a patched bitcoind. Patched binaries of older releases will be available soon. How often do you get the chance to work on a potentially world-changing project?

Gavin Andresen



Offline



Activity: 1652

Merit: 1066





Chief Scientist







LegendaryActivity: 1652Merit: 1066Chief Scientist Re: IMPORTANT: April 1 deadline for BIP16 support March 22, 2012, 03:00:10 PM #2

https://bitcointalk.org/index.php?topic=72069.0



A final 0.6 release candidate will be out very soon, the last issues are being resolved now.



Again: if you don't upgrade and are a solo miner, pool operator, or p2pool user you will almost certainly waste time hashing bad blocks after April 1.

See this thread for BIP16-compatible-backported release candidates:A final 0.6 release candidate will be out very soon, the last issues are being resolved now.Again: if you don't upgrade and are a solo miner, pool operator, or p2pool user you willafter April 1. How often do you get the chance to work on a potentially world-changing project?

kokjo



Offline



Activity: 1050

Merit: 1000



You are WRONG!







LegendaryActivity: 1050Merit: 1000You are WRONG! Re: IMPORTANT: April 1 deadline for BIP16 support March 23, 2012, 09:41:42 AM #4 you do know that that is a sucky date, to make important decisions on, right? no one will believe you, because they are expecting that you will lie. "The whole problem with the world is that fools and fanatics are always so certain of themselves and wiser people so full of doubts." -Bertrand Russell

Gavin Andresen



Offline



Activity: 1652

Merit: 1066





Chief Scientist







LegendaryActivity: 1652Merit: 1066Chief Scientist Re: IMPORTANT: April 1 deadline for BIP16 support March 23, 2012, 01:30:45 PM #6 Quote from: jetmine on March 23, 2012, 09:25:44 AM Quote from: Gavin Andresen on March 22, 2012, 03:00:10 PM Again: if you don't upgrade and are a solo miner, pool operator, or p2pool user you will almost certainly waste time hashing bad blocks after April 1.

This only applies when you include transactions generated by other people (because the old client will not be able to fully verify them).



If you think this statement is incorrect, then please elaborate (with technical details).

This only applies when you include transactions generated by other people (because the old client will not be able to fully verify them).If you think this statement is incorrect, then please elaborate (with technical details).

That statement is incorrect.



There are two ways you might waste time hashing:

1) Put a bad BIP16 transaction in your block

2) Building on top of a bad block produced by somebody else



So even if you don't include anybody else's transactions in your blocks you will still almost certainly waste some time hashing by building on top of invalid blocks produced and announced by some other lazy miner running an old version of bitcoind. That statement is incorrect.There are two ways you might waste time hashing:1) Put a bad BIP16 transaction in your block2) Building on top of a bad block produced by somebody elseSo even if you don't include anybody else's transactions in your blocks you will still almost certainly waste some time hashing by building on top of invalid blocks produced and announced by some other lazy miner running an old version of bitcoind. How often do you get the chance to work on a potentially world-changing project?

DeathAndTaxes

Legendary



Offline



Activity: 1218

Merit: 1007





Gerald Davis







DonatorLegendaryActivity: 1218Merit: 1007Gerald Davis Re: IMPORTANT: April 1 deadline for BIP16 support March 24, 2012, 12:17:16 AM #9 Quote from: RoadStress on March 23, 2012, 11:30:48 PM If he doesn't see this message can he figure out that he is wasting hash power? How?



First clue will be his wallet shows block reward and then it becomes orphaned and disapears as the longer valid chain becomes dominant. While this can happen occasionally if he is building on invalid chains it will happen at much higher frequency. I would imagine it wouldn't take more than a handful of block rewards being reversed before someone investigagtes.



Then again if you have a farm (ethical or not) which generates $1M annually wouldn't you atleast lurk this forum? First clue will be his wallet shows block reward and then it becomes orphaned and disapears as the longer valid chain becomes dominant. While this can happen occasionally if he is building on invalid chains it will happen at much higher frequency. I would imagine it wouldn't take more than a handful of block rewards being reversed before someone investigagtes.Then again if you have a farm (ethical or not) which generates $1M annually wouldn't you atleast lurk this forum?

DeathAndTaxes

Legendary



Offline



Activity: 1218

Merit: 1007





Gerald Davis







DonatorLegendaryActivity: 1218Merit: 1007Gerald Davis Re: IMPORTANT: April 1 deadline for BIP16 support April 05, 2012, 02:29:52 PM #19 Quote from: hazek on April 05, 2012, 02:19:53 PM Also wrong. The majority was only needed to avoid a permanent fork.



No that isn't true.



As long as one miner continues to mine the older version the the fork will continue to exist. There is no magical number to avoid a fork when implementing a breaking change to the protocol. A super majority of miners, developers, exchanges, and merchant helps to create a smooth transistion. If all end users see balances based on the new version then the alternate version has no real relevance.



A mere majority would be horribly chaotic and damaging to Bitcoin. A worst case scenario. One either wants the change to have overwhelming support or negligible support to ensure one chain remains dominant.



A 50/50 split would be catastrophic causing double spends across the network as the two incompatible chains switched places in height. This is why a condition for moving forward with BIP16 was 70%+ support. That ensure the minority fork would rapidly fall behind and consensus remains without dispute. No that isn't true.As long as one miner continues to mine the older version the the fork will continue to exist. There is no magical number to avoid a fork when implementing a breaking change to the protocol. A super majority of miners, developers, exchanges, and merchant helps to create a smooth transistion. If all end users see balances based on the new version then the alternate version has no real relevance.A mere majority would be horribly chaotic and damaging to Bitcoin. A worst case scenario. One either wants the change to have overwhelming support or negligible support to ensure one chain remains dominant.A 50/50 split would be catastrophic causing double spends across the network as the two incompatible chains switched places in height. This is why a condition for moving forward with BIP16 was 70%+ support. That ensure the minority fork would rapidly fall behind and consensus remains without dispute.