Would it be possible for the client to know if a miner support Bip 16 or not and only send transactions through miners who do support it? This could perhaps be a setting. Creating even more incentive for miners to uppgrade quickly.
Topic: BIP 16 is going to be much more disruptive than advertised (Read 2474 times)
I believe makomk is right here: old clients only use "only pushes" as criterion for validating an input's standardness.
Still, as soon as BIP16 is deployed with a supermajority of miners behind it, the other miners already have a large incentive to upgrade. This is one extra reason they will want to do so.
However, if switching happens at exactly 55% support, there still exists a 0.83% chance to have 6 consecutive blocks by old miners, which means a small but reasonable chance old nodes see an invalid from-BIP16 transaction with 6 confirmations. This is an extra reason for requiring significantly more than 55% support, imho.
Still, as soon as BIP16 is deployed with a supermajority of miners behind it, the other miners already have a large incentive to upgrade. This is one extra reason they will want to do so.
However, if switching happens at exactly 55% support, there still exists a 0.83% chance to have 6 consecutive blocks by old miners, which means a small but reasonable chance old nodes see an invalid from-BIP16 transaction with 6 confirmations. This is an extra reason for requiring significantly more than 55% support, imho.
Thanks.
I believe makomk is right here: old clients only use "only pushes" as criterion for validating an input's standardness.
Still, as soon as BIP16 is deployed with a supermajority of miners behind it, the other miners already have a large incentive to upgrade. This is one extra reason they will want to do so.
However, if switching happens at exactly 55% support, there still exists a 0.83% chance to have 6 consecutive blocks by old miners, which means a small but reasonable chance old nodes see an invalid from-BIP16 transaction with 6 confirmations. This is an extra reason for requiring significantly more than 55% support, imho.
Still, as soon as BIP16 is deployed with a supermajority of miners behind it, the other miners already have a large incentive to upgrade. This is one extra reason they will want to do so.
However, if switching happens at exactly 55% support, there still exists a 0.83% chance to have 6 consecutive blocks by old miners, which means a small but reasonable chance old nodes see an invalid from-BIP16 transaction with 6 confirmations. This is an extra reason for requiring significantly more than 55% support, imho.
Waiting for gmaxwell or Gavin to reply.
No way.
No way what?
But there is a bigger incentive to upgrade.
When Bip 16 works, Bitcoin will rock.
And unless you are stupid or a bank :O you want that to happen.
No way.
This is bad, but at least we still won't need a hard fork. This just means that nearly 100% of miners will need to upgrade. Once we decide to go with this, we'll need to wait a few years to enable it now, though. 
I don't think this is anything new. There are miners out there that allow any valid transaction and don't perform an isStandard check at all. This is why the process for upgrading is to first get a pledge of support from a supermajority of the mining power and once that's achieved, set a date in the future to start the full validation of BIP16 transactions. Miners will have a couple weeks to upgrade and avoid mining potentially invalid blocks.
As far as I know it's basically only luke-jr that doesn't check IsStandard, and even he's been known to forget to disable it on occasion. There is no reason to expect BIP 17 will have any such problems.
BIP 17 might be even worse actually. Obviously, correct attempts to spend BIP 17 transactions won't be included in blocks by miners like this because the spends won't pass IsStandard, but I think it should be possible to create transactions spending them that are invalid according to BIP 17 but treated as both valid and standard by non-BIP 17 miners. 
There is no reason to expect BIP 17 will have any such problems.
I don't think this is anything new. There are miners out there that allow any valid transaction and don't perform an isStandard check at all. This is why the process for upgrading is to first get a pledge of support from a supermajority of the mining power and once that's achieved, set a date in the future to start the full validation of BIP16 transactions. Miners will have a couple weeks to upgrade and avoid mining potentially invalid blocks.
One of the claims about BIP 16 - the "pay to script hash" change supported by most of the Bitcoin developers - is that it should be a reasonably non-disruptive change. In particular, it wasn't expected to affect pools and miners running unmodified Bitcoin clients too much even if they didn't upgrade. There was a small risk that they'd try and build on blocks containing an invalid attempt to spend a BIP 16 transaction, but the IsStandard check would supposedly stop them from trying to include any BIP 16 transactions they couldn't properly verify in blocks they created themselves.
This isn't true. As gmaxwell pointed out when he discovered p2pool was allowing miners to put non-standard transactions in their coinbases, IsStandard doesn't actually check that the scriptPubKey of the transaction being spent was standard at all - it only checks the scriptSigs and scriptPubKeys of the transaction being spent. This means that attempts to spend BIP16 transactions pass IsStandard in older clients and they'll include them in blocks they mine even though they can't do the extra BIP 16 verification required to do this safely. I've even tested this works using a couple of test nodes running on mainnet rules; unfortunately this can't be tested on testnet.
What does this mean? It means that once BIP 16 is switched on, anyone can send out a couple of simple transactions, the first paying money to a BIP 16 address and the second trying to spend it to a normal pubkey address in a way that pre-BIP 16 clients will accept and BIP 16 ones won't. Once they do, all the nodes that don't support BIP 16 will mine blocks that the BIP 16 nodes will treat as invalid and rewrite out of existence using their majority of hash power. Worse still, everyone running or mining on a pool that supports BIP 16 has an incentive to do this because it'll eventually push difficulty down and make them more money.
In retrospect, someone should've probably started asking questions once Gavin Andresen listed the fact that transactions spending from BIP 16 addresses would pass IsStandard and be forwarded by older nodes as an advantage over BIP 17. The rules for forwarding transactions are almost identical to the rules for including them in blocks. (BIP 17 probably has the same issue though.)
This isn't true. As gmaxwell pointed out when he discovered p2pool was allowing miners to put non-standard transactions in their coinbases, IsStandard doesn't actually check that the scriptPubKey of the transaction being spent was standard at all - it only checks the scriptSigs and scriptPubKeys of the transaction being spent. This means that attempts to spend BIP16 transactions pass IsStandard in older clients and they'll include them in blocks they mine even though they can't do the extra BIP 16 verification required to do this safely. I've even tested this works using a couple of test nodes running on mainnet rules; unfortunately this can't be tested on testnet.
What does this mean? It means that once BIP 16 is switched on, anyone can send out a couple of simple transactions, the first paying money to a BIP 16 address and the second trying to spend it to a normal pubkey address in a way that pre-BIP 16 clients will accept and BIP 16 ones won't. Once they do, all the nodes that don't support BIP 16 will mine blocks that the BIP 16 nodes will treat as invalid and rewrite out of existence using their majority of hash power. Worse still, everyone running or mining on a pool that supports BIP 16 has an incentive to do this because it'll eventually push difficulty down and make them more money.
In retrospect, someone should've probably started asking questions once Gavin Andresen listed the fact that transactions spending from BIP 16 addresses would pass IsStandard and be forwarded by older nodes as an advantage over BIP 17. The rules for forwarding transactions are almost identical to the rules for including them in blocks. (BIP 17 probably has the same issue though.)
Jump to: