Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YPVIj-0004in-Pg for bitcoin-development@lists.sourceforge.net; Sun, 22 Feb 2015 12:06:22 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.217.177 as permitted sender) client-ip=209.85.217.177; envelope-from=elombrozo@gmail.com; helo=mail-lb0-f177.google.com; Received: from mail-lb0-f177.google.com ([209.85.217.177]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YPVIi-0002h6-B9 for bitcoin-development@lists.sourceforge.net; Sun, 22 Feb 2015 12:06:21 +0000 Received: by lbvp9 with SMTP id p9so13932859lbv.0 for ; Sun, 22 Feb 2015 04:06:14 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.198.66 with SMTP id ja2mr5424077lbc.39.1424606773943; Sun, 22 Feb 2015 04:06:13 -0800 (PST) Received: by 10.112.201.67 with HTTP; Sun, 22 Feb 2015 04:06:13 -0800 (PST) Received: by 10.112.201.67 with HTTP; Sun, 22 Feb 2015 04:06:13 -0800 (PST) In-Reply-To: References: <20150212064719.GA6563@savin.petertodd.org> <20150215212512.GR14804@nl.grid.coop> <54E11248.6090401@gmail.com> <20150219085604.GT14804@nl.grid.coop> Date: Sun, 22 Feb 2015 04:06:13 -0800 Message-ID: From: Eric Lombrozo To: Jeff Garzik Content-Type: multipart/alternative; boundary=001a11c34010b4a23f050fac1c39 X-Spam-Score: 1.3 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (elombrozo[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.9 FUZZY_AMBIEN BODY: Attempt to obfuscate words in spam 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1YPVIi-0002h6-B9 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Feb 2015 12:06:22 -0000 --001a11c34010b4a23f050fac1c39 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 leas= t > 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 include= s > 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=C3=B3n wr= ote: >> > 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 & mor= e >> Get technology previously reserved for billion-dollar corporations, FREE >> >> http://pubads.g.doubleclick.net/gampad/clk?id=3D190641631&iu=3D/4140/ost= g.clktrk >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > --001a11c34010b4a23f050fac1c39 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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&quo= t; <elombrozo@gmail.com> w= rote:

It seems to me we're confusing two completely different motivations fo= r double-spending. One is the ability to replace a fee, the other is the ab= ility 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 ass= ume it's the former, a genuine fee replacement. Even allowing for thing= s 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 outpu= t with exactly the additional desired fee.

If we can clearly distinguish these two cases then the fee r= eplacement case can be handled by relaying both and letting miners pick one= or the other while the output replacement case could be handled by rewardi= ng everything to a miner (essentially all outputs are voided...made unredee= mable...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"= <jgarzik@bitpay= .com> wrote:
= On Sat, Feb 21, 2015 at 10:25 PM, Jorge Tim=C3=B3n <jtimon@jtimon.cc>= wrote:
> On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik <jgarzik@bitpay.com> wrote:
>> This isn't some theoretical exercise.=C2=A0 Like it or not man= y use
>> insecure 0-conf transactions for rapid payments.=C2=A0 Deploying s= omething
>> that makes 0-conf transactions unusable would have a wide, negativ= e
>> impact on present day bitcoin payments, thus "scorched earth&= quot;

> And maybe by maintaining first seen policies we're harming the sys= tem
> in the long term by encouraging people to widely deploy systems based<= br> > 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.=C2=A0 Simply ceas= ing
the "maintaining [of] first seen policies" alone is simply not a<= br> realistic option.=C2=A0 The negative impact to today's userbase would b= e
huge.

Instant payments need a security upgrade, yes.

--
Jeff Garzik
Bitcoin core developer and open source evangelist
BitPay, Inc.=C2=A0 =C2=A0 =C2=A0 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 & mo= re
Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gam= pad/clk?id=3D190641631&iu=3D/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment
--001a11c34010b4a23f050fac1c39--