Now that #241 is fixed, we can move onto SegWit. AFAICT from looking at BIP-141, there are only a couple edge cases that look interesting to me (and I suspect that they're both already handled correctly since it seems hard to screw them up, but best to verify that).

1. Verify that witness validation is enforced (after the softfork activation timestamp) for scriptPubKeys that consist of a name prefix, followed by the standard SegWit syntax of OP_0 (20-byte P2WPKH witness program). (Basically this is just to make sure that the name prefix doesn't interfere with identifying a scriptPubKey as a SegWit scriptPubKey.)
2. Verify that a name prefix whose beginning looks like a SegWit scriptPubKey (e.g. OP_3 (32-byte name) ...) doesn't get detected as a SegWit scriptPubKey. AFAICT the fact that there are additional OP_PUSHDATA / OP_DROP / OP_2DROP opcodes after the first 2 pushes should prevent them from ever being detected as SegWit scriptPubKeys (and if that's not the case, then I suspect Bitcoin would be broken), but it would be useful to verify this. Note that witness versions 1 through 3 (which correspond to the 3 name opcodes) are currently defined as "anyone can spend", so it may be a bit tricky to check whether they're being detected as SegWit scriptPubKeys... I assume there's a function for checking whether a scriptPubKey is SegWit (irrespective of what the witness version is), but I don't know if it's publicly exposed to tests.

Refs #239 . Once this is resolved, I think the only thing left on my agenda before ACKing everything for the softfork is figuring out the weight limit.