On Thu, Apr 18, 2013 at 10:32:24AM +0200, Mike Hearn wrote: > RE: shutting down services dependent on replacement. No, good users of > replacement would still end up taking priority over the constantly churning > DoS replacements. The most you can shut down is one contract. Obviously, if > there's no form of tx replacement at all then the "tried and doesn't work" > state is the same as "never tried", which doesn't seem like a win.
Yeah, an attack is a bit more subtle than perhaps John Dillon realizes. Assuming that nodes prioritize the transactions with the fewest total replacements first it becomes a multiplier on the standard attack of just broadcasting transactions. So for non-replacement users it's probably not that bad. An attack still shuts down useful tx replacement though. For instance in the adjusting payments example an attacker sets up a legit adjusting payment channel, does a bunch of adjustments, and then launches their attack. They broadcast enough adjustments that their adjustment session looks like part of an attack, and then don't have to pay for the full adjusted amount. What's worse, the attack itself can be just a large number of these micropayment sessions, IE, no bogus sessions at all. > The testnet is trivially DoSable today by anyone who cares to do so, there > are hardly any nodes and most people get coins from the faucet. Look at how It's *easily* DoSable, not trivially. Testnet has all the same fee/priority rules that Bitcoin has, so any attack still costs some amount of coins. For instance I did the math once on what it would cost to flood testnet with 1MB blocks, and it came out to IIRC $100/month or so in terms of lost mining revenue. Small, but still not trivial. non-final nLockTime floods and timewarp assisted can be easily done mind you, but the former is easy to fix and the latter is relatively tricky to pull off and still requires some mining expenditure. > Your proposed alternative doesn't seem any different DoS wise. Someone can > still broadcast a long series of incrementally different transactions and > have miners replace them. So you still need prioritisation of work. It's > useful anyway for other reasons. And as you point out yourself, it's still > susceptible to the problem that you end up running out of money because > it's all been spent on fees. John's proposing something that would work in conjunction with fees, so it's no different than the MIN_RELAY_FEE that has quite successfully prevented flooding on mainnet. For that matter, what he proposed can be used even with non-final == non-standard, which means the replacement transactions can't be broadcast onto the network at all until they can be mined. Actually, that's an interesting point: one way to do replacement anti-DoS would be to only allow each input a given number of chances to do a replacement. Provided your design is asymmetric in who the attacker would be, and the inputs controlled by the defender outnumber the attacker, the defender can always count on doing the last replacement. You would need some way of determining which input was responsible for a replacement though - I can't think of an obvious way to within the current transaction format, but I haven't thought hard about it yet. How exactly do you envision replacement working with non-final == non-standard anyway? > BTW $500 is rather low for the amount of work required. If you added a zero > onto that there might be more takers. If he's reasonable about the scope, IE just a initial implementation for further evaluation, I figure it's about two days work. $250/day is enough that I'd give it a go - I already looked into how to implement it anyway. -- 'peter'[:-1]@petertodd.org
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ Precog is a next-generation analytics platform capable of advanced analytics on semi-structured data. The platform includes APIs for building apps and a phenomenal toolset for data science. Developers can use our toolset for easy data analysis & visualization. Get a free account! http://www2.precog.com/precogplatform/slashdotnewsletter
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
