1
In IsStandardTx within main.cpp, there is a comment:
// Treat non-final transactions as non-standard to prevent a specific type
// of double-spend attack, as well as DoS attacks. (if the transaction
// can't be mined, the attacker isn't expending resources broadcasting it)
// Basically we don't want to propagate transactions that can't included in
// the next block.
What are the specific type of double-spend attacks and the DoS attacks alluded to here?
3
The denial-of-service (DOS) attack is easy to explain: each time a transaction is updated by increasing the sequence number in an input, the whole transaction needs to be propagated through the network again. So if a transaction is 1 KB and there are 10,000 full nodes, you can waste a minimum of 10 MB of network bandwidth each time you update the transaction at only 1 KB bandwidth cost to you---and you can do it an essentially unlimited number of times with an essentially unlimited number of transactions, none of them costing you any money besides the transaction fee.
I'm not absolutely sure what the double spend attack referred to here is, but my guess is that it's the basic zero-conf double spend but with the network helping the fraudster: the fraudster pays you with a non-final unconfirmed transaction, being a trusting person you provide goods immediately, the fraudster broadcasts a double spend with a higher sequence number, the network mines the double spend instead of the original transaction, and you don't get paid.
It would be easy to block this type of double spend by refusing to accept into your wallet any unconfirmed transaction with a non-final sequence number, but that could lead to user confusion: "he said he paid me, and BlockChain.info says he paid me, but the transaction doesn't appear in my wallet!"
Thanks, David, you're very articulate. Couldn't the DOS attack be mitigated just by only allowing like 16 possible values for the nSequence? That way nSequence could still be useful. And the second attack makes sense, but it also seems like something that software just has to account for (don't accept a non-final transaction as payment for goods/services). Blockchain.info would only show it as unconfirmed, and that's probably what Wallet software should do too. – morsecoder – 2014-11-21T00:31:27.927
@StephenM347 Thanks. Only allowing 16 values means only 16 updates are possible, limiting the utility of the field. A main use was to be mostly-out-of-band micropayments where thousands of tiny payments would be advantageous. I agree about the second attack being not very scary, but I can't think of a scarier scenario to account for the comment you pasted. :-) – David A. Harding – 2014-11-21T00:40:04.133