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 1UtEcp-0007rq-Vf for bitcoin-development@lists.sourceforge.net; Sun, 30 Jun 2013 10:12:56 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.80 as permitted sender) client-ip=62.13.149.80; envelope-from=pete@petertodd.org; helo=outmail149080.authsmtp.com; Received: from outmail149080.authsmtp.com ([62.13.149.80]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UtEcm-0000MS-PJ for bitcoin-development@lists.sourceforge.net; Sun, 30 Jun 2013 10:12:55 +0000 Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt10.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r5UACil0018623; Sun, 30 Jun 2013 11:12:44 +0100 (BST) Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r5UACeYY065591 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 30 Jun 2013 11:12:42 +0100 (BST) Date: Sun, 30 Jun 2013 06:12:39 -0400 From: Peter Todd To: John Dillon Message-ID: <20130630101239.GA1142@savin> References: <1372353053.10405.140661249237317.77984E1F@webmail.messagingengine.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 9a66bfa7-e16d-11e2-b10b-0025903375e2 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdQIUEkAaAgsB AmUbWlVeUV97XWA7 bAxPbAVDY01GQQRq WVdMSlVNFUsqBHlw dUt3Oxl0cgBPeTBy ZUBlXD5SDUJ8JxAs RVMBFGtSeGZhPWIC AkFYJR5UcAFPdx9G aVd6AXFDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4zBDkk QAsLGWdnOFABWyQZ LgBuI0VUEEsfO1g2 LRMtVEkbLxgKaEVV G0BABjMRIF9JTSs3 BgRbWwgZCjI1 X-Authentic-SMTP: 61633532353630.1019:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/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: 1UtEcm-0000MS-PJ Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org 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, 30 Jun 2013 10:12:56 -0000 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 28, 2013 at 10:09:16AM +0000, John Dillon wrote: > true transaction origins. Which reminds me, again, we need node-to-node > connections to be encrypted to at least protect against network-wide > passive sniffiing. Agreed. Speaking of, I may have missed it but as far as I can tell Bitmessage doesn't encrypt node-to-node communications, a serious oversight. Any attacker that can sniff a large fraction of the network, like the NSA, can easily use this to track down the originating node of any message, just like they can do with Bitcoin. > For what it is worth I ran a double-spend generator a month or so ago > against the replace-by-fee node that Peter setup and I found that a > small number of the double-spends did in fact appear to be mined under > replace-by-fee rules. Ah! I had a feeling that might be you. Were you the person who was creating the 1BTC fee transactions as well? > Though possibly just an artifact of unusually slow transaction > propagation it appeared that about 0.25% of hashing power was following > replace-by-fee rules. (not including transactions involving gambling, I > know Eligius and perhaps others block such transactions from their > mempools making double-spends easy to accomplish by including > Satoshidice outputs) I just got an email from someone saying they had a few Avalons with that patch installed actually; that was probably them. > I'm actually surprised by that figure myself given Peter Todd and I > haven't made a serious attempt yet to get miners to use replace-by-fee > rules. An interesting experiment would be to advertise that money is > being given away by such a tx generator in the mining forum, although I > would prefer to see solid mempool support for the "scorched-earth" > double-spend countermeasure first; Peter sounds like he has some great > ideas there, although as usual I am seeing very little in the way of > code. :) Keep in mind it's not just the mempool that needs changing - the network protocol semantics need to change too. For the "scorched-earth" strategy to work you need nodes tell their peers about the total fees a transaction has attached in addition tot he tx hash. Essentially you are advertising to your peers what would right now be an orphan, and your peers need to recursively get dependencies; I'm sure there's a bunch of edge cases there that would be need to thought out carefully. It's useful for a lot of things though, for instance when a zero-fee, zero-priority tx is given to a merchant who now wants to tell miners to mine it anyway due to a child tx. What I'd recommend actually for the nearer term is just adding recursive fee evaluation with a depth*breadth anti-DoS limit, adding the rpc and GUI adjfee and canceltx commands, adding better wallet support for conflicts, (someone is already workng on this) and adding a service bit with preferential peering. By preferential peering I mean you set aside a portion of your outgoing peer slots for peers with certain bits set and only fill those slots with those peers. In addition you can have DNS seeds return peers with specified service bits set: x0000000000000003.v1.seed.petertodd.org could be nodes with the first and second bits set. (we might want to define the upper 8 service bits as a service bit version field so we can redefine the other 56 in the far off future if required) --=20 'peter'[:-1]@petertodd.org 00000000000000b2b1f2ca2a2f937c2d93c41a5d089e1d3d4fe6bb663dd25db5 --h31gzZEtNLTqOjlF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJR0ASXAAoJECSBQD2l8JH7JbUH/3M849jw72EpVW4xwvcWs+kI JeY6i3uXMwFZqwRomT5sbQ96EVnK/sdpFFce4gWmsJzehWF2quIc3E60kPHr8pLu JAnsSPY3PwcTbMgYad5oYMujNt7YcXa24WIHR3WNZCYQVeh9B3I42k97er9evAtB JsAUqs0ZFfvQ2l+zHGJegXd5A/uB4ReXQ8Zt9Jr4auoitHaJFuxVzqZMuynJwr5s PDSCax/tuGk074+Ljlbp3KwQDXm4pP4zmqZ//tJyz3DO/nPcDKU2YWe3e0VU8Qd6 B2RlKKScJf9LIqpYQjNekQKqBiY0YZLl8O+kzdIcyKWX+6XjoNcR5RbVLsI3XmI= =V7NF -----END PGP SIGNATURE----- --h31gzZEtNLTqOjlF--