On Sun, Feb 22, 2015 at 08:36:01AM -0800, Tom Harding wrote: > On 2/11/2015 10:47 PM, Peter Todd wrote: > >My replace-by-fee patch is now available for the v0.10.0rc4 release: > > > > https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.0rc4 > > > > This patch immediately simplifies successful double-spends of > unconfirmed transactions. But the idea that it "gives a path to > making zeroconf transactions economically secure" is quite dubious. > > * You don't provide sufficient means to detect and relay > double-spends, which is necessary to trigger a scorched-earth > reaction. Not all double-spends will conform to your replacement > rules.
No, OTOH if they don't then the situation is no difference from what we have now, and replace-by-fee does no harm. Meanwhile, relaying of bare double-spend signatures can be implemented in the future, as I suggested last year for your/Andresen's double-spend relaying patch. Did you notice the even more obvious way to defeat ANYONECANPAY scorched earth with that patch? > * Maybe XT nodes would help to overcome this. But meanwhile, in > the ANYONECANPAY design, Bob's replacement is a triple-spend. Even > XT nodes won't relay it. So? RBF nodes will. > * It's unclear when, if ever, any senders/receivers will actually > try to use scorched-earth as a double-spend deterrent. I suspect many won't, because few people need to rely on unconfirmed transactions anyway. > Also, this patch significantly weakens DoS protections: > > * It removes the early conflict check, making all conflict > processing more expensive If you're going to consider replacement, conflict processing will definitely be more expensive. :) An actual DoS attacker would do their DoS attack in a way where conflict processing has nothing to do with it, so this change does no actual harm. > * There is no attempt to protect against the same transaction > being continually replaced with the fee bumped by a minimal amount. What exact git commit were you looking at? I did have an early one that did have a bug along those lines, now fixed. The current version ensures every replacement pays at least as much additional fees as would normally cost to broadcast that much data on the network, and additionally requires the fees/KB to always increase; under all circumstances it should be no more of a DoS threat than low-fee transactions are otherwise. I'd like to know if there is a flaw in that code however! -- 'peter'[:-1]@petertodd.org 000000000000000017c2f346f81e93956c538531682f5af3a95f9c94cb7a84e8
signature.asc
Description: Digital signature
------------------------------------------------------------------------------ Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration & more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
