Re: (context post by lachesis)

Participants: lachesis

Quote from: gavinandresen on August 11, 2010, 04:40:07 PM

[Deleted] Quote from: davidonpda on August 11, 2010, 04:19:43 PM

Quote from: gavinandresen on August 11, 2010, 04:10:56 PM

  • require some proof-of-work as part of the client-to-client connection process (helps prevent ‘Sybil’ attacks).

Isn’t that a brilliant idea? Like hashcash?

You would be required to hash the string of the transaction, with a proof of work, that would say, take 5 seconds to calculate on a modern PC. Checking the POW just like in bitcoin would be easy and very quick for the receiving machines, but would stop a flood attack of random data without the attacker having limitless CPU power.

I was actually thinking of a minute or three of proof-of-work on initial connection, not when submitting a transaction, but requiring some proof-of-work for every transaction submitted into the network IS a very interesting idea! Should be straightforward to implement, too (add a nonce and either a full or partial hash to the transaction)…

Unfortunately, as simple to implement as it is, in order to be effective it would have to be a breaking change.

Older clients won’t send the proof of work because they don’t know to. So an attacker could just claim that their client version was, say, 308 - too old for the protection. So your node would have to choose between dropping support for older clients and being secure against this sort of attack or continuing to support older clients and being insecure against this.

I’m not saying we shouldn’t do it, but I think we ought to get a list of important breaking changes together before we make one. Users really don’t like being told that they have to upgrade every other day.

Also, I don’t know how the message relay protocol works. I guess each node could just relay that Tx with the same nonce and hash that the first one gave it. There’s no danger of “reusing” a hash since a duplicate transaction is by nature invalid (although it could still harass the nodes).

Some detection and blacklisting code would be useful too. If an IP sends you a certain number of invalid transactions within a certain time, disconnect and refuse to accept connections from them for a certain period of time. If they do it again upon reconnecting, block them for longer… etc.