Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Z5yO3-0001g3-7W for bitcoin-development@lists.sourceforge.net; Fri, 19 Jun 2015 15:39:23 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of riseup.net designates 198.252.153.129 as permitted sender) client-ip=198.252.153.129; envelope-from=justusranvier@riseup.net; helo=mx1.riseup.net; Received: from mx1.riseup.net ([198.252.153.129]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1Z5yO1-0005Vf-Lj for bitcoin-development@lists.sourceforge.net; Fri, 19 Jun 2015 15:39:23 +0000 Received: from berryeater.riseup.net (berryeater-pn.riseup.net [10.0.1.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.riseup.net (Postfix) with ESMTPS id B49434140E; Fri, 19 Jun 2015 15:39:15 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: justusranvier) with ESMTPSA id 93FFB429D1 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 19 Jun 2015 15:39:15 +0000 From: justusranvier@riseup.net To: Peter Todd In-Reply-To: <20150619151127.GA11263@savin.petertodd.org> References: <20150619103959.GA32315@savin.petertodd.org> <20150619151127.GA11263@savin.petertodd.org> Message-ID: <47d8e5c4a1d55a1763f1aade1993fece@riseup.net> X-Sender: justusranvier@riseup.net User-Agent: Riseup mail X-Virus-Scanned: clamav-milter 0.98.7 at mx1 X-Virus-Status: Clean X-Spam-Score: -2.0 (--) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [198.252.153.129 listed in list.dnswl.org] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -0.3 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -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.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines -0.0 AWL AWL: Adjusted score from AWL reputation of From: address X-Headers-End: 1Z5yO1-0005Vf-Lj Cc: bitcoin-development@lists.sourceforge.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:39:23 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2015-06-19 15:11, Peter Todd wrote: > 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. > > 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. If there are two transactions which spend the same inputs, and each transaction has completely different output scripts, then this is prima facie fraudulent. https://en.wikipedia.org/wiki/Prima_facie If the two transactions have identical output scripts, and one output is reduced in value to increase the transaction fee, that has the appearance of honest dealing. There is a possibility that the payer has chose to under-pay their payee in order to over-pay the miner, but that's not what a reasonable observer would assume at first glance. Adding outputs to a transaction, while keeping all the existing outputs exactly how they are is another way of increasing the transaction fee of a transaction and is prima facie non-fraudulent. Note that child-pays-for-parent has none of this ambiguity. > 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? I haven't closely looked into the features of Bitcoin XT because I'm hoping that it never becomes relevant. I do want to see a heterogenous implementation network develop, but Bitcoin XT doesn't really count since it's a derivative of the Bitcoin Core codebase. In general, I think every signed Bitcoin transaction sent between different parties is part of a valid, enforceable contract (using common law definitions which predate any particular legal jurisdiction). Handling contracts and money is Serious Business and so the decision of how software should respond to double spends should not be made frivolously. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCgAGBQJVhDcpAAoJECpf2nDq2eYj23gP/ja9zqWZBoI/EfTJM0ZDVVY1 7lNwPJrAhO7oKQOKDrqhimA0TPRkoU0rCoYXSUEWn5X8ZIFlz9SQnGwXjIxt7PfG yZTxF+vJbFCDifNcUlF7DRs07cavEFM9AOutYi8PyVg0LoV5+0VMhhWT4Kc5vnlZ 4Tw91r1lvtI9MCif+KFpida/PnPlhvIfjASEuaK+vYx3ro1ovSUesh558xZmCZ9A Jfs+EwXBrxDO0zC0fatnaoRMkYQN7i/Dq1PFis7OHcZYBaQwgQTUoF8/wASvr8fQ dPXJNzhgpYYXeu4IsYH/Of9HkEw+N+/0DEW07asJJ5OIgQmcyoGn+ph8QzrPqG5m Rgb9BAmpqfCX+KrG6VDxU7xHLebwPhrPoYMIppvf77xhB2mV8c7Xky16Y/1tmxcH NLOL/WQelNBqCvx2+6c9yDJsJoY12Z0n1tdbIfp3m65xcFzqHPFPtTpsNl0p/gX7 xOMSEUdSVyjvsJjXxWOG3B06+dVRqjS0Pr9ERjjviqx40XVpg4Q0b6y+LL0ZVweE vs8ECN4y3vB7Qg2swYryVA7kNBh6GwCs7pMCh0DFw1mynGKndCKD+cPh8r3taP1u 8SlrKaD33schk4x70kxbtUzU+C7Yb5187Ct4U5kmsXhz1sypu4ebFPuWbJYG/Sjl uEW4Vcn+HxlNI/rhxBw4 =odRL -----END PGP SIGNATURE-----