Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id E3660308 for ; Wed, 24 Aug 2016 16:29:32 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qt0-f172.google.com (mail-qt0-f172.google.com [209.85.216.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B408884 for ; Wed, 24 Aug 2016 16:29:30 +0000 (UTC) Received: by mail-qt0-f172.google.com with SMTP id w38so10006315qtb.0 for ; Wed, 24 Aug 2016 09:29:30 -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; bh=PDeczQJUYWJ0biDmKGgshnMECCWKy7l87Gtl5nmMJrE=; b=VuLSmJi35BgW86cpn99Uv/fczvSsBpjNO0K0iOuOzGzDVhElL/1gT72h/8Xag03Yb/ W6/aEeZL1IIIhbEL6GofubDGgwtTgkI2irYktWaT9qVj8B3yzZgP4fqaS1ZJg3JI5OtA BhIWbB+PsnNu+2yH4fmTVCv8cklbhcDifgGk0kETiKTmZ3qBHIvxzRlMO8vc5j1UPdLJ MkaLYpDxIE4bFBww5KLtGbd20I6YACcaS/OZSmHFF1Tr5aCxj6WAwkh4Uw8OmXmreU3y F1ajd2jRAXK+772AK2JjL3cIlyh5SCO/CirXWjc30JmBwN+9OL5dz8mtuWH+eN75DVx7 tMZw== 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; bh=PDeczQJUYWJ0biDmKGgshnMECCWKy7l87Gtl5nmMJrE=; b=hKPvdQnooiC3MOoLbtbz92IYqt5CDJym4nbc3OOoG/wRTCuN4Bde6XsrSMUhlk4Ove pcgukFG5a/muT/AnsY508iniuGO5PWlJK/5ByKyaoJyLr69HAhjN2UAVCqWAjJaUQYKj k0VNALg5/QvV3P4hQ01jcF1j4b3FJmwwKsA70xwRbzZk0jtw5KZAYfdejJQ4YLTrsTHn +B6n2PF067h2nopsNQqMHyIi930WzBx8TWrXZjM4xyb80AuRdtaw/0f5+synjlGISOrM CO9Bs3+g/0VCJec1AWa263lQZPKr1fjuLc9r+eiwqsJNcvxRMB13ju+FKcwtPw7HUEEL L0UQ== X-Gm-Message-State: AE9vXwMQqXwpHrS74d4sTr5UwKf5QMOtZXynYGuKdixNW+rTzA/l5cpq4Y5aTJxoTxlwaoDpe7v1glmrNlf17A== X-Received: by 10.237.50.35 with SMTP id y32mr4547150qtd.98.1472056169938; Wed, 24 Aug 2016 09:29:29 -0700 (PDT) MIME-Version: 1.0 References: <20160824014634.GA19905@fedora-21-dvm> In-Reply-To: From: Jimmy Date: Wed, 24 Aug 2016 16:29:19 +0000 Message-ID: To: Matthew Roberts , Bitcoin Protocol Discussion , Peter Todd Content-Type: multipart/alternative; boundary=94eb2c116a7a19445e053ad3c940 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 X-Mailman-Approved-At: Wed, 24 Aug 2016 16:32:28 +0000 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, 24 Aug 2016 16:29:33 -0000 --94eb2c116a7a19445e053ad3c940 Content-Type: text/plain; charset=UTF-8 Is this unrelated to Bitcoin Vigil idea published in 2014? http://www.coindesk.com/bitcoin-vigil-program-guards-against-intrusion-coin-theft/ On Wed, Aug 24, 2016 at 8:42 AM Matthew Roberts via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Really nice idea. So its like a smart contract that incentivizes > publication that a server has been hacked? I also really like how the > funding has been handled -- with all the coins stored in the same address > and then each server associated with a unique signature. That way, you > don't have to split up all the coins among every server and reduce the > incentive for an attacker yet you can still identify which server was > hacked. > > It would be nice if after the attacker broke into the server that they > were also incentivized to act on the information as soon as possible > (revealing early on when the server was compromised.) I suppose you could > split up the coins into different outputs that could optimally be redeemed > by the owner at different points in the future -- so they're incentivzed to > act lest their reward decays even more (this is of course, assuming that > the monetary reward for this is greater than any possible legal > consequences for the attacker -- it might not be. Thinking about this some > more: it would also be somewhat hard to deny that this -wasn't- a honeypot > with such a complex and unique scheme required for transactions, and I for > one wouldn't like to reveal that I'd hacked a server if I knew it was all a > calculated ploy. Don't honeypots rely on subtly?) > > What about also proving to an attacker that by breaking into a server they > would be guaranteed a reward? I know that the use-case for this is proof of > compromise so incentivizing a security audit would kind of fall more into > an active invitation to audit but couldn't you also make a cryptocurrency > that allowed coins to be moved based on a service banner existing at a > given IP address? Attackers could then break into the server, setup a > service that broadcasts their public key hash, and then spend coins locked > at this special contract address to that pub key hash which miners would > check on redemption (putting aside malicious use-cases for now.) > > > On Wed, Aug 24, 2016 at 11:46 AM, 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 >> >> > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --94eb2c116a7a19445e053ad3c940 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is this unrelated to Bitcoin Vigil idea published in 2014?=


On Wed, Aug 24, 2016 at 8:42 AM Matthew Roberts via bi= tcoin-dev <bitc= oin-dev@lists.linuxfoundation.org> wrote:
Really nice idea. So its like a smart contra= ct that incentivizes publication that a server has been hacked? I also real= ly like how the funding has been handled -- with all the coins stored in th= e same address and then each server associated with a unique signature. Tha= t way, you don't have to split up all the coins among every server and = reduce the incentive for an attacker yet you can still identify which serve= r was hacked.

It would be nice if after the attacker broke into the = server that they were also incentivized to act on the information as soon a= s possible (revealing early on when the server was compromised.) I suppose = you could split up the coins into different outputs that could optimally be= redeemed by the owner at different points in the future -- so they're = incentivzed to act lest their reward decays even more (this is of course, a= ssuming that the monetary reward for this is greater than any possible lega= l consequences for the attacker -- it might not be. Thinking about this som= e more: it would also be somewhat hard to deny that this -wasn't- a hon= eypot with such a complex and unique scheme required for transactions, and = I for one wouldn't like to reveal that I'd hacked a server if I kne= w it was all a calculated ploy. Don't honeypots rely on subtly?)
What about also proving to an attacker that by breaking into a server they= would be guaranteed a reward? I know that the use-case for this is proof o= f compromise so incentivizing a security audit would kind of fall more into= an active invitation to audit but couldn't you also make a cryptocurre= ncy that allowed coins to be moved based on a service banner existing at a = given IP address? Attackers could then break into the server, setup a servi= ce that broadcasts their public key hash, and then spend coins locked at th= is special contract address to that pub key hash which miners would check o= n redemption (putting aside malicious use-cases for now.)


On Wed, Aug 24, 2016 = at 11:46 AM, Peter Todd via bitcoin-dev <bitcoin-dev@l= ists.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


_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--94eb2c116a7a19445e053ad3c940--