From mboxrd@z Thu Jan 1 00:00:00 1970 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 1Z5yM3-0006dT-Oe for bitcoin-development@lists.sourceforge.net; Fri, 19 Jun 2015 15:37:19 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.51 as permitted sender) client-ip=209.85.220.51; envelope-from=elombrozo@gmail.com; helo=mail-pa0-f51.google.com; Received: from mail-pa0-f51.google.com ([209.85.220.51]) by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Z5yM2-0006g9-Gw for bitcoin-development@lists.sourceforge.net; Fri, 19 Jun 2015 15:37:19 +0000 Received: by padev16 with SMTP id ev16so87643527pad.0 for ; Fri, 19 Jun 2015 08:37:12 -0700 (PDT) X-Received: by 10.70.134.133 with SMTP id pk5mr32939258pdb.133.1434728232819; Fri, 19 Jun 2015 08:37:12 -0700 (PDT) Received: from [192.168.1.102] (cpe-76-167-237-202.san.res.rr.com. [76.167.237.202]) by mx.google.com with ESMTPSA id t9sm11559377pbs.45.2015.06.19.08.37.11 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 19 Jun 2015 08:37:12 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: multipart/signed; boundary="Apple-Mail=_187EB51B-4BF2-4473-9686-3A945E4CC825"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b6 From: Eric Lombrozo In-Reply-To: <20150619151127.GA11263@savin.petertodd.org> Date: Fri, 19 Jun 2015 08:37:10 -0700 Message-Id: <04CE3756-B032-464C-8FBD-7ACDD1A3197D@gmail.com> References: <20150619103959.GA32315@savin.petertodd.org> <20150619151127.GA11263@savin.petertodd.org> To: Peter Todd X-Mailer: Apple Mail (2.2098) X-Spam-Score: -1.1 (-) 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 -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 0.5 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Z5yM2-0006g9-Gw Cc: bitcoin-development@lists.sourceforge.net, justusranvier@riseup.net Subject: Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee 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: Fri, 19 Jun 2015 15:37:19 -0000 --Apple-Mail=_187EB51B-4BF2-4473-9686-3A945E4CC825 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 OK, a few things here: The Bitcoin network was designed (or should be designed) with the = requirement that it can withstand deliberate double-spend attacks that = can come from anywhere at any time=E2=80=A6and relaxing this assumption = without adequately assessing the risk (i.e. I=E2=80=99ve never been = hacked before so I can assume it=E2=80=99s safe) is extremely dangerous = at best and just horrid security practice at worst. Your users might not = thank you for not getting hacked - but they surely will not like it when = you DO get hacked=E2=80=A6and lack a proper recovery plan. Furthermore, the protocol itself makes no assumptions regarding the = intentions behind someone signing two conflicting transactions. There = are many potential use cases where doing so could make a lot of sense. = Had the protocol been designed along the lines of, say, = tendermint=E2=80=A6where signing multiple conflicting blocks results in = loss of one=E2=80=99s funds=E2=80=A6then the protocol itself = disincentivizes the behavior without requiring any sort of altruistic, = moralistic assumptions. That would also mean we=E2=80=99d need a = different mechanism for the use cases that things like RBF address. Thirdly, taken to the extreme, the viewpoint of =E2=80=9Csigning a = conflicting transaction is fraud and vandalism=E2=80=9D means that if = for whatever reason you attempt to propagate a transaction and nobody = mines it for a very long time, you=E2=80=99re not entitled to = immediately reclaim those funds=E2=80=A6they must remain in limbo = forever. - Eric Lombrozo > On Jun 19, 2015, at 8:11 AM, Peter Todd wrote: >=20 > On Fri, Jun 19, 2015 at 03:00:57PM +0000, justusranvier@riseup.net = wrote: >> On 2015-06-19 10:39, Peter Todd wrote: >>=20 >> Yesterday F2Pool, currently the largest pool with 21% of the = hashing >> power, enabled full replace-by-fee (RBF) support after = discussions >> with >> me. This means that transactions that F2Pool has will be replaced = if >> a >> conflicting transaction pays a higher fee. There are no = requirements >> for >> the replacement transaction to pay addresses that were paid by = the >> previous transaction. >>=20 >>=20 >> Intentional fraud is a bad thing to add to a financial protocol. >>=20 >> A user who creates conflicting transactions, one that pays someone = else >> and another which does not pay them, and broadcasts both of them, has >> just self-incriminated themselves by producing prima facie evidence = of >> fraud. >=20 > Depends. >=20 > If you ask me to pay you 1BTC at address A and I create tx1 that pays > 1BTC to A1 and 2BTC of chain to C, what's wrong with me creating tx2 > that still pays 1BTC to A, but now only pays 1.999BTC to C? I'm not > defrauding you, I'm just reducing the value of my change address to = pay > a higher fee. Similarly if I now need to pay Bob 0.5BTC, I can create > tx3 paying 1BTC to A, 0.5BTC to B, and 1.498BTC to C. >=20 > Yet from the point of view of an external observer they have no idea = why > the transaction outputs reduced in size, nor any way of knowing if = fraud > did or did not occur. >=20 > Equally, maybe you tell me "Actually, just give me 0.5BTC to cancel = out > that debt", in which case I'm not breaking any contract at all by = giving > you less money than I first promised - the contract has changed. >=20 > Again, none of this can or should be observable to anyone other than = the > parties directly involved. >=20 >> It may be the case that since Bitcoin spans multiple legal = jurisdictions >> and can be use anonymously that the victims of such fraud can not = rely >> on legal recourse, and it may also be the case that proof of work is = how >> Bitcoin deals with the aforementioned factors, but regardless >> un-prosecutable fraud is still fraud and anyone who encourages it = should >> be recognied as a bad actors. >>=20 >> Committing vandalism and encouraging fraud to prove a point may be >> something the network can't stop on a technical level, but there's no >> reason not to call it out for what it is. >=20 > What do you think of Bitcoin XT then? It relays double-spends, which > makes it much easier to get double-spends to miners than before. In > particular you see a lot of zero-fee transactions being replaced by > fee-paying transactions, relayed through Bitcoin XT nodes and then > mined. Is that encouraging fraud? >=20 > -- > 'peter'[:-1]@petertodd.org > 000000000000000003932458055c68d4ee2b6d68441c4764efbdf6b0b1683717 > = --------------------------------------------------------------------------= ---- > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development --Apple-Mail=_187EB51B-4BF2-4473-9686-3A945E4CC825 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVhDcmAAoJEJNAI64YFENUA1QP/2SwmqlPHFsfhHVhNxsDBo6Q xp7urHl1P6rj8XUuHo7XCBYCtDSL+MAEexzivw8gRUqbKorjbxaPOxKKqCrG16++ GE/E/i/pU6EoIMcLikicDo+YfA5n1zJjyyVkbD6WQgYkUsP+ugYlp3uTuKjNT+Vp quu1IorzX8D8tw47s/eno3C100I43z1aJ4mh4tIPkH5ltkdoQ4gX+nyDOoKQ5gVk NzZSVDMUDPQc4NiZAYJG/M/4I2keKEmoSA1ombwNeem4uPWxpVEyag6sk+ksa9kx Y45AdLWstdGJ5FzWR842knCi5Ho6nCXyx2ZafT7qbgKRv3MbJrRlePThQM+v2v4a QyBqt6TOQWe8kiyOhbCLg1bY20fc4vXev54qSsmvIOPfDkeM/kr9jyWVwJekernr aA+uvjXIfmTwPOB7pIXGPLxr6enDa/imw0+Lu/LWEse3cHjSrTIfgbduNGZc5vIy 63zO56zqgquY8TmIc0mdsguRdM6nkeoAuDhE822Y9k6qL/uPWWPcOf+8Tjs3JsLs tSEOAKwjrgjKkmgML+YeLVvqqoVTmJzi8OBv/tRhw01jpv2ed67kI8j/FDwGPypo BJcjN1ysm68W6iEjxxQBcynFqrWpfmDk+AZcA0HU9U8Ux5R2/GGFYMDsoWBRLtEZ hPmsZXnJBTCtZrHEoEU/ =tKtV -----END PGP SIGNATURE----- --Apple-Mail=_187EB51B-4BF2-4473-9686-3A945E4CC825--