From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YLoSg-0001sF-3f for bitcoin-development@lists.sourceforge.net; Thu, 12 Feb 2015 07:45:22 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.114 as permitted sender) client-ip=62.13.148.114; envelope-from=pete@petertodd.org; helo=outmail148114.authsmtp.net; Received: from outmail148114.authsmtp.net ([62.13.148.114]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1YLoSe-0006RO-Si for bitcoin-development@lists.sourceforge.net; Thu, 12 Feb 2015 07:45:22 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt16.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t1C7jDRi078730; Thu, 12 Feb 2015 07:45:13 GMT Received: from savin.petertodd.org (75-119-251-161.dsl.teksavvy.com [75.119.251.161]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t1C7j9sp043212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 12 Feb 2015 07:45:12 GMT Date: Thu, 12 Feb 2015 02:45:09 -0500 From: Peter Todd To: Tamas Blummer Message-ID: <20150212074509.GC4254@savin.petertodd.org> References: <20150212064719.GA6563@savin.petertodd.org> <7C171F0B-1EF8-4542-8E18-187B2E94DF14@bitsofproof.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5G06lTa6Jq83wMTw" Content-Disposition: inline In-Reply-To: <7C171F0B-1EF8-4542-8E18-187B2E94DF14@bitsofproof.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 138885c0-b28b-11e4-b396-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdwAUHlAWAgsB AmMbW1NeVFh7WGE7 bA9PbARUfEhLXhtr VklWR1pVCwQmRR1y AUQXEVlycwZEeXw+ bEBiVz5aX0xyfUMu QlMGF2VUeGZhPWQC AkNRcR5UcAFPdx8U a1UrBXRDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4REyY4 ThsPWD8+WEMISm0t d1p/chhEBk1NWgAA X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 75.119.251.161/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) 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 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1YLoSe-0006RO-Si Cc: bitcoin-development@lists.sourceforge.net 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: Thu, 12 Feb 2015 07:45:22 -0000 --5G06lTa6Jq83wMTw Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Feb 12, 2015 at 08:23:29AM +0100, Tamas Blummer wrote: > Peter, >=20 > An important use of the core is being border router to proprietary softwa= re, that is usually indexing the block chain and mempool. That software is = also assuming that double spends are not relayed by the core. >=20 > To remain useful as border router, the replace-by-fee patched core should= only relay double spend if it actually replaces an earlier transaction, as= otherwise the replace logic that is according to your commit more than jus= t fee comparison, would have to be replicated in the proprietary stack and = mempool might get out of sync with that of the border router.=20 Absolutely nothing in the replace-by-fee patch is consensus critical; your objection is entirely an artifact of the poor modularity of the Bitcoin Core codebase, something that is being actively improved on as we speak. Anyway, the logic of dealing with double-spends and keeping mempools synced is pretty trivial: for i in range(len(tx.vout)): for double_spent_tx in mempool.mapNextTx[COutPoint(tx.GetHash(), i)= ]: mempool.remove(double_spent_tx, recursive=3DTrue) mempool.add(tx) IOW, assume every transaction your "border router" gives you is now the one and only true transaction, and everything conflicting with it must go. All the complexity of replace-by-fee is in deciding when one transaction should replace another(s). Other than that the code is simple and very similar to block handling logic. --=20 'peter'[:-1]@petertodd.org 00000000000000000948f5c1f1a8c8073cc7d5161b98474e33904f8a1d6b0330 --5G06lTa6Jq83wMTw Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQGrBAEBCACVBQJU3FoBXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDAwODc4ZTllOWUwOTFlZjgzNjBiZjcxMGMxOGFmYjQzODRl MGJjM2NlZTc0YmQ1NzIvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfsQIQf+NgiN0zVef4vyWRhOzkqC7D2x juHVENDq5+TZIbgnCA7QOK24sr695nTrwkS4chSDaaigulObShE2MffBDfJAQ6oB bQV48riuEyzfEasm+7nm0730FP8L4vFldd/KD0p1XN95uTHSlPP3WHaS4EkmO2AD g+ZJBP+eOLhpw0iq9A1XTPkcImFXBSJTY3TymTRdcTLuibtzwvqWZ3/ejZ8ALROb fWausmxF/f/D8x0QHEAE+PZ7Hz9TqmvycvUOYO84ORU5sbp+NqlKZqHx++mt6FbQ 1+ilhe2UY9JmQUwi5npgUQF5Hc+3U5n0fuLFRlDgD+/lEJYyplBXPEUOHiBRzg== =FAew -----END PGP SIGNATURE----- --5G06lTa6Jq83wMTw--