Quote from: JoelKatz on June 28, 2011, 12:32:02 AM

Quote

Of course, I could still keep miner's disks pretty full if I broadcast say 1000 nLockTime transactions an hour. Basically if i want to force miners to waste 100 MB of disk space, I just have to transmit 100 MB of nLockTime transactions per day; each day when miners eliminate old cruft, they just get more from me. I get some 'friends' to do the same and now miners are wasting lots of disk space and burning lots of network bandwidth accepting these transactions.

They'll just add rules to drop those transactions. It doesn't matter if miners hold them. So long as there exists some person with a financial interest in those transactions, they'll hold them. And one person with an interest in getting them into the chain is better than 1,000 people with no such interest.

I agree with what you are saying as the ideal (and eventual) behavior of the system. But I don't know what the current state of the art is in bitcoin client and miner code. Are these systems currently vulnerable to such shenanigans? Or are protections already in place?

I have to say that my reading of the 'official' bitcoin client code revealed a very, very disturbing lack of defensive coding. Not encrypting the wallet file was an obvious and glaring omission but there are innumerable other aspects to the code that make it look much more like a prototype and much less like a client written to handle money in a trustworthy fashion.

I don't know if typical miner code is any different.