I should note that my proposal does require a change to the consensus rules...but getting bitcoin to scale will require this no matter what. - Eric Lombrozo On Feb 22, 2015 3:41 AM, "Eric Lombrozo" wrote: > It seems to me we're confusing two completely different motivations for > double-spending. One is the ability to replace a fee, the other is the > ability to replace outputs. > > If the double-spend were to merely add or remove inputs (but keep at least > one input in common, of course), it seems fairly safe to assume it's the > former, a genuine fee replacement. Even allowing for things like coinjoin, > none of the payees would really care either way. > > Conversely, if at least one of the inputs were kept but none of the > outputs were, we can be confident it's the the latter. > > It is possible to build a wallet that always does the former when doing > fee replacement by using another transaction to create an output with > exactly the additional desired fee. > > If we can clearly distinguish these two cases then the fee replacement > case can be handled by relaying both and letting miners pick one or the > other while the output replacement case could be handled by rewarding > everything to a miner (essentially all outputs are voided...made > unredeemable...and all inputs are added to coinbase) if the miner includes > the two conflicting transactions in the same block. > > Wouldn't this essentially solve the problem? > > - Eric Lombrozo > On Feb 21, 2015 8:09 PM, "Jeff Garzik" wrote: > >> On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón wrote: >> > On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik >> wrote: >> >> This isn't some theoretical exercise. Like it or not many use >> >> insecure 0-conf transactions for rapid payments. Deploying something >> >> that makes 0-conf transactions unusable would have a wide, negative >> >> impact on present day bitcoin payments, thus "scorched earth" >> >> > And maybe by maintaining first seen policies we're harming the system >> > in the long term by encouraging people to widely deploy systems based >> > on extremely weak assumptions. >> >> Lacking a coded, reviewed alternative, that's only a platitude. >> Widely used 0-conf payments are where we're at today. Simply ceasing >> the "maintaining [of] first seen policies" alone is simply not a >> realistic option. The negative impact to today's userbase would be >> huge. >> >> Instant payments need a security upgrade, yes. >> >> -- >> Jeff Garzik >> Bitcoin core developer and open source evangelist >> BitPay, Inc. https://bitpay.com/ >> >> >> ------------------------------------------------------------------------------ >> 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 >> >