From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UsVmk-0003Cu-Lp for bitcoin-development@lists.sourceforge.net; Fri, 28 Jun 2013 10:20:10 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.175 as permitted sender) client-ip=209.85.214.175; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f175.google.com; Received: from mail-ob0-f175.google.com ([209.85.214.175]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UsVmi-0003bd-Qi for bitcoin-development@lists.sourceforge.net; Fri, 28 Jun 2013 10:20:10 +0000 Received: by mail-ob0-f175.google.com with SMTP id xn12so1803194obc.34 for ; Fri, 28 Jun 2013 03:20:03 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.176.67 with SMTP id cg3mr6013565obc.65.1372414803437; Fri, 28 Jun 2013 03:20:03 -0700 (PDT) Sender: mh.in.england@gmail.com Received: by 10.76.23.36 with HTTP; Fri, 28 Jun 2013 03:20:03 -0700 (PDT) In-Reply-To: References: <1372353053.10405.140661249237317.77984E1F@webmail.messagingengine.com> Date: Fri, 28 Jun 2013 12:20:03 +0200 X-Google-Sender-Auth: 6xfYBW82ZQfbgljsf82H8NB9xBQ Message-ID: From: Mike Hearn To: John Dillon Content-Type: text/plain; charset=UTF-8 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 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: 1UsVmi-0003bd-Qi 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:20:10 -0000 I suspect what you saw is mining nodes restarting and clearing their mempools out rather than an explicit policy of replace by fee. On Fri, Jun 28, 2013 at 12:09 PM, John Dillon wrote: > -----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-----