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 E821C258 for ; Wed, 24 Aug 2016 01:46:40 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149115.authsmtp.co.uk (outmail149115.authsmtp.co.uk [62.13.149.115]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 0374E1AB for ; Wed, 24 Aug 2016 01:46:39 +0000 (UTC) Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt22.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u7O1kbBI078340; Wed, 24 Aug 2016 02:46:37 +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 u7O1kZZN016922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Aug 2016 02:46:36 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id 41BCB400DB; Wed, 24 Aug 2016 01:43:23 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 407D220532; Wed, 24 Aug 2016 01:46:34 +0000 (UTC) Date: Wed, 24 Aug 2016 01:46:34 +0000 From: Peter Todd To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <20160824014634.GA19905@fedora-21-dvm> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: 981ed305-699c-11e6-829e-00151795d556 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAYUGUATAgsB AmAbW1ZeVFt7WmU7 bghPaBtcak9QXgdq T0pMXVMcUQIXAEdr bGAeUx97dQcIeX14 bUIsV3haCRB5dUNg REddRnAHZDJmdWgd WRVFdwNVdQJNdxoR b1V5GgBcITxDNyZw MgE9PjswMDNDYARS RAwcNVUOWg4UWXZ2 fBsFBz4vEEFNaiwp MxxsYnIbAUwVP14q PF0tWFQXUVcqEApC EkpRAShfTwAA 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: Jeff Coleman Subject: [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, 24 Aug 2016 01:46:41 -0000 --PNTmBPCT7hxwcZjr Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Bitcoin-based honeypots incentivise intruders into revealing the fact they = have broken into a server by allowing them to claim a reward based on secret information obtained during the intrusion. Spending a bitcoin can only be d= one by publishing data to a public place - the Bitcoin blockchain - allowing detection of the intrusion. The simplest way to achieve this is with one private key per server, with e= ach server associated with one transaction output spendable by that key. However this isn't capital efficient if you have multiple servers to protect: if we have N servers and P bitcoins that we can afford to lose in the compromise,= one key per server gives the intruder only N/P incentive. Previously Piete Wuille proposed(1) tree signatures for honeypots, with a single txout protected by a 1-N tree of keys, with each server assigned a specific key. Unfortunately though, tree signatures aren't yet implemented = in the Bitcoin protocol. However with a 2-of-2 multisig and the SIGHASH_SINGLE feature we can implem= ent this functionality with the existing Bitcoin protocol using the following script: 2 2 CHECKMULTISIG The honeypot secret key is shared among all N servers, and left on them. The distriminator secret key meanwhile is kept secret, however for each server a unique signature is created with SIGHASH_SINGLE, paying a token amount to a notification address. For each individual server a pre-signed signature cre= ated with the distriminator secret key is then left on the associated server alo= ng with the honeypot secret key. Recall the SIGHASH_SINGLE flag means that the signature only signs a single transaction input and transaction output; the transaction is allowed to have additional inputs and outputs added. This allows the thief to use the honey= pot key to construct a claim transaction with an additional output added that p= ays an address that they own with the rest of the funds. Equally, we could also use SIGHASH_NONE, with the per-server discriminator being the K value used in the pre-signed transaction. Note that Jeff Coleman deserves credit as co-inventor of all the above. Censorship Resistance =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A potential disadvantage of using non-standard SIGHASH flags is that the transactions involved are somewhat unusual, and may be flagged by risk analysis at exchanges and the like, a threat to the fungibility of the reward. We can improve on the above concept from Todd/Coleman by using a pre-signed standard transaction instead. The pre-signed transaction spends the honeypot txout to two addresses, a per-server canary address, and a change address. = The private key associated with the change addres is also left on the server, a= nd the intruder can then spend that change output to finally collect their rew= ard. To any external observer the result looks like two normal transactions crea= ted in the process of someone with a standard wallet sending a small amount of funds to an address, followed by sending a larger amount. Doublespending =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D A subtlety in the the two transactions concept is that the intruder doesn't have the necessary private keys to modify the first transaction, which means that the honeypot owner can respond to the compromise by doublespending that transaction, potentially recovering the honeypot while still learning about= the compromise. While this is possible with all honeypots, if the first transac= tion is signed with the opt-in RBF flags, and CPFP-aware transaction replacement= is not implemented by miners, the mechanics are particularly disadvantageous to the intruder, as the honeypot owner only needs to increase the first transaction's fee slightly to have a high chance of recovering their funds. With CPFP-aware transaction replacement the intruder could in-turn respond = with a high-fee CPFP second transaction, but currently no such implementation is known. Scorched Earth =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D We can use the "scorched earth" concept to improve the credibility of the honeypot reward by making it costly for the honeypot owner to doublespend. = Here a second version of the honeypot pre-signed transaction would also be provi= ded which sepnds the entirety of the honeypot output to fees, and additionally spends a second output to fees. An economically rational intruder will publ= ish the first version, which maximizes the funds they get out of the honeypot. = If the owner tries to dishonestly doublespend, they can respond by publishing = the "scorched earth" transaction, encouraging the honeypot owner's honesty and making CPFP-aware transaction replacement irrelevant. Of course, miner centralization adds complexity to the above: in many insta= nces honeypot owners and/or intruders will be able to recover funds from altruis= tic miners. Equally, the additional complexity may discourage intruders from ma= king use of the honeypot entirely. Note that as an implementation consideration CHECKSEQUENCEVERIFY can be use= d to ensure the honeypot output can only be spent with transaction replacement enabled, as CSV requires nSequence to be set in specific ways in any transa= tion spending the output. References =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1) https://blockstream.com/2015/08/24/treesignatures/ --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --PNTmBPCT7hxwcZjr Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXvPx3AAoJEGOZARBE6K+yIB0H/3UqL0sxRyHU2aBTd2S5phrb VRqcK8+gGDrzs2a3/UIyAJ75JBe5ALSdRV97P8+cbD3IFgtLW4Q36Y5yqri6LZyc z/rOC1zt3ojyEIDcOxd+aNIOt/j0rlKY9BnImqvjmpd84jJqVf3pVkveD4NL/RKE 0js9nlFwbAGhEDYjPrRcpy5MyMTQyQIH8YX7/cugPZC8AerwZc29CBsbevG2GO36 j5zuays72QX2MJdaddw7IWFxXRGP7bRkmC5ZFIdZzuRE74BZ2xRKngriVWq07KKe 2TUWA+RuHRreyZ0cqcf5CapkF4B9mtgLZBmu7PFpinnhqEctEPLRO9QwR0lRyqU= =hbTm -----END PGP SIGNATURE----- --PNTmBPCT7hxwcZjr--