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 360447AA for ; Thu, 25 Aug 2016 02:55:00 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qk0-f177.google.com (mail-qk0-f177.google.com [209.85.220.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 106B414F for ; Thu, 25 Aug 2016 02:54:59 +0000 (UTC) Received: by mail-qk0-f177.google.com with SMTP id v123so34260338qkh.2 for ; Wed, 24 Aug 2016 19:54:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WMfh80u7kGdLDQXi9AOgF9XdeKdhyY5oRjdVsnO7uoE=; b=cfs8UxEF4MQGpVPH7L2phtt+fNxPnWBbvufbdsbRGtkXSlYBvzIpgHz9IxZcPKRr0r tuAaehr+TZyFR9iGwiKeflhjvaTp2JJY1dmoFOQxFsZY5X5P/MlXL1cV2M22eRa7VA+I 94KweCsAWwnsh2fZOuMB0WL/0FctQSiAzJUsyFeAZ6nJi3tz3bnHSQplYY69GLkUo34w M+CGM//LOHUp4CKkwp+dfOeqCD0SwuUWaxJ6LvdxiAiIF6hqn/M93fywoiXeGWl1zTom pz6NwU6D0wRxrap919qLBI8BDfWMKGozfFBETtlinLhpr82mIl0r/gJd/icNo3kZVyca nWTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WMfh80u7kGdLDQXi9AOgF9XdeKdhyY5oRjdVsnO7uoE=; b=FvCAxSEaOxF2C9wZ2tpz5pOxSS/jaCwh/G3qa20r2xUxxK1tCHOUXq4W8MUp5fZ9/7 BBz6jwOpVhAlcFBTrrPNdk0qrbWEu4levdYORrZeqUwE7uiR247P++bPJsTxHlRqTGcg EiAU8YtCgFhjrQfFXm2sTxZ9/sifSrGEQR3FxdlWloh6amahal6PIZzh6/14XcatxFWX ZA34H+68ZK1LQdEqchptRLtpxdZ1J3Nd7dnq4F3etCnNCBzmAaiGq/9cRwc2Eg18GPoa 1NLxyuJr0Mq1/pVOORtKtizAjdGnNnmSrv1YmiwqpYY4TAnqC0PCB1UK+/NkvDMd2rK4 rM4A== X-Gm-Message-State: AE9vXwP+XgCZ90sTHocS9ArKlPWv8nXrojzhUWYzxuysLUbQ2fBdn3hoTLu/dvjI8bQAQa3CvWC61ot/HDRwCA== X-Received: by 10.55.78.19 with SMTP id c19mr7153068qkb.193.1472093698166; Wed, 24 Aug 2016 19:54:58 -0700 (PDT) MIME-Version: 1.0 References: <20160824014634.GA19905@fedora-21-dvm> In-Reply-To: <20160824014634.GA19905@fedora-21-dvm> From: James MacWhyte Date: Thu, 25 Aug 2016 02:54:47 +0000 Message-ID: To: Peter Todd , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a114a8388f49447053adc85f4 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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: 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: Thu, 25 Aug 2016 02:55:00 -0000 --001a114a8388f49447053adc85f4 Content-Type: text/plain; charset=UTF-8 I've always assumed honeypots were meant to look like regular, yet poorly-secured, assets. If the intruder could identify this as a honeypot by the strange setup (presigned, non-standard transactions lying around) and was aware that the creator intended to doublespend as soon as the transaction was discovered, wouldn't they instead prefer to not touch anything and wait for a non-bait target to appear? Is the assumption here that the intruder wouldn't know this is a honeypot, or that they would know and it's just assumed that they would rather take their chances on this instead of causing some other trouble? On Tue, Aug 23, 2016 at 6:47 PM Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > 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 > done > 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 > each > 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 > implement > 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 > created > with the distriminator secret key is then left on the associated server > along > 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 > honeypot > key to construct a claim transaction with an additional output added that > pays > 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 > ===================== > > 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, > and > the intruder can then spend that change output to finally collect their > reward. > > To any external observer the result looks like two normal transactions > created > 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 > ============== > > 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 > transaction > 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 > ============== > > 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 > provided > which sepnds the entirety of the honeypot output to fees, and additionally > spends a second output to fees. An economically rational intruder will > publish > 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 > instances > honeypot owners and/or intruders will be able to recover funds from > altruistic > miners. Equally, the additional complexity may discourage intruders from > making > use of the honeypot entirely. > > Note that as an implementation consideration CHECKSEQUENCEVERIFY can be > used 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 > transation > spending the output. > > > References > ========== > > 1) https://blockstream.com/2015/08/24/treesignatures/ > > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a114a8388f49447053adc85f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I've always assumed honeypots were meant to look like = regular, yet poorly-secured, assets. If the intruder could identify this as= a honeypot by the strange setup (presigned, non-standard transactions lyin= g around) and was aware that the creator intended to doublespend as soon as= the transaction was discovered, wouldn't they instead prefer to not to= uch anything and wait for a non-bait target to appear? Is the assumption he= re that the intruder wouldn't know this is a honeypot, or that they wou= ld know and it's just assumed that they would rather take their chances= on this instead of causing some other trouble?

On Tue, Aug 23, 2016 at 6:47 PM Peter Todd via bitc= oin-dev <bitcoi= n-dev@lists.linuxfoundation.org> wrote:
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. Howeve= r
this isn't capital efficient if you have multiple servers to protect: i= f 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 implemen= ted 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:

=C2=A0 =C2=A0 2 <honeypot-pubkey> <distriminator-pubkey> 2 CHEC= KMULTISIG

The honeypot secret key is shared among all N servers, and left on them. Th= e
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 hav= e
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<= br> 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 honeypo= t
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<= br> 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&#= 39;t
have the necessary private keys to modify the first transaction, which mean= s
that the honeypot owner can respond to the compromise by doublespending tha= t
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 t= o
the intruder, as the honeypot owner only needs to increase the first
transaction's fee slightly to have a high chance of recovering their fu= nds.
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 credibilit= y 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<= br> 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/treesignatur= es/

--
http= s://petertodd.org 'peter'[:-1]@petertodd.org
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--001a114a8388f49447053adc85f4--