From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UsVcK-0002ka-Qc for bitcoin-development@lists.sourceforge.net; Fri, 28 Jun 2013 10:09:24 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of googlemail.com designates 74.125.83.53 as permitted sender) client-ip=74.125.83.53; envelope-from=john.dillon892@googlemail.com; helo=mail-ee0-f53.google.com; Received: from mail-ee0-f53.google.com ([74.125.83.53]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UsVcI-0000iS-Lj for bitcoin-development@lists.sourceforge.net; Fri, 28 Jun 2013 10:09:24 +0000 Received: by mail-ee0-f53.google.com with SMTP id c41so939954eek.40 for ; Fri, 28 Jun 2013 03:09:16 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.14.211.67 with SMTP id v43mr13140194eeo.55.1372414156310; Fri, 28 Jun 2013 03:09:16 -0700 (PDT) Received: by 10.223.12.131 with HTTP; Fri, 28 Jun 2013 03:09:16 -0700 (PDT) In-Reply-To: References: <1372353053.10405.140661249237317.77984E1F@webmail.messagingengine.com> Date: Fri, 28 Jun 2013 10:09:16 +0000 Message-ID: From: John Dillon To: Mike Hearn Content-Type: text/plain; charset=ISO-8859-1 X-Spam-Score: -1.4 (-) 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 (john.dillon892[at]googlemail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (john.dillon892[at]googlemail.com) -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: 1UsVcI-0000iS-Lj 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: Fri, 28 Jun 2013 10:09:25 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On Fri, Jun 28, 2013 at 9:05 AM, Mike Hearn wrote: >> I see some of the the other things that were concerning for me at the >> time are still uncorrected though, e.g. no proxy support (so users >> can't follow our recommended best practices of using it with Tor), > > Yeah. That's not the primary privacy issue with bitcoinj though. I'm > much, much more concerned about leaks via the block chain than the > network layer. Especially as Tor is basically a giant man in the > middle, without any kind of authentication you can easily end up > connected to a sybil network without any idea. I'd be surprised if Tor > usage was very high amongst Bitcoin users. Tor does not act as a particularly effective man in the middle for nodes that support connections to hidden services because while your connections to standard Bitcoin nodes go through your exit node, the routing path for each hidden service peer is independent. Having said that we should offer modes that send your self-generated transactions out via Tor, while still maintaining non-Tor connections. Anyway Sybil attacks aren't all that interesting if you are the one sending the funds, and receivers are reasonably well protected simply because generating false confirmations is extremely expensive and very difficult to do quickly. After all, you always make the assumption that nearly all hashing power in existence is honest when you talk about replace-by-fee among other things, and that assumption naturally leads to the conclusion that generating false confirmations with a sybil attack would take more than long enough that the user would be suspicious that something was wrong long before being defrauded. I'd be surprised if anyone has ever bothered with a false confirmation sybil attack. I wouldn't be the slightest bit surprised if the NSA is recording all the Bitcoin traffic they can for future analysis to find 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. Regarding usage I would be interested to hear from those running Bitcoin nodes advertising themselves as hidden services. > It's not a library limitation anyway, it's a case of how best to > present information to a user who is not familiar with how Bitcoin > works. "Safe" and "Not safe" is still a rather misleading distinction > given the general absence of double spends against mempool > transactions, but it's still a lot more meaningful than "2 confirms" 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. Specifically the generator would create a transaction from confirmed inputs, wait 60-180 seconds (randomized) to allow for full propagation, and then create a double-spend if the transaction hadn't already been mined. The transactions were randomized to look like normal traffic, including occasional bets to Satoshidice and similar for fun. (for the record the script had no way of knowing if a bet won and would happily attempt to double-spend wins) Fees for the replacement were power-law distributed IIRC, with some occasionally set to be quite hefty. 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'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. :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBCAAGBQJRzWCOAAoJEEWCsU4mNhiPwhgH/ic/OJMCYwdIuEM2ArSAEQRY l5bqafMYMcC/KE9xqZ1HVkLJ9Zg57MQ8VZw95WOsmRgNA0v1xIoCyREjI84QkCIq R/hOgS97eJc+XXnPBVoB4Jadq5LQ6jNpJo7cmiLJjCEmE6rTxLZBBT4P3eQw8oIn WAd7X7utP7/QAkjhaWB9FsfWT8QZseqpSPv8WucRftsRCABurzuD+eSfpRqYwk2z XBD0zO+EyAtu6hB3dRAFhqnhVfEcOLJCtXpm76WO574H4AZ/8EN+HozLJSUtylCq j1NZnpj/6pdFh2v5Pid4HEMEvuNNX60u6iXGJ560PUsdKmOh+LEhUBLKd9acJTw= =QtjI -----END PGP SIGNATURE-----