According to Roasbeef (and confirmed by Sipa), the transaction was non-standard and required an adversarial mining pool to make it into a block.
The question is whether the mining pool was cooperating to broadcast this transaction or was running a "custom-made" client that won't do the expected checks before including it into a block (which is, in a way, questioning the point of blaming btcd).
(Nevertheless, I agree with Peter Todd position)
"however, I didn't imagine someone would work w/ miners to mine it"
Its a shame that lightning developers don't care to operate under adversarial mindsets and continue to dismiss real concerns that can lose funds. Oh well, LL will just raise hundreds of millions anyways so not their problem.
We need more "attacks" like this.
reply
It's a stretch to call the mining pool adversarial. They were simply paid to mine a valid but non-std tx that wouldn't ordinarily be relayed.
reply
Speaking of which, what's the point of having tx relay checks then? If not proactively adversarial, the mining pool operator might have been running a non-standard node. Would you be happy to provide them with your hashpower?
Plus, wasn't everyone blasting Faketoshi/Wright on Twitter for not understanding the relay consensus rules?
reply
Speaking of which, what's the point of having tx relay checks then?
It increases the cost of attacks and helps prevent honest mistakes. Motivated attackers will still find a way around. It makes sense to have them.
reply
I believe it's just weaker consensus, ie it prevents unmotivated bad behavior, but not motivated bad behavior.
What's the point of having curbs if you can just drive onto them?
reply