1) Will the implementation break compatibility with old solo mining clients?
I assume that when someone is solo mining and producing blocks with an old client, he will just not include the new transactions but everything else works as before.
I assume that when someone is solo mining and producing blocks with an old client, he will just not include the new transactions but everything else works as before.
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...).
Quote
2) If, as a solo miner with an old client, compiled from source, wanted to vote in favor or against the P2SH, what changes exactly would I have to do to the source? ...This question is strictly about adding the vote cast, nothing else. What change(s) are necessary for that?
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.