From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 10F60892 for ; Wed, 31 Aug 2016 20:01:25 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149058.authsmtp.co.uk (outmail149058.authsmtp.co.uk [62.13.149.58]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 27BF724D for ; Wed, 31 Aug 2016 20:01:23 +0000 (UTC) Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt20.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u7VK1Lef088905; Wed, 31 Aug 2016 21:01:21 +0100 (BST) Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com [52.5.185.120]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u7VK1HRd023307 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 31 Aug 2016 21:01:18 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id 649F0400D3; Wed, 31 Aug 2016 19:57:56 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 4EB2B20526; Wed, 31 Aug 2016 20:01:14 +0000 (UTC) Date: Wed, 31 Aug 2016 20:01:14 +0000 From: Peter Todd To: James MacWhyte Message-ID: <20160831200114.GA23079@fedora-21-dvm> References: <20160824014634.GA19905@fedora-21-dvm> <82507740-C4A3-4AF2-BA02-3B29E5FECDE4@petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="XsQoSWH+UP9D9v3l" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: ae3d14ec-6fb5-11e6-829e-00151795d556 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdQMUGUATAgsB AmAbWVVeUFx7WGs7 bghPaBtcak9QXgdq T0pMXVMcUQIOeh15 ZEoeUBpxdwIIeX9y Y0MsDyVYCEV+IBVg RBgGEHAHZDJmdWgd WRVFdwNVdQJNdxoR b1V5GhFYa3VsNCMk FAgyOXU9MCtqYA9c WgARJFZabEgFHzU9 ShYeVRUoG0AUXyIv NFQ5bRZWJ00WKE4y PFdpdFsCLx9YaEVy GFxHBCJCP1QHSyst AktiR0kCHTZBQCBa agAA X-Authentic-SMTP: 61633532353630.1037:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 52.5.185.120/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Protocol Discussion , Jeff Coleman Subject: Re: [bitcoin-dev] Capital Efficient Honeypots w/ "Scorched Earth" Doublespending Protection X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 20:01:25 -0000 --XsQoSWH+UP9D9v3l Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Aug 31, 2016 at 07:48:50PM +0000, James MacWhyte wrote: > > > > >I've always assumed honeypots were meant to look like regular, yet > > >poorly-secured, assets. > > > > Not at all. Most servers have zero reason to have any Bitcoin's accessi= ble > > via them, so the presence of BTC privkeys is a gigantic red flag that t= hey > > are part of a honeypot. > > >=20 > I was talking about the traditional concept. From Wikipedia: "Generally, a > honeypot consists of data (for example, in a network site) that appears to > be a legitimate part of the site but is actually isolated and monitored, > and that seems to contain information or a resource of value to attackers, > which are then blocked." >=20 > I would argue there are ways to make it look like it is not a honeypot > (plenty of bitcoin services have had their hot wallets hacked before, and > if the intruder only gains access to one server they wouldn't know that a= ll > the servers have the same honeypot on them). But I was just confirming th= at > the proposal is for an obvious honeypot. Ah, yeah, I think you have a point re: naming - this isn't quite the traditional honeypot, as we uniquely have the ability to give the attackers= a reward in a way where it's ok for the intruder to know that they've been detected; with traditional non-monetary honeypots it's quite difficult to c= ome up with a scenario where it's ok for an intruder to gain something from the intrusion, so you're forced to use deception instead. Perhaps a better term for this technique would be a "compromise canary"? Or "intruder bait"? After all, in wildlife animal research it's common to use = bait as a way of attracting targets to discover that they exist (e.g. w/ wildlife cameras), even when you have no intention of doing any harm to the animal. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --XsQoSWH+UP9D9v3l Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXxzeHAAoJEGOZARBE6K+yicgH/A3E3hvtlDLzJ2OFgWVudVho QdAAY52Co0QLn1+TZA+xlYUXFP0C7IVcBFkEKYsfQ8IgYRJio4/9Gil2R8zXAjpP eHhkVxU7ltKeVl3bXpVrHhSdXC3pZvPb/9xCZPC0Q9lDQtFS4mQTGKeO3bBHuwsU oM+4HH6a93s/+Borqh77oGdEhSrNDvv8Gd5Yn7SQmj4QuDMwdrfv1YBsDeUpc3Z3 je7HleWOFjopSPQf3534HfsS3VeLnzkmuulsHb6h8h4d9Y03vfX6F0lJ6NcI77F7 3RsKBg73wMJxQ8XQrlgHPyDC9ON/5JZER6JKeFKxJSvn+XyXGae2coP+EIook70= =mccF -----END PGP SIGNATURE----- --XsQoSWH+UP9D9v3l--